Archive for May, 2014

RE: Outreach Program for Women

Friday, May 30th, 2014

Started writing this posting four weeks ago. Time to publish, seeing the latest blogposts by Philip and Marina on Planet GNOME about the Outreach Program for Women (OPW).

First things first (so you can stop reading if you disagree here):

  • If you question Outreach Programs in general: I consider diversity an important goal in distributed software development communities.
  • If you dislike that the Outreach Program for Women only targets people who do not define themselves as male and that it does not target different or other minority groups in a community: I don’t see why you have to try to cover all possible aspects when you start tackling a problem. I will not stop anybody from setting up an Outreach program for <insert language/region><insert ethnicity><insert economical class><insert sexual orientation or gender self-understanding><insert disability><insert religion><insert what I’ve forgotten> folks. That might be some work though and not just talking and criticizing from the sidelines. ;)

Outreach programs need to scale and be sustainable to be a long-term success. Is that the case? I’m not sure myself; depends on the criteria you come up with.

Scale

As Jim wrote, “the program grew to a size that overwhelmed our administrative staff person” (to simplify it).
Outreach Programs need to run without putting the GNOME Foundation or any other involved entity into financial or legal problems. I don’t follow closely enough, so I wonder if GNOME Foundation and organizations taking part in OPW have considered creating a separate legal entity with a dedicated mission to facilitate more diversity in free and open source software projects (as OPW has grown and is bigger than what GNOME is about)?

Sustainability

Do OPW participants (and GSoC participants) keep participating in our community after OPW is over, and do some become mentors themselves? (And if participants had sufficient time and financial resources, would they also participate if no money was offered?)
I consider the GNOME Documentation project to be a rather successful project keeping OPW’ers involved: Of those 14 OPW participants who worked on GNOME documentation, 6 pretty much vanished after OPW. 2 have mentored, 2 will likely mentor soon, and the rest is still around or around a bit. I don’t have numbers to compare and interpret (Marina posted some) but other GNOME teams feel less successful to me.
I’ve been wondering why. I’m sure others see other criteria and practices and I have not investigated other organizations who take part in OPW – feel free to add your impressions to the comments.

What to consider best practices?

  • Responsibility: GNOME includes dozens of software applications. The user documentation area provides identifiable smaller chunks (“the help files for application XY”). If you can well-define what your “area” is and others can recognize your area, you might get the feeling that others in the project rely on you and your work. You will be rewarded with responsibility (if such intrinsic motivation works for you) as you progress and prove that you are capable. An encouraging tone (“your patch is nearly ready, there are just a few smaller issues to fix”) and getting patch reviews from numerous persons instead of a single point of failure makes you realize that many people are interested in and follow your contributions.
  • Peer group size: The GNOME docs team has its IRC channel (#docs on GIMPnet IRC) with an overviewable peer group size. It might be less intimidating and overwhelming to ask your question into the void on such an IRC channel than on a channel with hundreds of people. It’s also easier to create friendship and trust than in larger channels. But when there are some non-doc related questions coming up, you are asked to interact and become involved with other members and teams of the larger community, in public. If you see that the rest of the community is also friendly and welcoming, you form further ties and friendships that make it attractive to stay.
  • Visibility: After you got accepted in an outreach program you get added to Planet GNOME (a website that aggregates blogs of GNOME community members) and are expected to write regular blogposts. (I hope there is some backpatting via blog comments that your work is appreciated but I’m sure this is an area where every community can improve.)
    GNOME wants you as an outreach program participant to attend GNOME’s annual GUADEC conference so you are provided partial sponsorship for travel costs (partial to avoid freeriding mentality and as GNOME isn’t rich). You will have to give a short presentation about your work. Latest GUADECs had a dedicated session for it with no other talks running in parallel – no excuses for missing it.
  • Learning curve: Learning to manage tools efficiently and understanding workflows of teams takes time. If you handed it in a late application for the program you might get rejected as the learning curve for you would still be too steep. You will be encouraged to continue contributing, learning more, and to apply again for the next round. And to avoid that, better start early. :)
  • Spreading the word, multiplicating the message, encouraging others to also get involved: I don’t know if GNOME asks applicants whether they actively engage with their local User Group or Hacklab, whether they can imagine giving talks about the FOSS organization and their experience working in FOSS at that User Group, their university, or a conference, and whether applicants get “warned” early to think about becoming a mentor themselves in the next round to help making the community grow and become a more diverse and welcoming place.

Statistics: Wikimedia has some statistics (beta) on community contributors joining and leaving. Which does not tell you why people join or leave of course. Could organizations be better to find out the “why”?
For example, I kept in contact with my OPW participant after OPW was over, but she got busy with her new job and moving to a new location (socializing). And I don’t want to be too be pushy and expectant towards volunteer contributions. Could I have done something better or differently? I don’t know. We all have our own lives and make our own decisions what to invest our time on.

Thanks

Thanks to my team (Sumana, Quim, Guillaume) for discussing diversity in general and thanks to Kat for discussing best practices and numbers about OPW in GNOME Documentation.
And obviously everything written here is my personal opinion. As usual.

GNOME.Asia Summit 2014: Docs & Bugs

Saturday, May 24th, 2014

GNOME Asia

GNOME.Asia Summit 2014 is taking place this weekend in Beijing (China) together with FUDCon APAC.

Yesterday (Friday) before the conference started, Kat, Dave and I held a hands-on session about making your first contribution to GNOME documentation (also see Kat’s blogpost). As a result, a number of tickets in Bugzilla have received comments and patches.
Apart from the pleasure to walk around in the room, take a look over the shoulders of people and helping out on non-obvious things, it was extremely eye-opening to realize again how many obstacles you need to pass in order to finally make a contribution – running a recent GNOME version, finding the documentation that is supposed to explain the following steps, having a GNOME Bugzilla account, finding a task (bug report) that sounds interesting, finding the corresponding code repository, locating the documentation file to patch in that code repository (in some subfolder called “C” instead of “en”), using git (formatting the patch, providing a commit message), uploading the patch somewhere for review.

Today I gave a presentation about managing bug reports in GNOME. About 15 to 20 people attended it and I’m very happy how it turned out – we ran out of time to triage a few tickets at the end, but the audience was interested and asked really good questions (e.g. the upstream-downstream relation)! I’m looking forward to the video recording of it.

Sponsored by GNOME Foundation

I would like to thank the organizers (especially Emily for her endless patience helping me to sort out visa issues), the sponsors, and the GNOME Foundation for paying part of my travel costs.

Wikimedia to migrate its Product Management Tools to Phabricator

Monday, May 19th, 2014

Slightly more correct title might be “Wikimedia to migrate its software development product/project code review issue tracking management planning tools to Phabricator”. Or something like that.

The problem

The Wikimedia technical community has used plenty of different tools for tracking bugs / product management / project management / todo lists. Bugzilla, RT, Gerrit, Mingle, Trello, Scrumbugs, Google Docs, to mention most of them.
From my personal point of view, Wikimedia Foundation is pretty bottom-up: Each team can experiment and use those tools they prefer and suit them. That also means teams might have moved from Bugzilla to Trello to Mingle to Google Docs while other teams prefer(ed) other tools. Bugzilla is our public issue tracker but misses a lot of functionality when it comes to agile development workflows, design review work, or activity feeds.

We also have some connectivity between these tools. Bingle/Bugello to sync some parts between Bugzilla and Mingle/Trello, or its-bugzilla (previously “bugzilla-hooks”) to have Gerrit post comments in Bugzilla tickets about related patches (if the bug number was correctly refered in the commit message). But things are brittle – for example, just this Friday the Gerrit→Bugzilla notifications broke.
All in all, the multitude of tools and channels is not helpful for cross-team collaboration, keeping track of what’s happening, and transparency of discussions and decisions in general as things are discussed in several places.

The idea

In late 2013, the idea was to start a discussion about a possible agreement on a recommendation for a smaller set of tools that teams could agree upon. My colleague Guillaume and I had the pleasure to facilitate the discussion and to ensure it doesn’t remain an idea only. References were a previous evaluation attempt in 2009/2010 and the Gerrit evaluation in 2012.

The steps

The first step was asking interested teams and individuals to describe their needs and workflows on a wiki discussion page.
Its content was then consolidated by Guillaume and cleaned up a little bit more by me. (I felt reminded of GNOME’s decision process to migrate from Subversion to Git but that was a survey among GNOME foundation members and hence a very different approach.)

After having those (sometimes contractive) needs and workflows collected, we tried to decrease the items in the list of candidate tools to consider, plus investigate and encourage discussing them on the related discussion page. For candidate tools not having an online test instance offered on the project’s homepage we wondered whether to set up test instances on Wikimedia Labs to make testing easier, but we left it to anybody strongly favoring a tool to set up that tool. Wikimedia Deutschland already had Scrumbugs instance in production (Scrum on top of Bugzilla) we could point to, and for Phabricator somebody had set up a test instance in Wikimedia Labs already.

To gather the broader community opinion and broader support for investigating more potential (wo)manpower, we started to prepare a Request for comments (RFC). While we listed several options at the beginning (Keep the status quo; status quo+Fulcrum; status quo+Scrumbugs; move completely to Phabricator; move partially to Phabricator; move to GitLab) the feedback quickly turned this into one question to ask the community: Move to Phabricator?
We ran this RFC for three weeks until May 6th and announced it widely on mailing lists and via banners on top of Bugzilla and mediawiki.org.

Parallel to running the RFC, we were working on sorting out the blockers for a potential migration from Bugzilla and documenting things. My colleague Quim created a comparison page between Phabricator and Bugzilla.

The decision

Phabricator project logo

The result of the RFC is that there seems to be general support for moving from our infrastructure tools to Phabricator. This won’t all happen at the same time though – we will start investigating replacing Bugzilla, RT, Trello, Mingle.
For the code review functionality (currently done via Gerrit), more work in Phabricator is needed to fit the needs defined by our community, for example when it comes to Continuous Integration. We do not plan to switch off Gerrit on the day we start using Phabricator in production and we got more items to sort out (see the list of code review related items).

For managing the project to move to Phabricator we use the Phabricator test instance itself (dogfooding for the win), by tracking missing features compared to our existing tools, and tasks that need to be solved for the migration. Also, we asked users of existing tools what they would specifically miss in Phabricator by creating (sub)tasks in our Phabricator test instance.

We have not created a Phabricator production instance yet to which we would potentially migrate to, because in the past Wikimedia ended up with a lot of tools by not enforcing migration.

Spreading the word and resource allocation

For the last months we also ran IRC office hours every two or three weeks in order to discuss and answer questions related to the project.

Last weekend the Wikimedia Hackathon took place in Zürich. There were several Phabricator related sessions (videos available for the sake of transparency; the first two videos are more like discussions though):

  1. A general quick introduction to Phabricator by my colleague Shahyar
  2. A discussion among ~10 people of what needs to be sorted out and done for Day 1 of Phabricator in production (being tracked in this Phabricator project board), plus related stakeholders and who’s going to work on what.
  3. A session by Shahyar specifically explaining the code review concept and tool in Phabricator (remember: we do not plan to switch from Gerrit to Phabricator for code review on the first day)

Current status and next steps

  • General and central information page about Wikimedia’s Phabricator instance.
  • Planning board for Wikimedia Phabricator Day 1 in Production (You see several columns here: ‘Need discussion’ needs more thoughts first until we know how to solve those tasks; ‘Ready to Go’ are tasks for which the way forward is clearly defined and somebody could start working on them; ‘Waiting for upstream’ are tickets that we have reported to upstream; ‘Doing’ is what is currently actively being worked on.)
  • The team working on Wikimedia Phabricator and the stakeholders are defined. We have tasks such as investigating migrating Bugzilla and RT data to Phabricator, plus implementing missing functionality like restricting access to certain projects by default (like for Bugzilla’s “Security” product or RT’s procurement queue) via namespaces. The WMF Technical Operations team will set up low-level infrastructure and puppetize our Phabricator instance. We have stakeholders defined to keep in contact with the team of Product Managers and the Platform and Release Engineering/QA team, we have more interested stakeholders which will provide input to help making decisions and driving things forward, and I am happy to also see volunteers being interested to get involved by diving into the code.
  • To track the tasks that Wikimedia is interested in in Phabricator’s upstream task tracker, we have a “Wikimedia” project in upstream Phabricator and the corresponding planning board.

The usual disclaimer: Plans might be subject to change and there is intentionally no timeline yet.

How you can help

Check out the Get involved section on the central project page and the planning board for Wikimedia Phabricator Day 1 in Production if there are tasks that interest you!

Thanks

I would like to thank everybody in the community who has provided input, help and support. Upstream Phabricator developers have been extremely responsive and interested in discussing our needs and fixing issues – it’s a great pleasure to work with them.
Furthermore, getting to this point would have been impossible without my wonderful colleagues in the Wikimedia Engineering Community Team who have helped so much with communication, prioritization, planning, support.