Live data from Hacker News

Don't be that open-source user, don't be me

jacobtomlinson.dev

81–90 of 173 posts

Re: Don't be that open-source user, don't be me

#81
post #26

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…

The point here is to not bump the issue. My GitHub notifications are a mess, and bumps cause me to unsub from notifications to issues in my own repository. There’s also a 0% chance a bump is going to cause me to reallocate my evening, so it doesn’t help get the issue moved forward.

Re: Don't be that open-source user, don't be me

#82
Looks 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. 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

#83

Earlier 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.

It depends a bit in the project and maintainers motivation.

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

#84

Earlier 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.

Same, I find these bots really annoying. I guess they might be necessary/useful for popular projects where a small team of maintainers is trying to stay on top of a massive pile of incoming issues. But for the most part they seem misguided. (Especially the ones with a really short (like 30 days) activity window.) If an issue still exists in the project, why should it be closed? That will just require the next person who notices the issue to open a new one... Also, no activity on an issue can just mean that folks are waiting patiently for someone to get around to implementing it (or, more commonly, for some project dependency to release the patch that is necessary for fixing the issue ..).

Re: Don't be that open-source user, don't be me

#85
post #75
post #68

Thank 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 what I see, somebody submitted a bug fix that hadn’t been approved/merged by you for 6 months.

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

#86

Just 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?

Unless you have an absolute monopoly market position you are a democratic institution where the ‘votes’ are people giving you their hard earned money in exchange for whatever you’re selling.

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

#87
post #82

Looks 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…

People mature and the way they interact with others can change. I see this post not as a public self-shaming, but as the output of a personal retrospective that the author felt would be helpful to others to learn from instead of having to repeat the same mistakes...

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

#88
post #10

I 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…

> With everything on Github, it's simply too easy to quickly slap a thoughtless comment on a project

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

#89
post #52
post #49

Earlier 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…

> When they make a project public they’re explicitly condoning the fact they may get a PR

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.

Post reply on HN