Wikimedia is an organization which has both volunteers and paid folks working together in software development, with many software projects and different stakeholders involved.
In Wikimedia, there is currently some discussion how to improve the code review process. One aspect is reducing our code review queues and waiting times, with a focus on contributions provided by volunteers.
There are numerous successful free and open source software projects with a similar setup of companies and volunteers involved (Mozilla, Openstack, …) so I’m curious if your project has also investigated similar questions and if there is some knowledge and experience to share.
- In your project, do maintainers commit to review contributed patches in a certain timeframe, like “all patches receive a first review comment within four days”? How is this process implemented? Do you think it is successful?
- With an existing backlog of patches that did not manage to attract a review, what do you with ancient and rotting patches? Do you just abandon them after a certain timeframe in your code review tool to get a “cleaner slate”? Or do you leave them open to (theoretically) allow someone to find them and them pick up?
- Do you have any specific workflow in place that provides feedback to patch authors who contribute a patch to a rather unmaintained repositories that noone feels responsible for (anymore)? Do you signal the lack of maintainers and encourage contributors to step up as maintainers? How?
- Do you have a workflow in place to specifically prioritize the review of patches contributed by volunteers? How efficient is it?
I’d be very interested in hearing how your project handles these issues. Needless to say, links to documents are welcome. Thanks!
For PulseAudio:
> In your project, do maintainers commit to review contributed patches in a certain timeframe?
No, this is impossible for patches touching upon “scientific” areas that require specific knowledge (e.g. signal processing or control theory) from reviewers. In fact, “scientific” pieces of code are exactly those that attract bad contributions (and some of them, including the non-working equalizer, are, unfortunately, accepted).
> With an existing backlog of patches that did not manage to attract a review, what do you with ancient and rotting patches?
Tanu Kaskinen tries to review the backlog periodically, separately from fresh patches. So, old patches that are reviewable will eventually be reviewed.
> Do you have any specific workflow in place
Before May 2015, we had a PatchStatus wiki page that was maintained by Tanu. Now we have a Patchwork instance.
> Do you have a workflow in place to specifically prioritize the review of patches contributed by volunteers?
No.
(these answers are not official)