Code review in open source projects: Influential factors and actions

Posted on 2016-11-21 by aklapper

Coming from “Prioritizing volunteer contributions in free software development”, the Wikimedia Foundation allowed me to spend time on research about code review (CR) earlier in 2016. The theses and bullet points below incorporate random literature and comments from numerous people.
While the results might also be interesting for other free and open source software projects, they might not apply to your project for various reasons.

In Wikimedia we would like to review and merge better code faster. Especially patches submitted by volunteers. Code Review should be a tool and not an obstacle.
Benefits of Code Review are knowledge transfer, increased team awareness, and finding alternative solutions. Good debates help to get to a higher standard of coding and drives quality.[A1]

I see three dimensions of potential influential factors and potential actions (that often cannot be cleanly separated):

  • 3 aspects: social, technical, organizational.
  • 2 roles: contributor, reviewer.
  • 3 factors: Patch-Acceptance/Positivity-Likeliness, Patch-Time-to-review/merge, Contributor onboarding (not covered here).

In general, “among the factors we studied, non-technical (organizational and personal) ones are betters predictors” (means: possible factors that might affect the outcome and interval of the code review process) “compared to traditional metrics such as patch size or component, and bug priority.”[S1]

Note that Wikimedia plans to migrate its code review infrastructure from Gerrit to Phabricator Differential at some point.

Unstructured review approach

An unstructured review approach potentially demotivates first patch contributors, but fast and structured feedback is crucial for keeping them engaged.

Set up and document a multi-phase, structured patch review process for reviewers: Three steps proposed by Sarah Sharp for maintainers / reviewers[A2], quoting:

  • Fast feedback whether it is wanted: 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.[A2]
  • Architecture: 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.[A2]
  • Polishing: 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[A2]

Lack of enough skillful, available, confident reviewers and mergers

Not enough skillful or available reviewers and potential lack of confident reviewers[W1]? Not enough reviewers with rights to actually merge into the codebase?

  • Capacity building: Discuss consider handing out code review rights to more (trusted) volunteers by recognizing active users who mark patches as good-to-go or needs-improvement (based on statistics)? Encourage them to become habitual and trusted reviewers; actively nominate to become maintainers[W2]? Potentially recognize people not executing their code review rights anymore. Again this requires statistics (to identify very active reviewers) and stakeholders (to decide on nominations).
  • Review current code review patch approval handout practice (see Wikimedia’s related documentation about +2 rights in Gerrit).
  • Consider establishing prestigious roles for people, like “Reviewers”?[W3]
  • “we recommend including inexperienced reviewers so that they can gain the knowledge and experiences required to provide useful comments to change authors”[S2]; Reviewers who have prior experience give more useful comments as they have more knowledge about design constraints and implementation.[S2]

Under-resourced or unclear responsibilities

Lack of repository owners / maintainers, or under-resourced or unclear responsibilities when everyone expects someone else to review. (For the MediaWiki core code repository specifically, see related tasks T115852 and T1287.)

“Changes failing to capture a reviewer’s interest remain unreviewed”[S3] due to self-selecting process of reviewers, or everybody expects another person in the team to review. “When everyone is responsible for something, nobody is responsible”[W4].

  • Have better statistics (on proposed patches waiting for review for a long time) to identify unmaintained areas within a codebase or codebases with unclear maintenance responsibilities.
  • Define a role to “Assign reviews that nobody selects.”[S3] (There might be (old) code areas that only one or zero developers understand.) Might need an overall “Code Review wrangler” position similar to a Bugwrangler/Bugmaster.
  • Clarify and centrally document which Engineering/Development/Product teams are responsible for which codebases, and Team/Maintainer ⟷ Codebase/Repository relations (Example: “How Wikimedia Foundation’s Reading team manages extensions”)
  • Actively outreach to volunteers for unmaintained codebases via Requesting repository ownership? Might need an overall “Code Review wrangler” position similar to a Bugwrangler/Bugmaster.
  • Advertise a monthly “Project in need of a maintainer” campaign on a technical mailing list and/or blog posts?

Hard to identify good reviewer candidates

Hard for new contributors to identify and add good reviewers.

“choice of reviewers plays an important role on reviewing time. More active reviewers provide faster responses” but “no correlation between the amount of reviewed patches on the reviewer positivity”.[S1]

  • Check “owners” tool in Phabricator “for assigning reviewers based on file ownership”[W5] so reviewers get notified of patches in their areas of interest. In Gerrit this exists but is limited.
  • Encourage people to become project members/watchers.[W6]
  • Organization specific: Either have automated updating of outdated manual list of Developers/Maintainers, or replace individual names on the list of Developers/Maintainers by links to Phabricator project description pages.
  • In the vague technical future, automatic reviewer suggestion systems could help[S2], like automatically listing people who lately touched code in a code repository or related tasks in an issue tracking system and the length of their current review queue. (Proofs of concept have been published in scientific papers but code is not always made available.)

Unhelpful reviewer comments

Due to unhelpful reviewer comments, contributors spend time on creating many revisions/iterations before successful merge.

  • Make sure documentation for reviewers states:
    • Reviewers’ CR comments considered useful by contributors: identifying functional issues; identifying corner cases potentially not covered; suggestions for APIs/designs/code conventions to follow.[S2]
    • Reviewers’ CR comments considered somewhat useful by contributors: coding guidelines; identifying alternative implementations or refactoring[S2]
    • Reviewers’ CR comments considered not useful by contributors: Authors consider reviewers praising on code segments, reviewers asking questions to understand the implementation, and reviewers pointing out future issues not related to the specific code (should be filed as tasks) as not useful.[S2]
    • Avoid negativity and ask the right questions the right way. As a reviewer, ask questions instead of making demands to foster a technical discussion: “What do you think about…?” “Did you consider…?” “Can you clarify…?” “Why didn’t you just…” provides a judgement, putting people on the defensive. Be positive.[A1]
    • If you learned something or found something particular well, give compliments. (As code review is often about critical feedback only.)[A1]
    • Tool specific: Agree and document how to use Gerrit’s negative review (CR-1): “Some people tend to use it in an ‘I don’t like this but go ahead and merge if you disagree’ sense which usually does not come across well. OTOH just leaving a comment makes it very hard to keep track – I have been asked in the past to -1 if I don’t like something but don’t consider it a big deal, because that way it shows up in Gerrit as something that needs more work.”[W7]
    • Stakeholders with different expertise areas to review aspects need to split reviewing parts of a larger patch.

Weak review culture

Prioritization / weak review culture: more pressure to write new code than to review patches contributed? Code review “application is inconsistent and enforcement uneven.”[W8]

  • Introduce and foster routine and 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 patches[A1].
  • Write code to display “a prominent indicator of whether or not you’ve pushed more changesets than you’ve reviewed”[W9]?
  • Technical: Allow finding / explicitly marking first contributions by listing recent first contributions and their time to review on korma’s code_contrib_new_gone in T63563. Someone responsible to ping, follow up, and (with organizational knowledge) to add potential reviewers to such first patches. Might need an overall “Code Review wrangler” position similar to a Bugwrangler/Bugmaster.
  • Organization specific: Contact the WMF Team Practices Group about their thoughts how this can be fostered?

Workload of existing reviewers

Workload of existing reviewers; too many items on their list already.

Reviewer’s Queue Length: “the shorter the queue, the more likely the reviewer is to do a thorough review and respond quickly” and the longer the more likely it takes longer but “better chance of getting in” (due to more sloppy review?)[S1].

  • Code review 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[W2] but this requires already good knowledge of the community members as otherwise it just creates more noise.
  • Potentially document that “two reviewers find an optimal number of defects – the cost of adding more reviewers isn’t justified […]”[S3]
    • Documentation for reviewers: “we should encourage people to remove themselves from reviewers when they are certain they won’t review the patch. A lot of noise and wasted time is created by the fact that people are unable to keep their dashboards clean”[WA]
  • Tool specific: Gerrit’s negative review (CR-1) gets lost when a reviewer removes themselves (bug report) hence Gerrit lists (more) items which look unreviewed. Check if same problem exists in Phabricator Differential?
  • Tool specific: Agree whether ‘Patch cannot be merged due to conflicts; needs rebasing’ should be a reason to give CR-1[WB] in order to get a ‘cleaner’ list? (But depending on the Continuous Integration infrastructure tools of your project, such rejection via static analysis might happen automatically anyway.)

Poor quality of contributors’ patches

Due to poor quality of contributors’ patches, reviewers spend time on reviewing many revisions/iterations before successful merge. Might make reviewers ignore instead of reviewing again and again giving yet another negative CR-1 review.

  • Make sure documentation for contributors states:
    • Small, independent, complete patches are more likely to be accepted.[S4]
    • “[I]f there are more files to review [in your patch], then a thorough review takes more time and effort”[S2] and “review effectiveness decreases with the number of files in the change set.”[S2]
    • Small patches (a maximum of 4 lines changed) “have a higher chance to be accepted than average, while large patches are less likely to be accepted” (probability) but “one cannot determine that the patch size has a significant influence on the time until a patch is accepted” (time)[S5]
    • Patch Size: “Review time [is] weakly correlated to the patch size” but “Smaller patches undergo fewer rounds of revisions”[S1]
    • Reasons for rejecting a patch (not all are equally decisive; “less decisive reasons are usually easier to judge” when it comes to costs explaining rejections):[S6]
      • Problematic implementation or solution: Compilation errors; Test failures; Incomplete fix; Introducing new bugs; Wrong direction; Suboptimal solution works but there is a more simple or efficient way); Solution too aggressive for end users; Performance; Security
      • Difficult to read or maintain: Including unnecessary changes (to split into separate patch); Violating coding style guidelines; Bad naming (e.g. variable names); Patch size too large (but rarely matters as it’s ambiguous – if necessary it’s not a problem); Missing docs; Inconsistent or misleading docs; No accompanied test cases (When should “No accompanied test cases” be a reason for a negative review? In which cases do we require unit tests?[W4] This should be more deterministic); Integration conflicts with existing code; Duplication; Misuse of API; risky changes to internal APIs; not well isolated
      • Deviating from the project focus or scope: Idea behind is not of core interest; irrelevant or obsolete
      • Affecting the development schedule / timing: Freeze; low urgency; Too late
      • Lack of communication or trust: Unresponsive patch authors; no discussion prior to patch submission; patch authors’ expertise and reputation[S6]
      • cf. Reasons of the Phabricator developers why patches can get rejected
    • There is a mismatch of judgement: Patch reviewers consistently consider test failures, incomplete fix, introducing new bugs, suboptimal solution, inconsistent docs way more decisive for rejecting than authors.[S6]
    • Propose guidelines for writing acceptable patches:[S6]
      • Authors should make sure that patch is in scope and relevant before writing patch
      • Authors should be careful to not introduce new bugs instead of only focussing on the target
      • Authors should not only care if the patch works well but also whether it’s an optimal solution
      • Authors should not include unnecessary changes and should check that corner cases are covered
      • Authors should update or create related documentation[S6] (for Wikimedia, see Development policy)
    • Patch author experience is relevant: Be patient and grow. “more experienced patch writers receive faster responses” plus more positive ones. In WebKit, contributors’ very first patch is likely to get positive feedback while for their 3rd to 6th patch it is harder.[S1]
  • Agree on who is responsible for testing and document responsibility. (Tool specific: Phabricator Differential can force patch authors to fill out a test plan.)[W7]

Likeliness of patch acceptance depends on: Developer experience, patch maturity; Review time impacted by submission time, number of code areas affected, number of suggested reviewers, developer experience.[S7]

Hard to realize a repository is unmaintained

Hard to realize how (in)active a repository is for a potential contributor.

  • Implement displaying “recent activity” information somewhere in the code repository browser and code review tool, to communicate expectations.
  • Have documentation that describe steps how to ask for help and/or take over maintainership, to allow contributors to act if interested in the code repository. For Wikimedia these docs are located at Requesting repository ownership.

No culture to improve changesets by other contributors

Changesets are rarely picked up by other developers[WB]. After merging, “it is very difficult to revert it or to get original developers to help fix some broken aspect of a merged change”[WB] regarding followup fixing culture.

  • Document best practices to amend a change written by another contributor if you are interested in bringing the patch forward.

Hard to find related patches

Hard to find existing “related” patches in a certain code area when working on your own patch in that area, or when reviewing several patches in the same code area. (Hence there might also be some potential rebase/merge conflicts[WB] to avoid if possible.)

  • Phabricator Differential offers “Recent Similar Open Revisions”.[WC] Gerrit might have such a feature in a newer version.[WD]

Lack of synchronization between teams

Lack of synchronization between developer teams: team A stuck because team B doesn’t review their patches?

  • Organization specific: Wikimedia has regular “Scrum of Scrum” meetings of all scrum masters across teams, to communicate when the work of a team is blocked by another team.

Comment which important factors that you have experienced are missing!

References

Posted in computer, lang-en, metrics, phabricator, wikimedia | 2 Comments

Restricting cookies vs. using Google Hangouts

Posted on 2016-09-09 by aklapper

No idea if this is useful to anyone but it was an interesting exercise.

By default I have disabled storing cookies in my main web browser. I have a custom list of specific web sites that I allow to set cookies. (Whether that makes any sense regarding all the other data your browser sends which might create a unique fingerprint anyway is a different question up to your personal judgement/opinion on “privacy” and not the topic here.)

Ideally that whitelist would only include web sites that use my data in a way that I can agree with. In reality, services exist that could either be considered convenient (like Facebook; if you want to use their services you could use a private browser session every time and reenter your password, or use a separate browser to isolate Facebook’s cross-site cookie pollution) or services that your employer or customers use or expect for whatever reasons.

Google Hangouts video calls and Google Hangout text chats (which are proprietary after dropping XMPP) are used by some of my co-workers.
I have been wondering for a while which specific Google sites to allow setting cookies in order to be able to use these services but could not find information on the web. Google lists a bunch of domains but that list seems neither specific nor complete.
Going for trial and error, I removed any Google cookies (which might require more than a simple string search due to sites such as accounts.youtube.com), removed any potential rules allowing Google cookies, set my browser to not allow any cookies, and see how far I can make it working around random error messages and getting logged out immediately after having logged in.

I ended up allowing the sites accounts.google.com, client-channel.google.com, clients[1-6].google.com, hangouts.google.com, people-pa.clients[1-6].google.com, plus.google.com, talkgadget.google.com to set cookies. Some of these were trickier to find but your web browser’s developer tools allow you to check which sites want to set cookies.

And now back to actual work.

Posted in computer, lang-en | 4 Comments

Rewriting code review documentation, on paper.

Posted on 2016-09-05 by aklapper

At Wikimedia, for the last months I’ve been on and off rewriting our on-wiki technical Gerrit/Git/Code Review documentation.

Code review related documentation

That included improving the onboarding steps like setting up Git and Gerrit (related task; 135 edits), the contribution guidelines and expectations for patch authors (related task; 28 edits), and to some extent the guidelines for patch reviewers (related task; 23 edits).

Among the potential next steps there is agreeing on a more structured, standardized approach for reviewing code contributions. That will require engineering and development to lead efforts to have teams follow those guidelines, to establish a routine of going through unreviewed patches, and other potential iterative improvements.

Printed documentation.

On paper

I’m not a person carrying around a laptop and don’t use mobile phones much. The more text/comments to tackle (or seperate pages covering related topics), the more I prefer working on paper. (That’s also how I started high-level planning the GNOME Evolution user docs rewrite.)
It might be archaic but paper allows me to get an overview of several pages/documents at the same time. (I could probably also buy more or bigger screens?) I can mark and connect sections that are related and should not be in four different places (like Troubleshooting related information or operating system specific instructions). Plus trying to be accountable and transparent I end up performing lots of small atomic changes with a proper change summary message so I can cross out sections on paper that are done on the wiki.
Paper especially works for me when thinking about topics that still require finding an approach. So I end up in the park or in a pub.

In a future blog post I’m going to cover what I’ve learned about aspects and issues of code review.

Posted in computer, lang-en, user-documentation, wikimedia | Comments Off on Rewriting code review documentation, on paper.

GUADEC 2016.

Posted on 2016-08-13 by aklapper

Filthy attempts on the unconference session scheduling whiteboard by so-called “friends” trying to trick me into literally ‘something’.
They won’t succeed.

#makeandrenevertalkagain #noicecreamleftbehind

Posted in computer, gnome, lang-en | Comments Off on GUADEC 2016.

Travel.

Posted on 2016-06-17 by aklapper

Middle East

In late March 2016, I attended some Wikimedia gatherings in the Middle East: The WikiArabia conference in Amman (Jordan), a Technical Meetup in Ramallah (Palestinian territories), and the Wikimedia Hackathon in Jerusalem (Israel).

Your browser cannot play HTML5 video. Download it.


(Video above by Victor Grigas [CC BY-SA 3.0], via Wikimedia Commons)

I gave an introduction to the many technical areas in Wikimedia anyone can contribute to. I also gave an introduction how to use Phabricator, the project management suite used (for mostly technical aspects) by the Wikimedia community which allows managing and following progress in projects and collaborating with developers.

Your browser cannot play HTML5 video. Download it.


(Video above by Victor Grigas [CC BY-SA 3.0], via Wikimedia Commons)

As I love discussing society and politics I was not sure initially how much I’d have open and blunt conversations. But on the first evening I was already sitting together with folks from Tunesia, Egypt and Saudi-Arabia who were comparing the situations in their home countries. People also allowed me to learn a little bit about how daily life is in Iraq or Saudi-Arabia.

Petra

Petra

After a short trip to Petra, we spent an entire day to get to and cross the border between Jordan and the West Bank. If you look at the mere distance it feels ridiculous. It definitely makes you appreciate open borders.

At the border crossing between Jordan and the West Bank

At the border crossing between Jordan and the West Bank

Afterwards, we were very lucky that Maysara (one of our hosts) took the time and his car to drive us around in the Westbank to visit a bunch of spots, pass settlements, look at walls, or wonder which streets to take (sometimes a checkpoint with a soldier pointing a machine gun at you helps making decisions).

The old city center of Nablus

The old city center of Nablus

Graffiti on graffiti in Ramallah

Graffiti on graffiti in Ramallah

At some point, Maysara simplified it in a single quoted sentence: For Israelis it’s fear. For Palestinians it’s humiliation.

Street sign in the West Bank

Street sign in the West Bank

Imagery of dead fighters in Nablus

Imagery of dead fighters in Nablus

In Israel, we walked through Jerusalem’s old town, visited Masada and took a bath in the Dead Sea.

Dead Sea: Past war zones

Dead Sea: Past war zones

View from Masada

View from Masada (the squares were siege camps)

On the last day I visited the Yad Vashem Holocaust memorial with some co-workers (thanks to Moriel for organizing it). It’s obviously an activity you cannot “look forward to”. I am still impressed by our guide who explained and summarized history extremely well.
The architecture of Yad Vashem makes you go through several rooms on the left and right of the passageway in a chronological way and our guide mentioned several times that you “cannot yet see what is coming a few rooms (means: a few years) later”, and the question “Why did Jewish citizens not flee” got answered by “Where would you try to escape to if even outside of ghettos and concentration camps everybody is hostile”. Which explained very well the self-understanding why to found a state for Jews.

I am incredibly thankful to those many great people I could meet and who shared their points of views on the social and political situation, always in a pretty reflected and respectful way despite of all the frustration being around.
And whatever my question was to locals, the answer pretty much always was “It’s more complicated than you thought.”

India

Afterwards I spent some time in India to attend Rootconf, visit GeekSkool to learn a lot about why the concept works, and attend GNOME.Asia (thanks to Shobha and everybody organizing it!).

Hardware recycling via badge lanyards

Hardware recycling via badge lanyards

Breakdance competitions

Breakdance competitions

In a society where the path of welfare could be expressed by “walk → motorbike → car”, I received some grins admitting I had never had a motorbike ride before. In Indian traffic I’d call that an experience, for a tourist like me.

GNOME.Asia 2016 venue

GNOME.Asia 2016 venue

GNOME.Asia 2016 music

GNOME.Asia 2016 music

As usual, it’s wonderful to finally meet folks in person who you’ve only spoken to online beforehand, and to hang out with old friends. (I sound like a broken record here. I am sorry I could not see everybody. I’ll be back.)

Posted in gnome, lang-en, misc, non-technical, politics, wikimedia | Comments Off on Travel.

War Porn.

Posted on 2016-02-12 by aklapper

Photo of the book.

Sometimes, when some individual, group, institution publishes, releases, leaks a cruel video of this planet’s conflicts, media decide not to show it or only show a (edited) screenshot.
I usually end up trying to find the uncut video on the internet because I naively believe I can better realize how cruel things are when I force myself to watch it.
So I constantly feel the need to defend my behavior against accusations of voyeurism and dehumanization: “Can’t you imagine the rest anyway? Haven’t you played video games and watched enough fictitious movies?”

A few months ago I bought the photo book “War Porn” by Christoph Bangert (a photo journalist in war regions). The photos are somewhere between disturbing and disgusting.
Bangert also covers the aspect of self-censorship as a photographer or publisher, hence for some of the pages you have to decide yourself whether to break the perforation to see the image included on that page.

The book’s introduction puts it into simple words that I could not find myself:
“What’s the point of showing these things? We know that wars and disasters are horrible events. But are we really aware of just HOW horrible they are? Yes? Why are we so shocked by these pictures, then?”

Posted in lang-en, non-technical, politics | 2 Comments

Wikimedia in Google Code-in 2015

Posted on 2016-01-28 by aklapper

(Google Code-in and the Google Code-in logo are trademarks of Google Inc.)

Google Code-in 2015 is over. As a co-admin and mentor for Wikimedia (one of the 14 organizations who took part and provided mentors and tasks) I can say it’s been crazy as usual. :)

To list some of the students’ achievements:

  • More than a dozen of MediaWiki extensions converted to using the extension registration mechanism
  • Confirmation dialogs in UploadWizard and TimedMediaHandler use OOjs-UI
  • Vagrant roles created for the EmbedVideo and YouTube extensions
  • Two more scraping functions in the html-metadata node.js library (used by Citoid)
  • Many MediaWiki documentation pages marked as translatable
  • lc, lcfirst, uc and ucfirst magic words implemented in jqueryMsg
  • Screenshots added to some extension homepages on mediawiki.org
  • ReCaptchaNoCaptcha of the ConfirmEdit extension uses the UI language for the captcha
  • MobileFrontend, MultimediaViewer, UploadWizard, Newsletter, Huggle, and Pywikibot received numerous improvements (too many to list)
  • Long deprecated wfMsg* calls were removed from many extensions
  • The CommonsMetadata extension parses vcards in the src field
  • The MediaWiki core API exposes “actual watchers” as in “action=info”
  • MediaWiki image thumbnails are interlaced whenever possible
  • Kiwix is installable/moveable to the SD card, automatically opens the virtual keyboard for “find in page”, (re)starts with the last open article
  • imageinfo queries in MultimediaViewer are cached
  • The Twinkle gadget‘s set of article maintenance tags was audited and its XFD module has preview functionality
  • The RandomRootPage extension got merged into MediaWiki core
  • One can remove items from Gather collections
  • A new MediaWiki maintenance script imports content from text files
  • Pywikibot has action=mergehistory support implemented
  • Huggle makes a tone when someone writes something
  • Many i18n issues fixed and strings improved
  • Namespace aliases added to MediaWiki’s export dumps
  • The Translate extension is compatible with PHP 7
  • …and many, many, more.

Numerous GCI participants also blogged about their GCI experience with Wikimedia:

The Grand Prize winners and finalists will be announced on February 8th.

Congratulations to our many students and 35 mentors for fixing 461 tasks, and thank you for your hard work and your contributions to free software and free knowledge.
See you around on IRC, mailing lists, Phabricator tasks, and Gerrit changesets!

Graph with weekly numbers of Wikimedia GCI tasks

Posted in computer, lang-en, wikimedia | 2 Comments

2015: Music.

Posted on 2016-01-22 by aklapper

Publishing my usual list of awkward and never complete pop music preferences of 2015.

Grimes’ “Art Angels” is probably my favorite album of 2015. Halsey’s “Badlands” debut and the latest releases by Purity Ring and Chvrches came close.

In general Angel Haze was the most dominant artist in my playlist. I also enjoyed Little Simz’ “A Curious Tale of Trials + Persons” debut and FKA Twigs’ “M3LL155X”.

Other helpful artists were We are Twin, Leftfield (with a surprisingly great 2015 release), Lowell, TĀLĀ, Camila Moreno, and Tei Shi, and Autobahn.

Posted in lang-en, music, non-technical | 1 Comment

Google Code-in 2015 has started!

Posted on 2015-12-08 by aklapper
(Google Code-in and the Google Code-in logo are trademarks of Google Inc.)

Another round of Google Code-in started yesterday. Together with Nemo and Petr I am one of the organization administrators for the Wikimedia community.

In this year’s edition of Google Code-in, students can choose from tasks provided by the following organizations / projects: Apertium, Copyleft Games, Drupal, FOSSASIA, Haiku, KDE, MetaBrainz, OpenMRS, RTEMS, SCoRe, Sugar Labs, Systers, Ubuntu, and Wikimedia.

If you are a 13-17 year old pre-university student interested in getting involved into free and open source software development, check out Google Code-in.
It is a great opportunity to learn about distributed software projects, to find out which areas of software development you are interested in, to gather some on-hands experience, to contribute to “real” projects out there used by millions of people, and to make new friends all over the world.

Posted in computer, gnome, lang-en, wikimedia | Comments Off on Google Code-in 2015 has started!

Prioritizing volunteer contributions in free software development

Posted on 2015-12-01 by aklapper

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!

Posted in computer, lang-en, metrics, wikimedia | 1 Comment