User:AKlapper (WMF)/Sandbox

TODO: Should use proper references to literature instead of inline. And all these topics are so mingled they are really hard to structure...

Influential factors
TODO: Split into: Contributor managing to create a patch (set up dev env, finding right place in code, docs and their size and findability, finding right feedback place); Factors for time to review and time to merge; Factors for likeliness to get the patch reviewed and merged

Factors: social, technical, organizational. Roles: contributor, reviewer. Aspects: Acceptance rate, number of revisions per patch before merge.


 * 1) Social: Time to review for first patch of a contributor is crucial
 * 2) Some patches need many iterations; takes time for everybody: Poor quality requires big effort and makes reviewers ignore instead of reviewing again and again with CR-1.
 * 3) Social: Prioritization / weak open source culture: more pressure to write new code than to review patches contributed?
 * 4) Social: Lack of sync between developer teams: team A stuck because team B doesn't review their patches?
 * 5) Organizational: Reviewer workload; too much on the plate already
 * 6) Organizational: Not enough reviewers in general?
 * 7) Organizational: Not enough people with CR+2 rights?
 * 8) Social/Organizational: Finding the right reviewer and making sure they are added; Unclear or no responsibilites: "Changes failing to capture a reviewer's interest remain unreviewed" (from: Rigby, Cleary, Painchaud, Storey, German: Contemporary Peer Review Action: Lessons from Open Source Development, 2012) due to self-selecting process of reviewers, or everybody expects another person in the team to review
 * 9) Organizational: Unclear responsibilites: Outdated documentation how to find maintainer to ping
 * 10) Technical: CR tool to allow a reviewer to notify them of patches in their areas of interest
 * 11) Social: Unmaintained repositories: Lack of owners / maintainers, or under-resourced
 * 12) Technical/Social: Unmaintained repositories: Lack of disclaimers for potential contributors
 * 13) Social: Time to review for first patch of a contributor is crucial

Potential actions

 * 1) CR tool to allow finding / explicitly marking first contributions. korma.wmflabs.org to list recent first contributions and their time to review
 * 2) Patches should be "small, independent, and complete". Stakeholders with different expertise areas to review aspects need to split reviewing parts of a larger patch.
 * 3) Introduce and foster routine / habit across developers to spend a certain amount of time each day for reviewing patches (or part of standup), and team peer review on complex / controversial patches
 * 4) Blocked-on-* projects in Phabricator?
 * 5) Tool support to propose reviewers or display on how many unreviewed patches a reviewer is already added so the author can choose other reviewers. Proposal to add reviewers to patches in "Suggestions to reduce code review backlog" but needs good knowledge of community members as otherwise creating noise; "two reviewers find an optimal number of defects - the cost of adding more reviewers isn't justified [...]"  (from: Rigby, Cleary, Painchaud, Storey, German: Contemporary Peer Review Action: Lessons from Open Source Development, 2012)
 * 6) Capacity building: Recognize contributors (supported by korma stats?) and "somehow" encourage them to become habitual and trusted reviewers; actively nominate to become maintainers (from: "Suggestions to reduce code review backlog")
 * 7) Review current CR+2 handout practice (cf. changes in numbers), total number of volunteers and staff plus ratio. Consider handing out code review rights to more volunteers? Recognize people not executing their CR+2 rights anymore. Related: Trust levels.
 * 8) Need for better tools to identify such areas within a codebase. Then clarify within teams. "Assign reviews that nobody selects." (from: Rigby, Cleary, Painchaud, Storey, German: Contemporary Peer Review Action: Lessons from Open Source Development, 2012). Share knowledge: There might be (old) code areas that only one or zero developers understand.
 * 9) Automate updating the outdated and manual Developers/Maintainers; publically documented (and findable) Team/Maintainer <-> Codebase/Repository relations.
 * 10) Existing via https://www.mediawiki.org/wiki/Gerrit/watched_projects but limited
 * 11) Need for better technical implementation to display information; allow contributor to act
 * 12) Structured patch review process: Three steps proposed by Sarah Sharp for maintainers / reviewers (from The Gentle Art of Patch Review), quoting:
 * 13) Is the idea behind the contribution sound? / Do we want this? Yes, no. If the contribution isn’t useful or it’s a bad idea, it isn’t worth reviewing further. Or “Thanks for this contribution!  I like the concept of this patch, but I don’t have time to thoroughly review it right now.  Ping me if I haven’t reviewed it in a week.” The absolute worst thing you can do during phase one is be completely silent.
 * 14) Is the contribution architected correctly? Squash the nit-picky, perfectionist part of yourself that wants to comment on every single grammar mistake or code style issue.  Instead, only include a sentence or two with a pointer to coding style documentation, or any tools they will need to run their contribution through.
 * 15) Is the contribution polished? Get to comment on the meta (non-code) parts of the contribution.  Correct any spelling or grammar mistakes, suggest clearer wording for comments, and ask for any updated documentation for the code
 * 1) Is the contribution polished? Get to comment on the meta (non-code) parts of the contribution.  Correct any spelling or grammar mistakes, suggest clearer wording for comments, and ask for any updated documentation for the code

Related pages

 * https://www.mediawiki.org/wiki/Manual:Coding_conventions
 * https://www.mediawiki.org/wiki/Gerrit/Code_review for reviewers
 * https://www.mediawiki.org/wiki/Gerrit/Code_review/Getting_reviews for authors (too long?)

T115852, T1287 - Unclear maintenance responsibilities for some parts of MediaWiki core repository

 * Related: Automate updating the outdated and manual Developers/Maintainers; publically documented (and findable) Team/Maintainer <-> Codebase/Repository relations.

Influential factors

 * 1) Social: Unclear responsibilites: everybody expecting another person to review
 * 2) Organizational: The last developer with knowledge of a code area has been moved to a different code area

Potential actions

 * 1) Need for better tools to identify such areas within a codebase. Then clarify within teams.

T113707 - SLA on time to review for CR

 * TODO: Nothing found in literature. Andre to blog.
 * Requires clear responsibilities who owns what.

T113706 - Cut-off date to abandon patches in CR

 * TODO: Nothing found in literature. Andre to blog.

Volunteer onboarding

 * "Make it easy to contribute by making the software easy to configure, build, and test to a known state. The more time you save outside developers that might be interested in contributing, the more time they have to work on the contribution they want to make, rather than losing time and possibly interest in trying to get past building the software." Stephen Walli in http://www.outercurve.org/blog/2013/04/11/GitSVNMercurial-and-Growing-a-FOSS-Community/

Hospitality and tone

 * cf. https://en.wikisource.org/wiki/Hospitality,_Jerks,_and_What_I_Learned
 * "the level of politeness in the communication process among developers does have an effect on the time required to fix issues and, in the majority of the analysed projects, it has a positive correlation with attractiveness of the project to both active and potential developers. The more polite developers were, the less time it took to fix an issue, and, in the majority of the analysed cases, the more the developers wanted to be part of project, the more they were willing to continue working on the project over time."; "Issue fixing time for polite issues is faster than issue fixing time for impolite issues for 10 out of 14 analysed projects."; "Findings. In the majority of projects Magnet and Sticky are positively correlated with Politeness."; ”Politeness is the practical application of good manners or etiquette. It is a culturally defined phenomenon and therefore what is considered polite in one culture can sometimes be quite rude or simply eccentric in another cultural context. The goal of politeness is to make all of the parties relaxed and comfortable with one another.” (from: Marco Ortu, Giuseppe Destefanis, Mohamad Kassab, Steve Counsell, Michele Marchesi, and Roberto Tonelli: Would you mind fixing this issue? An Empirical Analysis of Politeness and Attractiveness in Software Developed Using Agile Boards)
 * "Would you be interested in contributing a fix and a test case for this as well?" style instead of "this isn't the forum to clarify support requests"?; "The latest changeset isn't applying cleanly to git master anymore - could you resubmit it please?"

T78639 - Addressing the long tail of low priority tasks in active projects

 * TODO: Understanding the triaging and fixing processes of long lived bugs at http://www.sciencedirect.com/science/article/pii/S0950584915000531

Bounties / Crowdfunding

 * TODO
 * cf. T88265

Other related tasks

 * T114320, T114311 - CR migration to Differential
 * T114419 - Make CR not suck, especially for volunteers
 * T89907 - MW developer community governance model
 * T102920 - Unmaintained/inactive repos
 * T115659 - Collaboration on prioritization

Misc

 * Large single vendor governed FOSS projects tend to be controversial; non-profit foundations seem to be successful: http://openlife.cc/blogs/2010/november/how-grow-your-open-source-project-10x-and-revenues-5x
 * "Solid Engineering Practices + Strong Community Governance + Clear IP Management enables Growth." http://stephesblog.blogs.com/my_weblog/2015/03/why-openstack-is-different-from-other-open-source-projects.html
 * Magnetism and Stickiness: A project is Magnetic (magnetism) if it attracts new developers over time. A project is Sticky (stickiness) if it keeps its developers over time. (From: K. Yamashita, S. McIntosh, Y. Kamei, and N. Ubayashi. Magnet or sticky? an oss project-by-project typology. In MSR, pages 344–347, 2014.)
 * Magnetism is the portion of new active developers during the observed time interval, in our example 2/10 (dev 6 + dev 7 were active in 2011 but not in 2010).
 * Stickiness is the portion of active developers that were also active during next time interval, in our example 3/7 (dev 1, dev 2, dev 3 were active in 2011 and in 2012).
 * Covered by korma's Demographics page
 * Time to merge
 * OpenStack: Number of active core reviewers growing, 0% of the changesets that landed into master were merged in less than 3 days since the review process was opened. -- http://blog.bitergia.com/2015/10/15/efficiency-analysis-in-the-openstack-community-liberty-release/
 * Linux Kernel: 33% of the patches make it into the Linux kernel within 3-6 months; Factors are submission time, affected subsystems, number of requested reviewers (from: Will My Patch Make It And How Fast - Case Study on the Linux Kernel)