There's just one rule which does it for me:
Thanks for your bug report! The next step is to submit a patch fixing the bug. If you need help, ask questions in our chat room at...
Helping newcomers become contributors to open projects
21–30 of 99 posts
Re: Helping newcomers become contributors to open projects
#22What do you do when the owner of the repository just ignores your pull request? I put hard work into some improvements and I would also change and adapt them to the repository owner's liking, but he just doesn't reply. He doesn't even say he doesn't have time, he's just completely absent. (And yes, the library is very popular and used by many) It's annoying because I depend on that library, so now I have to depend on…
I had a similar experience. I sent in a bug fix and some new features. The maintainer partially accepted my fix and ignored the other patches. After many messages and additional work, he just said the features would not be added to the project and that I was free to maintain my own version.
Sometimes it's better to just let go.
Re: Helping newcomers become contributors to open projects
#23Beware, 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 enou…
The general rule is that a project shouldn't need a code of conduct. A code of conduct outlines basic decency rules in which case, if it gets to the point that the project needs to be explicit about them to keep a good ambiance, that project has deeper seated issues.
Codes of conduct are great when the etiquette is ambiguous. Open source projects are not one of those.
When the users are in the wrong, you should be able to kick them out uncontroversially. And when the maintainers are in the wrong... They tend to ignore their own CoC anyway. Speaking from experience, I've tried contributing to a particular PSF project in the past, adding a feature to support a use case the maintainer did not like (supporting tab indent option in a code formatter), which was ignored and closed; and when I pointed out to the maintainer that his behaviour was in breach of the CoC, that too was ignored. What are you gonna do? In the end I had to fork the project.
Re: Helping newcomers become contributors to open projects
#24Open 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…
On the flip side, I have written things that got significantly more attention that I had expected and probably came across to the project maintainers as hating on their work–and that is with multiple drafts to make it clear that this wasn't my intention. There might be random people who like to persecute individuals and their work for no good reason, but even harder to deal with are the people who have been invested in the project before and you've made unhappy; doubly so if you've reached the point where you're not interested in having certain conversations and your governance structure makes it difficult for them to feel heard. Really, this is not a simple problem and I think it's more nuanced than "people will take your Code of Conduct and use it to nitpick you and call your work stupid on the internet", when there's a whole spectrum of "this maintainer has been closing all conversations of a contentious topic by citing the governance structure" to "we made an unpopular but necessary decision that we did not explain well enough and that's causing everyone to come out of the woodwork to harass us".
Re: Helping newcomers become contributors to open projects
#25Some 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…
> Document how to build and run it.
This, especially in non-web repos (C/C++) is common mistake of READMEs and docs.
Let's take an example of XFCE-WM project [0]. The main README does not include any information how to compile it, nor provides any link to the documentation how to build this very specific code. If you will google it you might find following wiki page [1], which is general for all repositories. In the COMPOSITOR [2] file you might notice some information about flags that you can provide during building, and that's great such doc has been created, but except that document I couldn't find any information how "fresh contributor" would like to debug and test some change in code that he made in the cloned repository. Download and install some linux distro on virtual machine and then invest (1h+) to configure it accordingly to run it there? Use Xephyr (I guess "fresh contributor" has never heard about this tool)?
In my honest experience, the "how to build" step is probably included in many of repositories, but the "how-to-run" is usually lacking in READMEs and it is what I really would like to see in complex projects (e.g. desktop environment).
> 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.
One more thing related to docs and "how-to-build-&-run" thing. Let's say the project owner have some critical accident that made him unavailable to push progress of development forward for few months or longer. If there isn't any knowledge shared (docs, other contributors) then I guess the project will be stalled and possibly forgotten if there is no clear incentive to use alternative methods of repo maintenance (e.g. fork).
[0]: https://github.com/xfce-mirror/xfwm4
[1]: https://docs.xfce.org/xfce/building
[2]: https://github.com/xfce-mirror/xfwm4/blob/master/COMPOSITOR
Re: Helping newcomers become contributors to open projects
#26Some 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. And don't lock them as stale once closed. Holy shit, it's infuriating seeing projects abuse what is essentially an anti-harrasment tool to prevent people from…
You can learn about a maintainer's experience with closed issues that keep being bumped here: https://www.henryzoo.com/an-issue-with-issues/
Even though I'm maintaining Lock Threads [1], I sometimes shake my head when I come across a closed issue that was locked by it, but I also have to admit that all I want is to ask a question quickly and get the information I need, without considering how my shortcuts affect maintainers.
There may be times when there's a legitimate reason for commenting on a long-resolved issue, but unfortunately most of the comments on closed issues are low effort support requests. Locking them as resolved is the best solution we have so far to avoid spending our time retriaging closed issues.
Re: Helping newcomers become contributors to open projects
#27What do you do when the owner of the repository just ignores your pull request? I put hard work into some improvements and I would also change and adapt them to the repository owner's liking, but he just doesn't reply. He doesn't even say he doesn't have time, he's just completely absent. (And yes, the library is very popular and used by many) It's annoying because I depend on that library, so now I have to depend on…
You first submit an issue where you ask if the maintainer(s) would be open for a PR. That way you wont waste any time building something that might be ignored.
Re: Helping newcomers become contributors to open projects
#28Beware, 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.
Re: Helping newcomers become contributors to open projects
#29Don't steal their PRs and commit them as your own.
Re: Helping newcomers become contributors to open projects
#30Open 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…
It's infuriating to see those complaining about very real barriers to contribution or actual abuses smeared as "rail thieves". For example, the percieved gender of the submitter making a difference to pull request acceptance rates: https://peerj.com/articles/cs-111/
...by a very small margin.
It's hard to determine how maintainer preceived the submitter's gender, so they tested for how they could have perceived instead (availability of identifying information - and even that is very hard to determine and limited the sample size).
Looking at the big picture, a lot of pull requests are accepted from both genders.
I'd be concerned if the difference was >20%, but 4% with all the listed limitations in the study doesn't get me excited.