User:AKlapper (WMF)/Sandbox

= Misc Community Health related thoughts =

All those topics

 * Blog about them!
 * Wikimedia Foundation service-level agreement on code review times
 * Define Cut-off date for abandoning old changesets in our code review tool
 * Reduce code review queues and waiting times - Our code review practices are not common across reviewers and don't focus on efficiency
 * prioritize code review of patches submitted by volunteers - Volunteers having a hard time getting their contributions reviewed, also in active repos
 * Make code review not suck, especially for volunteers


 * Prioritization / weak open source culture: more pressure to write new code than to review patches contributed?
 * Unmaintained repositories: lack of owners is a problem, lack of disclaimers for potential contributors to these repos too. (T102920)
 * "Can we make turn around time on first patch review even shorter?"
 * Lack of sync between developer teams: team A stuck because team B doesn't review their patches?
 * Volunteers contributing patches in areas that are basically unmaintained or clearly under-resourced.
 * Plenty of repos not used by Wikimedia and basically unmaintained with 1-2 forgotten patches, deforming lists and metrics.
 * Poor quality of patches requiring a lot of effort to push forward, making reviewers to pass instead of review with -1.
 * Give code review rights to more volunteers on more projects?
 * Gamification?
 * Politeness? --- "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)
 * Growth has both social and technical ones
 * "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?"

Stats on 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)

The long tale of low priority issues

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

Sarah Sharp's Three patch review steps
Check list by Sarah Sharp for maintainers / reviewers (from The Gentle Art of Patch Review):
 * 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.
 * “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.
 * 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.
 * 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

Our docs:
 * https://www.mediawiki.org/wiki/Gerrit/Code_review and subpages

Interesting definitions
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).
 * 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:

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
 * "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/