I got the same vibe from the article TBH, a lot of what he considers rude just seems like well intentioned, if possibly misunderstood, suggestions.
Consider that even filing a bug report is an effort 95% of users would never make. So even doing that is in most cases a contribution, at least as seen from the point of view of the submitter. But the author actually considers it an affront if it doesn't conform to the bug report template.
With the disclaimer that I have never maintained a highly popular GitHub repo, I get a lot of feedback for my projects that is unuseable, and some that is aggravating. I always have the option of simply ignoring it, and that's the end of that interaction. Perhaps the author is not actually good at setting boundaries and ends up blaming others for imposing.
This was not the vibe I meant to express. I'm sorry it came across that way. I meant to express how it made me _feel_. The next paragraph goes on to say how such issues are eminently reasonable in a lot of cases, and my coming to terms with that is a struggle I face.
My goal was to explain my own perspective in the hope that it increases understanding of everyone involved.
> Perhaps the author is not actually good at setting boundaries and ends up blaming others for imposing.
I tried really hard to leave blame out of my article (for anyone other than myself). That is not how I feel. On the contrary, as I mentioned in my article, setting boundaries is exactly what has helped me so much.
I hope you don't take my comments as combative, I'm trying to speak from experience. I also learned of Mr. Gallant from being on the Go code review lists. I also noticed he seemed to "switch" to Rust. With that knowledge, anything I used heavily I would fork. If one day the two can reconcile, great. If not, congratulations, you own it until you get tired of it and someone else forks it. Such is the nature of open source!
Mentioning that you don't intend to maintain a project is not "labour".
If you don't look at any PR in the next 3/6 months, mark it unsupported.
eg If you fork the code where the upstream project is obviously still active, and your changes target the same audience as the original (eg not taking in a new/experimental direction), then it could be rude.
However, if the upstream repo is no longer active the upstream authors may even happy to have someone picking up the leadership role for that particular project.