Helping newcomers become contributors to open projects
journals.plos.org
Helping newcomers become contributors to open projects
1–10 of 99 posts
Re: Helping newcomers become contributors to open projects
#2While this is meant for open source and mostly remote workers, I can’t help thinking how much better the applications and teams with which I’ve worked over the years if they followed this advice.
Re: Helping newcomers become contributors to open projects
#3I think some combinations of items 6 and 9 are often missing from projects where there’s a quick rush to view issues and bug reports as nuisance instead of viewing them as a lifeline of critical feedback the project needs for survival.
I’ve seen it so many times where open source projects have critical bugs, but the existing contributors rush to play the false defense along the lines of “pay us if you want this fixed,” while prioritizing new features or projects out of intellectual curiosity instead.
Obviously no contributor in an open source project _has to_ do anything. But at some level if you’re working on the project because you care about the project instead of burning the commons in a land grab for satisfying personal projects, then taking priority from reported issues and even thanking people for pointing out urgent bugs whose fixes should supercede the fun features of some planned release has to become the expected default.
Re: Helping newcomers become contributors to open projects
#4Beware, 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.
Re: Helping newcomers become contributors to open projects
#5Beware, 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.
Hm, I think I know some of the cases you're thinking of. (Specifically, GNU and Stack Overflow come to mind?)
But don't you think these were (at least in part) only the visible outbreaks of conflicts that had already been simmering for a long time? If that is so, introducing an explicit governance/CoC may have been a long overdue step that ended up breaking some crockery, but only because it wasn't enacted early enough...
Re: Helping newcomers become contributors to open projects
#6Open source projects (or any large collaboration) now have a new type of danger that many are unprepared to handle, in that there are people online who will shit on your work or make a giant spectacle that can ruin people just so that they can appear good in Twitter or make some kind of name for themselves in certain online circles. Similar to thieves who steal metal from railways, the damage they cause is far higher to the benefit they get, and so they should be resisted like the harmful element they are.
Sadly, having an open and explicit CoC and governance structure gives these people a weapon to use against you. Now instead of dealing with your problem on a case-by-case basis, you will have third parties, who otherwise have no stake, interpreting your own CoC against you just to win some internet cred.
Re: Helping newcomers become contributors to open projects
#7Beware, 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.
Another is eat your own dogfood. If you enforce rules on others, enforce them on yourself. One project I keep an eye on and gave up trying to contribute to has users who berate others for something then turn around and do the same thing. If you make everyone else do code reviews. You do them too. If you want some sort of special spacing. Make the tools do it. Do not enforce them in code reviews. Teach the users how to setup the tools. Make a FAQ that shows how. Point people at it. You know where everything is, they dont.
Another pitfall I see is what I call 'claiming with neglect' where a user will claim something then let no one else touch it, usually in a pull request that someone put a bunch of time into. But then not do what they said they were going to do. Two years later the pull request dies on the vine and nothing changes. The person who made the request usually just wanders off due to lack of feedback.
Another is letting pull requests sit for years. Just set a max timeframe. If it does not go in that time close it. Do leave the person hanging. I get that happens on a dead project. But on a project that is obviously active? Give that pull request some love. Close it, tweak it, or merge it (something!).
Re: Helping newcomers become contributors to open projects
#8Some 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 task, don't micromanage them.
* Document your availability. If you have to step away from the project, put this at the top of the README, even if it's temporary. Don't drip-feed interaction - be either on or off.
* Be responsive to issues and pull requests. That doesn't mean accept everything, but answer quickly, even if just to say you need more time to look into it. Don't leave stale reviews open.
* 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.)
* On documentation: one example is worth a dozen descriptions. Check if your language offers you a way to combine documentation and unittests; this is of high worth - take full advantage.
* Have a style guide. Link it in the README. This saves you time in review.
* Set up CI. Nowadays, there's plenty of free services that integrate with Github, so there's really no reason not to.
(Combo bonus: CI with style check!)
Re: Helping newcomers become contributors to open projects
#9Open source projects (or any large collaboration) now have a new type of danger that many are unprepared to handle, in that there are people online who will shit on your work or make a giant spectacle that can ruin people just so that they can appear good in Twitter or make some kind of name for themselves in certain online circles. Similar to thieves who steal metal from railways, the damage they cause is far higher…
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".)
Re: Helping newcomers become contributors to open projects
#10Some 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…
> * Have a style guide. Link it in the README. This saves you time in review.
I would go even further and recommend using some automatic style formatter. That way, you can fail the CI step if the code is not correctly formatted and that problem is trivial to fix (just run the formatter).