Regarding adding +1 to issues - rather than doing this, up-vote the issue on GitHub (thumb up). This can be useful to maintainers because they can sort by thumb up and see the most popular ones. Adding a +1 comment really does nothing - it's just one more useless notifications for everyone, and it won't allow filtering or sorting issues. People might even unwatch the issue because of this and thus missing useful comm…
> This can be useful to maintainers because they can sort by thumb up and see the most popular ones. TIL, but I also think it's not really clear what a reaction does. Does adding a reaction to a comment in an issue thread bump the whole issue, does it have to be added to the top issue to show up in sorting? I think a global "Vote for this issue" button would make this a bit more clearer than just a reaction within th…
Don't be that open-source user, don't be me
81–90 of 173 posts
Re: Don't be that open-source user, don't be me
#82There's nothing wrong in these tickets to apologize for. Issues are for public discussions of issues. If maintainers cannot deal with public issues, they cannot be maintainers. Problems don't come with silverspoons, And this case there were not even problems at all.
Re: Don't be that open-source user, don't be me
#83Earlier quoted context omitted.
Then again, adding a comment may prevent a bot from auto-closing the issue.
I've never really understood the point of these bots. I could understand if an issue had a test case attached to it, and the bot was auto-closing the issue if/when the test passes. That way, if it is resolved when fixing some other bug, or when refactoring, the issue is closed. But closing an issue due to inactivity gives the false impression that the issue has been resolved.
However: Many projects swim in a sea of open tickets. Too many for the maintainers to keep an overview. By auto closing you make it clear to observers that currently this thing likely won't change and by forcing to reopen the maintainers can get users to tell them whether the issue still persists without having to try themselves. Generally there is little worth in keeping many years old tickets open, hiding recent issues while probably not being an issue anymore for whatever reason.
Re: Don't be that open-source user, don't be me
#84Earlier quoted context omitted.
Then again, adding a comment may prevent a bot from auto-closing the issue.
I've never really understood the point of these bots. I could understand if an issue had a test case attached to it, and the bot was auto-closing the issue if/when the test passes. That way, if it is resolved when fixing some other bug, or when refactoring, the issue is closed. But closing an issue due to inactivity gives the false impression that the issue has been resolved.
Re: Don't be that open-source user, don't be me
#85Thank you to the author for writing this. Entitlement in open source is a massive problem, I have experienced it first-hand many times. The problem is that it discourages contributions not only from the existing maintainers but also from people who may volunteer to fix issues in the future. Would you be willing to contribute if most of the issues are just asking for things (often rudely) and not even saying thanks wh…
I’m not sure what you mean by this example. From what I see, somebody submitted a bug fix that hadn’t been approved/merged by you for 6 months. Then some quite rude conversation happened “Don’t act as my free time is owned by you”. I mean both sides look quite ugly in this particular case to be honest.
From my perspective the PR was reviewed and was stuck on a test case being created. The author of the PR even stated "I'll try to make a simple test case." so as far as I'm concerned the ball was in their court.
But you know, reviewing PRs takes time too. Acting entitled about a review taking a long time shouldn't be done either.
Re: Don't be that open-source user, don't be me
#86Just a thought (vaguely connected here) but voting on features to be implemented is ... pretty much same as voting IRL on policies not parties. I have often wondered what would be the thing to trigger companies to stop being totalitarian dictatorships and become democratic to their (employees / stakeholders) - is it crazy to say voting on features to build would be the one?
Where things go wrong is ‘stakeholders’ (aka non-paying people/customers) demanding influence for whatever is important to them like savings baby seals or whatever. They know they can’t influence the company by ‘voting with their wallet’ so seek out other means to change the company’s direction. Like, as a totally random example, wanting voting rights to the future plans of the company as an outsider with no knowledge of internal goals and/or if the proposal would even be profitable.
Re: Don't be that open-source user, don't be me
#87Looks more like the new US youngsters becoming more like brainwashed Chinese or Russian apostates, who need to make public apologies before being allowed into society again. mea culpa, mea maxima culpa. What's wrong with you? Seriously. There's nothing wrong in these tickets to apologize for. Issues are for public discussions of issues. If maintainers cannot deal with public issues, they cannot be maintainers. Proble…
IMHO, content like this is very useful to my development as a person and a member of a community. (Not as a rule-set that must be blindly adhered to, but as an opportunity for self-reflection on my actions and how they impact others...)
Re: Don't be that open-source user, don't be me
#88I kinda blame Github for all this. In the past, there was just a bit of friction before filing a bug or dropping a comment on a project. You had to sign up for bugzilla. You had to sign up for the mailing list. Something. Anything. It was just enough friction that you had to want to post that comment or file that bug. You weren't going to waste your time just to be a shit. With everything on Github, it's simply too e…
THIS! The UI really encourages drive-by comments from anybody.
Like social networks, it's designed to maximize views and clicks instead of building communities.
Re: Don't be that open-source user, don't be me
#89Earlier quoted context omitted.
Your quick PR becomes the maintainer's burden, and rejecting a pull request can also come with a substantial time cost. It's best to conform to the contribution process described by the maintainer to avoid wasting their time as much as possible.
> It's best to conform to the contribution process described by the maintainer to avoid wasting their time as much as possible. It’s not their prerogative to waste my time, just as it’s not mine to waste theirs. If they’re not happy with a PR they’re welcome to reject it, ask me to fix it, or completely ignore it. When they make a project public they’re explicitly condoning the fact they may get a PR (and nothing els…
I don't think that's true. It appears you just assume that because pull requests cannot be disabled on GitHub.
Sending unsolicited pull requests to people that clearly told you to open an issue first is disrespectful. You don't have to engage with a project or a community, but if you decide to participate by submitting a pull request, you should follow their contribution guidelines.
Re: Don't be that open-source user, don't be me
#90Yeah, it can be very hard depending on the case, at least some premium features/merch/books/guides should be used to keep an open source project alive.