GitHub Issues Do's and Don'ts • Hacker News Board

Re: GitHub Issues Do's and Don'ts

#11

Post by p4wnc6 » Mon, Aug 29, 2016, 6:16 PM UTC

adzicg wrote: post #10

p4wnc6 wrote: post #9

Earlier quoted context omitted.

Same here. When an issue goes unaddressed for a long time, yet the user base clearly needs it to be addressed, there has to be a mechanism by which the user base can make it annoying to the developers who continue to choose not to address it. Making it annoying for them, e.g. by a constant reminder that many people support some action to be taken, is the whole point. That way, projects can't simply define away critic…

> Same here. When an issue goes unaddressed for a long time, yet the user base clearly needs it to be addressed, there has to be a mechanism by which the user base can make it annoying to the developers who continue to choose not to address it. instead of trying to annoy people who volunteered their own time to build something useful, why not submit a pull request instead? if it's that important to you, invest a bit…

That's very unrealistic. I may be a casual user of a tool, while the fix requires deep familiarity with internal parts. The age-old answer of "fix it yourself" is silly, unless project maintainers don't care if what they make actually helps people.

In your comment there again is this mention that the dev time is volunteered, but this is a red herring. The time isn't useful just because it's volunteered. It has to be both volunteered and directed at effort that addresses something people need. If it's volunteered, but not directed at something people need, I think it's perfectly reasonable that they use some mechanism to indicate they feel dev resources aren't being allocated in a satisfactory way.

Re: GitHub Issues Do's and Don'ts

#12

Post by adzicg » Mon, Aug 29, 2016, 6:21 PM UTC

p4wnc6 wrote: post #11

adzicg wrote: post #10

Earlier quoted context omitted.

> Same here. When an issue goes unaddressed for a long time, yet the user base clearly needs it to be addressed, there has to be a mechanism by which the user base can make it annoying to the developers who continue to choose not to address it. instead of trying to annoy people who volunteered their own time to build something useful, why not submit a pull request instead? if it's that important to you, invest a bit…

That's very unrealistic. I may be a casual user of a tool, while the fix requires deep familiarity with internal parts. The age-old answer of "fix it yourself" is silly, unless project maintainers don't care if what they make actually helps people. In your comment there again is this mention that the dev time is volunteered, but this is a red herring. The time isn't useful just because it's volunteered. It has to be…

> The time isn't useful just because it's volunteered. It has to be both volunteered and directed at effort

useful depends on the target. something might be useful to you but not to other people. big part of successful product management is deciding on good market segments. as a casual user of a tool, you might not be in a segment that the project maintainers care a lot. annoying maintainers won't help at all if that is the case. learning about the code and fixing it will.

Re: GitHub Issues Do's and Don'ts

#13

Post by sixhobbits » Mon, Aug 29, 2016, 6:35 PM UTC

I know it's controversial, but I think

Dos and Don'ts

as is correct English grammar and faithful to the author's title is strongly preferable to

Do's and Don'ts

(Apostrophe is never used for pluralization, although I know that "Dos" looks really strange). The other option is to quote both words and to put the apostrophes outside the quotes

"Do"s and "Don't"s

Re: GitHub Issues Do's and Don'ts

#14

Post by alangpierce » Mon, Aug 29, 2016, 7:19 PM UTC

I like this list, but I would also add "Don't worry so much about these rules.". At least for me, I've often wanted to contribute to an open source project or participate in a discussion, but I was scared to because I was worried that I would say something wrong or not follow some implicit norm. Probably, the whole "RTFM culture" (or at least my perception/worry of it) had a net negative effect in my case because I ended up not contributing in cases where I probably could have positively contributed.

It really depends on your personality, though. If you're the type of person who naturally just speaks your mind without hesitation, then it's nice to slow down a bit and be more thoughtful, especially if you're dealing with a complex topic or your comment will be read by many people. But if you're more shy, you shouldn't feel the need to go through this checklist 5 times before submitting any comment or PR.

Similarly, if you're maintaining an open source project and someone breaks one of these "rules", be polite and be thankful that they're trying to help out. Allowing people to make little mistakes and learn from those mistakes is much more welcoming and human than "you must read this giant list of docs before you're allowed to speak". There's a balance to everything, of course, but you'll get a stronger community and help people grow if you're more welcoming.

Re: GitHub Issues Do's and Don'ts

#15

Post by nicky0 » Mon, Aug 29, 2016, 7:22 PM UTC

p4wnc6 wrote: post #11

adzicg wrote: post #10

Earlier quoted context omitted.

> Same here. When an issue goes unaddressed for a long time, yet the user base clearly needs it to be addressed, there has to be a mechanism by which the user base can make it annoying to the developers who continue to choose not to address it. instead of trying to annoy people who volunteered their own time to build something useful, why not submit a pull request instead? if it's that important to you, invest a bit…

That's very unrealistic. I may be a casual user of a tool, while the fix requires deep familiarity with internal parts. The age-old answer of "fix it yourself" is silly, unless project maintainers don't care if what they make actually helps people. In your comment there again is this mention that the dev time is volunteered, but this is a red herring. The time isn't useful just because it's volunteered. It has to be…

And it is perfectly reasonable for devs to ignore the annoying steam of +1s and do what they want anyway.

Re: GitHub Issues Do's and Don'ts

#16

Post by ramblenode » Mon, Aug 29, 2016, 7:32 PM UTC

p4wnc6 wrote: post #9

StavrosK wrote: post #6

Earlier quoted context omitted.

I needed to +1 something (as in, saying "this affects me too" literally five minutes ago, and felt bad that wasn't more constructive, but it was the only way to send the maintainer a notification about the issue. If I had just thumbsupped it, nobody would have been notified and seen that it affects more than one person.

Same here. When an issue goes unaddressed for a long time, yet the user base clearly needs it to be addressed, there has to be a mechanism by which the user base can make it annoying to the developers who continue to choose not to address it. Making it annoying for them, e.g. by a constant reminder that many people support some action to be taken, is the whole point. That way, projects can't simply define away critic…

Understand that as the consumer of a FOSS project you are entitled only to terms specified in the license. Usually those do not include free customer support or a guarantee of quality. If you can't or don't want to contribute code you are certainly free to contribute money to help offset the cost of development for features you would like to see. But if you think it's appropriate to harass developers and usurp their development platform in an attempt to squeeze more thankless work out of them, there is something seriously wrong with your world view.

Re: GitHub Issues Do's and Don'ts

#17

Post by etimberg » Mon, Aug 29, 2016, 7:49 PM UTC

p4wnc6 wrote: post #11

adzicg wrote: post #10

Earlier quoted context omitted.

> Same here. When an issue goes unaddressed for a long time, yet the user base clearly needs it to be addressed, there has to be a mechanism by which the user base can make it annoying to the developers who continue to choose not to address it. instead of trying to annoy people who volunteered their own time to build something useful, why not submit a pull request instead? if it's that important to you, invest a bit…

That's very unrealistic. I may be a casual user of a tool, while the fix requires deep familiarity with internal parts. The age-old answer of "fix it yourself" is silly, unless project maintainers don't care if what they make actually helps people. In your comment there again is this mention that the dev time is volunteered, but this is a red herring. The time isn't useful just because it's volunteered. It has to be…

I think it's reasonable to ask someone for a PR but it's also reasonable for that person to ask the maintainers how to do it. As a maintainer of a fairly popular library, I would love if everyone who "+1'd" a feature request asked on our slack channel how to implement it, or even emailed me. I've started closing feature requests that we aren't going to implement (don't belong in the core library) with something like "Closing because we will not implement this in the core. If you'd like to implement this as a plugin, post here and I can direct you in the right direction."

Re: GitHub Issues Do's and Don'ts

#18

Post by adzicg » Mon, Aug 29, 2016, 8:01 PM UTC

etimberg wrote: post #17

p4wnc6 wrote: post #11

Earlier quoted context omitted.

That's very unrealistic. I may be a casual user of a tool, while the fix requires deep familiarity with internal parts. The age-old answer of "fix it yourself" is silly, unless project maintainers don't care if what they make actually helps people. In your comment there again is this mention that the dev time is volunteered, but this is a red herring. The time isn't useful just because it's volunteered. It has to be…

I think it's reasonable to ask someone for a PR but it's also reasonable for that person to ask the maintainers how to do it. As a maintainer of a fairly popular library, I would love if everyone who "+1'd" a feature request asked on our slack channel how to implement it, or even emailed me. I've started closing feature requests that we aren't going to implement (don't belong in the core library) with something like…

for claudia I have a policy of replying to issues with ideas on how to implement it, and closing the issue one week after if there was no activity. got a fair few happy contributors now, and more people know the code base so they respond to users on the chat channel even when I'm not around.

Re: GitHub Issues Do's and Don'ts

#19

Post by joshka » Mon, Aug 29, 2016, 11:04 PM UTC

ramblenode wrote: post #16

p4wnc6 wrote: post #9

Earlier quoted context omitted.

Same here. When an issue goes unaddressed for a long time, yet the user base clearly needs it to be addressed, there has to be a mechanism by which the user base can make it annoying to the developers who continue to choose not to address it. Making it annoying for them, e.g. by a constant reminder that many people support some action to be taken, is the whole point. That way, projects can't simply define away critic…

Understand that as the consumer of a FOSS project you are entitled only to terms specified in the license. Usually those do not include free customer support or a guarantee of quality. If you can't or don't want to contribute code you are certainly free to contribute money to help offset the cost of development for features you would like to see. But if you think it's appropriate to harass developers and usurp their…

+1 ;)

Re: GitHub Issues Do's and Don'ts

#20

Post by StavrosK » Tue, Aug 30, 2016, 1:44 AM UTC

adzicg wrote: post #10

p4wnc6 wrote: post #9

Earlier quoted context omitted.

Same here. When an issue goes unaddressed for a long time, yet the user base clearly needs it to be addressed, there has to be a mechanism by which the user base can make it annoying to the developers who continue to choose not to address it. Making it annoying for them, e.g. by a constant reminder that many people support some action to be taken, is the whole point. That way, projects can't simply define away critic…

> Same here. When an issue goes unaddressed for a long time, yet the user base clearly needs it to be addressed, there has to be a mechanism by which the user base can make it annoying to the developers who continue to choose not to address it. instead of trying to annoy people who volunteered their own time to build something useful, why not submit a pull request instead? if it's that important to you, invest a bit…

My specific problem (and the reason for the +1 above) was that I did submit a PR that would be very easy to merge and the maintainer has been sitting on it for months :(