Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Helping newcomers become contributors to open projects

journals.plos.org

Post reply on HN
Print view View original

41–50 of 99 posts

Re: Helping newcomers become contributors to open projects

#41

Post by pjc50 »

Dirlewanger wrote: post #36
TeMPOraL wrote: post #9

Earlier quoted context omitted.

Until recently, having a CoC in the first place is something I viewed as signalling allegiance or submission to the bully crowd you mention. Over the recent years, however, CoC seems to have become a new term for the standard rules boilerplate every community has, so I view it as neutral these days. (Unless someone makes a big deal about adopting Contributor Covenant. That's just genuflecting to the "rail thieves".)

Nope, it's still virtue signalling. By acknowledging the need to have a paragraph of text that boils down to "play nice, or we'll take your things away", you've already given trolls too much legitimacy and power. Why is it so hard to start from a position of: assume all participants want to make the project better from the start until otherwise seen?

That leads to "the person complaining about a problem is trying to make the project worse, so all we have to do is ban the person who said that groped them at a conference and we can get back to work".

(That example was not referencing any particular case, BTW)

Re: Helping newcomers become contributors to open projects

#42

Post by FeepingCreature »

_ea1k wrote: post #37
FeepingCreature wrote: post #8

Some practical rules I wish projects would follow, from personal experience: * Have a README. At the top of the README, say what the project does. Document how to build and run it. * Make sure every artifact of the project is buildable from source. This includes project websites and binary releases. Document this process. * Have a clear assignment of responsibilities, and respect it. If you let someone take over a ta…

* Don't close bug reports just because they're old. A bug report is either good or bad - that is, the bug is either reproducible or it isn't. A bad bug report is bad from the start; close it quickly - or else, don't close it just because enough time has passed. (This goes doubly for bug reports with advice.) I disagree... lots of bug reports actually are not bad at all, but are also not something that you want to pri…

Well, then the bug stays open. :shrug: Why is that so bad?

The only reason I can see to close old bugs is that a project wants to make it seem like it has fewer issues than it does, and hopes that users won't notice the issue.

Re: Helping newcomers become contributors to open projects

#43

Post by dspillett »

_ea1k wrote: post #37
FeepingCreature wrote: post #8

Some practical rules I wish projects would follow, from personal experience: * Have a README. At the top of the README, say what the project does. Document how to build and run it. * Make sure every artifact of the project is buildable from source. This includes project websites and binary releases. Document this process. * Have a clear assignment of responsibilities, and respect it. If you let someone take over a ta…

* Don't close bug reports just because they're old. A bug report is either good or bad - that is, the bug is either reproducible or it isn't. A bad bug report is bad from the start; close it quickly - or else, don't close it just because enough time has passed. (This goes doubly for bug reports with advice.) I disagree... lots of bug reports actually are not bad at all, but are also not something that you want to pri…

That isn't closing them "just because they're old" though.

That is closing them in a "WONTFIX" state. This is perfectly valid for minor irritations or matters that the maintainers don't agree are bugs at all, though some (entitled) bug reporters will take umbrage with it especially if they've taken the time to actually produce a good bug report rather than just a vague "X doesn't work" or "Y breaks Z".

If closing in a WONTFIX state, a brief explanation added to the ticket is a good idea, to reduce the risk of future time wasted because it is simply reopened as a new bug. For instance: you might be closing it in that state because it will become irrelevant shortly due to other work (perhaps the feature is changing considerably which will render the issue moot), because you don't consider it a bug (i.e. behaviour by design) or fixing to some satisfactory standard is something there isn't time for (i.e. your "not ever likely to be a priority" status). In the "not ever likely to be a priority" case, perhaps suggest that a PR addressing the issue matching your coding standards (assuming you have them documented) would be welcome, though only do that if such a PR would have a change of being given the relevant assessment time.

Re: Helping newcomers become contributors to open projects

#44

Post by dspillett »

FeepingCreature wrote: post #42
_ea1k wrote: post #37

Earlier quoted context omitted.

* Don't close bug reports just because they're old. A bug report is either good or bad - that is, the bug is either reproducible or it isn't. A bad bug report is bad from the start; close it quickly - or else, don't close it just because enough time has passed. (This goes doubly for bug reports with advice.) I disagree... lots of bug reports actually are not bad at all, but are also not something that you want to pri…

Well, then the bug stays open. :shrug: Why is that so bad? The only reason I can see to close old bugs is that a project wants to make it seem like it has fewer issues than it does, and hopes that users won't notice the issue.

> and hopes that users won't notice the issue

It is a little more than that in many cases. People judging a project overall by the number of open bugs reports, no matter how minor, isn't really fair if there is considerable development on more important bugs/features/other elsewhere in the project.

Re: Helping newcomers become contributors to open projects

#45

Post by semiotagonal »

Confession: I've been a professional software developer for 24 years, and I've never been able to get my foot in the door for an open-source project (other than my own open-sourced license stuff).

I think part of it is because the projects that are most worthwhile have no shortage of participants, so they don't need to extend any welcome to newcomers; and the projects that need participants often end up that way because they're not clearly good things to be working on in the first place.

Re: Helping newcomers become contributors to open projects

#46

Post by TeMPOraL »

pjc50 wrote: post #41
Dirlewanger wrote: post #36

Earlier quoted context omitted.

Nope, it's still virtue signalling. By acknowledging the need to have a paragraph of text that boils down to "play nice, or we'll take your things away", you've already given trolls too much legitimacy and power. Why is it so hard to start from a position of: assume all participants want to make the project better from the start until otherwise seen?

That leads to "the person complaining about a problem is trying to make the project worse, so all we have to do is ban the person who said that groped them at a conference and we can get back to work". (That example was not referencing any particular case, BTW)

More likely that the person complaining about a social problem is actually trying to make the project worse. Like e.g. outsiders coming out of the woodwork to push CoCs on projects that don't have them.

> so all we have to do is ban the person who said that groped them at a conference and we can get back to work

Yes. Such an issue should be brought to the police, not be posted on an issue tracker for rallying social media lynch mobs. Cases of exaggerating or straight up lying about sexual harassment in order to remove or destroy someone are common enough, and consequences of a mistaken judgement severe, so the presumption of innocence is very important.

Re: Helping newcomers become contributors to open projects

#47

Post by at_a_remove »

matheusmoreira wrote: post #28
rurban wrote: post #4

Beware, pitfalls. * Make governance explicit: Mostly backfires. * Have and enforce a code of conduct: Mostly backfires. All the recent dramas were entirely caused by having explicit governance and code of conduct bylaws, which would not have happened (and didn't happen) without these before. It only encourages public fights over these.

Yeah. I've witnessed so many controversies I started archiving and collecting them. Code of conduct enforcement is flawed to say the least.

I would be interested in seeing these.

My naive hope is that a code of conduct could be crafted with defensive measures to at least mitigate such problems, but that is probably hopeless in the face of bad actors.

Re: Helping newcomers become contributors to open projects

#49

Post by pjc50 »

TeMPOraL wrote: post #46
pjc50 wrote: post #41

Earlier quoted context omitted.

That leads to "the person complaining about a problem is trying to make the project worse, so all we have to do is ban the person who said that groped them at a conference and we can get back to work". (That example was not referencing any particular case, BTW)

More likely that the person complaining about a social problem is actually trying to make the project worse. Like e.g. outsiders coming out of the woodwork to push CoCs on projects that don't have them. > so all we have to do is ban the person who said that groped them at a conference and we can get back to work Yes. Such an issue should be brought to the police, not be posted on an issue tracker for rallying social…

> Such an issue should be brought to the police

... who will often ignore it.

> Cases of exaggerating or straight up lying about sexual harassment in order to remove or destroy someone are common enough

Are they?

Re: Helping newcomers become contributors to open projects

#50

Post by beart »

dspillett wrote: post #44
FeepingCreature wrote: post #42

Earlier quoted context omitted.

Well, then the bug stays open. :shrug: Why is that so bad? The only reason I can see to close old bugs is that a project wants to make it seem like it has fewer issues than it does, and hopes that users won't notice the issue.

> and hopes that users won't notice the issue It is a little more than that in many cases. People judging a project overall by the number of open bugs reports, no matter how minor, isn't really fair if there is considerable development on more important bugs/features/other elsewhere in the project.

It also isn't fair for people who assume a project that has a large number of closed issues is highly active, when in fact, a large number of those issues have just never seen any activity and were closed for being stale.
Post reply on HN