FOSDEM 2017 From the community devroom

A few weeks ago I happily went off to FOSDEM. Saturday I caught up with people, Sunday I spent most of the day in the incredibly busy Community devroom - right until I had to give up my seat for food. I really enjoyed the talks and hope the track manages to get a bigger devroom next year, dozens of people had to be kept out after every session ended (fire safety regulations).

Most talks lasted about 30mn and the videos should be available on the FOSDEM website. Here are some of the highlights from my perspective and notes.

Closing Loops (Greg Sutcliffe)

Link to talk

This talk was more about raising questions and figuring out best practices based on audience participation rather than offering The One Solution. In this context, a "loop" means an RFC still undecided, a discussion dying out, patches unreviewed. How do you decide when a topic has come to a conclusion?

It's important to remember that everybody has the best interests of the project at heart, this is more about blaming the systems we use.

Say, in a Request For Comments discussing significant changes on a mailing list, the discussion tends to peter out after a while, and it can be difficult to track how a proposal evolved. Foreman (Greg's project) decided to move the discussions to an RFC repository instead, but 6 months later it seems to have only moved the problem.

From the audience:

  • For Debian, the discussion ends "when someone starts the work" :)
  • LibreOffice has a "technical council" type meeting/discussion with about 40 people, on the phone. A wiki documents the process to join.
  • In the PHP world, the RFC author gets to choose when to call a vote and the deadline for it (at least 2 weeks ahead). Greg wondered if that might get divisive if there are too many 50/50 situations, but the audience member indicated that it wasn't the case, because most problems get solved during the discussions that precede the vote so they are usually overwhelmingly accepted. Every contributor gets a vote from a certain contribution threshold.

The speaker seemed interested in trying out the technical council direction for his project.

Data science for community management (Manrique Lopez)

Link to talk

Communities need to have a common vision and self-awareness to see if they are walking toward it: what kind of people are part of the community, what are they doing... This helps with governance and transparency (fairness, trust).

What is the role of a community manager? Do communities even need to be managed? "Manage" is a strong word.

A community manager is interested in keeping their community alive, active, and productive. Having visibility into community health is important. There are a lot of tools out there with data relevant to this: JIRA, git, IRC, slack, StackOverflow, ... A lot of places, which individually are only one part of the bigger picture.

Rather than cobling a bunch of scripts together to get to all that data, GrimoireLab does all the work for you and presents it nicely using graphs. One example was the "Pony Factor," which I hadn't heard of: who's doing 50% of the commits? For example in the kernel, the pony factor is about 200 people/10 companies. That's a lot of people!

When you have that data you can see the evolution of the project over time: reviews, gender, demography, pony factor, etc, etc., in beta, lets you try it out for free for up to 5 Github organisations.

Getting your issues fixed (Tomer Brisker)

Link to talk

I think anyone trying to get help or start contributing as a user to an open-source project needs to watch this. Tomer summarised a ton of best practices that experienced open-source people "just know" and would likely never think to document.

A super rough summary:

  • Try to ask for help on IRC
  • Try the mailing list. If no one replies and you solve it yourself or find a workaround later, please self-reply. (Mandatory xkcd link)
  • Search the bug tracker. If there is a bug, add your input, your use case. If there are none, create a new issue and include as much information as possible: traces, logs, version (including of the plugin if relevant), screenshots... Anything to help the developers reproduce the issue. If this is a feature request, explain your use case.


  • Tabs vs spaces: follow the coding guidelines for the project. If there aren't any follow the standards and conventions of the existing code base.
  • Make the commit message good. Explain "why" as completely as possible. Apparently Github even lets you include screenshots, so that the patch can be reviewed without having to pull the code. "Why" did you do it this way and not another way, explained in such a way people in the future can understand the decision.
  • Include tests. This protects against regressions, so that you don't have to fix the same bug two releases later.
  • Be kind. We're building a community. No one wants to be shouted at. Be patient.

Handle conflict, like a boss! (Deb Nicholson)

Link to talk

Conflicts often come from a piece of information that is missing. Conflict is natural. If you don't handle it, it will come back worse.

How do we minimise it? Try to understand the other people, where they're coming from.

For example:

  • Passion. When people get so excited about something they forget why they're doing it. Mismatched goals.
  • Identity. When someone's identity is linked to a task, not a goal. For example, the person known to be super helpful with wrangling the complex bug tracker, who'll end up sad when you finally upgrade to something better.

Don't leave conflict unattended or you'll end up in a snake pit. You don't owe your mental health to any FOSS project.

There are 3 styles of handling conflict. We tend to use them all, depending on the circumstances.

  • Avoidance. This is not good in a project! It festers. It looks like you don't care, like you're not connected to the community and its concerns.
  • Accommodation. Doing stuff you don't really want to in order to keep the group happy. For bigger issues it can make it look like you don't mind the way things are going. It works for small things.
  • Assertion. Can also be called Aggression. Name calling, etc. Not a good strategy. It wears out other contributors.

Conversations happen in many places. Document the decisions so that it doesn't feel like they're coming out of nowhere.

If you notice in passing a problem in the community you're probably missing some information. Gather more info in order to understand the source of conflict: misunderstanding goals, stepping on toes (e.g. that person always writes the release notes but someone else went ahead and did it this time instead, without asking), ... Is it new members clashing with the old ones? Go back to the historical vision, step out of the tactical discussion. Are there sekrit goals underway? For example a motivation you're not aware of, someone with different goals for their participation like a new job or internal deadlines...

If the conflict is based on fear, it can be harder to get at, e.g. someone afraid they can't learn a new skill if switching language. Create a back channel where it's safe to discuss, to try to deal with it.

Planning for future conflict:

  • Assume the best.
  • Have a code of conduct. Set expectations.
  • No name calling/ad hominem, only discuss technical merits.
  • Set an example.

We could do so much more in the FOSS world if we didn't spend so much time slagging each other :)

Some references:

Mentoring 101 (Brian Proffitt)

Link to talk

This was a lively talk on both formal mentoring via programs such as the Google Summer of Code as well as daily mentoring.

Onboarding is important. This is not just about keeping people in but helping people get in.

As software project, should you want to participate in formal mentoring: have a plan. Formal programs have their own rules and structure.

As a participant, be a member of the community, pick a project that interests you. Be ready to commit. Be flexible - it takes time but is rewarding. Be ready to ask for help.

Undermentoring is a problem. Have clear, set goals for the mentee. Keep an eye on them while also giving them space.

Issue with mentees disappearing... They really should keep a line of communication open, even if only to say, "sorry, I cant' participate anymore." (From personal experience mentoring, this is quite stressful and it was a relief when the mentee admitted they could no longer participate.) You need to proactively mentor to avoid this.

  • Be consistent. E.g. your style may be authoritative (do it this way), democratic (collaboration) or coaching (guidance). Stick to one. (...with Brian noting that the last one is best for mentoring!)
  • Set expectations. Make sure the goals are aligned, define the process, avoid confusion.
  • Take an interest in the mentee. Listen actively. Build a relationship. Learn their style. Don't be a stalker though.
  • Wait before giving advice. It's easy to try to fix things when someone comes at you with a problem. You might be able to solve it but that won't help them. Hit the pause button. Ask more question, get to the heart, guide them to the solution. It takes time. You may not solve the problem. As long as it's not time-sensitive that's ok.
  • Don't assume anything. Avoid stereotypes. Learn the details of a situation. Emphasise communication.

Remember this one thing: they aren't you!! Understand the mentee. This is not only about getting the project done.

A question from the audience was, how can I help my mentor as a mentee? Once again it's about being proactive: this is what I want to do, how do you help me do this? If it isn't working, reconsider the relationship.

How to recruit mentors? Some projects are easier to get in than others. In oVirt, there's a separate mailing list and no formal process. Spread the word, see who's interested. What about a project where there's a lot of mentees yet no one ever answers the call for mentors? If this is part of a corporate project, a solution could be to make it part of the job.

Impromptu community talk

One of the talks was cancelled, so a couple of people started a conversation around community and community events (too many pizzas, too much alcohol is the feedback I remember from that part).

The need for "cruel empathy" was brought up: sometimes meeting organisers should be jerks for good reasons. Loud, demeaning people are toxic and need to be called out. Tell them, in private: "I appreciate that you're here, etc, but you're sucking air out of the community." They may not realise they are doing it, so be nice about it.

The Shotwell community was brought up as one with great first contact.

Overcoming culture clash (Dave Neary)

Link to talk

This was a very interesting talk, mainly summarising information and graphs from books, which I'm going to list here. And hopefully read soon!

Basically a lot of what we do and how we interpret things depends on our upbringing (country, culture, ...)

  • The Tragedy of the Commons - Garret Hardin.
  • Moral Tribes - Joshua Greene.
  • Culture and Organizations - Geert Hofstede. That one brings up 6 dimensions of culture, for example tending to be uncomfortable with silence and filling it instantly, vs. leaving a couple seconds pause to make sure the person is finished.
  • Getting to Yes - Roger Fish. This is more psychology-based than about hard negotiation.

There are no easy solutions. Focus on the relationship. Take small steps: one conversation at a time. Encourage local user groups - though keep them connected e.g. via sending mentors/leaders to these meetups to avoid silos. Have short mentoring programs. Learn about the cultural norms and sensitivity of the community. Avoid real-time meetings.

I contributed! But what now? (Bee Padalkar)

Link to talk

Based on the Fedora community, this talk was about improving contributor retention rates by finding patterns about successful contributors.

Why do people stay? According to a survey they ran, usually thanks to the strong, positive and inclusive community. Other reasons were identifying with the Fedora foundations (core values), giving back, constantly learning.

No matter how interesting the project is, if the community is poor people don't stick around.

  • Have a defined onboarding process.
  • Encourage people to speak up.
  • Assign action items early on, to create a sense of responsibility.
  • Let people know they are doing good work, give feedback (e.g. IRC karma).
  • Use inclusive and motivating language.
  • Encourage attending events to meet people in person.
  • Encourage consistency over activity. Let people contribute according to their own time.
  • Inspire, interact, give feedback.
  • Help people identify with your mission.


Looking forward to next year's event!

Leave a comment

Training at EuroPython 2014 Making your first contribution to OpenStack

OpenStack logo

Last week I ran a 3-hour training on how to get started contributing to OpenStack at EuroPython. The aim was to give a high-level overview of how the contribution process works in the project and guide people through making their first contribution, from account creation to submitting a patch.


The session starts with an extremely fast overview of OpenStack, geared toward giving the participants an idea of the different components and possible areas for contribution. We then go through creating the accounts, why they're all needed, and how to work with DevStack for the people who have installed it. From there we finally start talking about the contribution process itself, some general points on open-source and OpenStack culture then go through a number of ideas for small tasks suitable for a first contribution. After that it's down to the participants to work on something and prepare a patch. Some people chose to file and triage/confirm bugs. The last part is about making sure the patch matches the community standards, submitting it, and talking about what happens next both to the patch and to the participant as a new member of the community.


During the weeks preceding the event, I ran two pilot workshops with small groups (less than 10 people) in my local hackerspace, in preparation for the big one in Berlin. That was absolutely invaluable in terms of making the material more understandable and refining the content for items I didn't think of covering initially (e.g. screen, openrc files) and topics that could use more in-depth explanations (e.g. how to find your first task), timings, and generally getting a feel for what's reasonably achievable within a 3-hour intro workshop.


I think it went well, despite some issues at the beginning due to lack of Internet connectivity (always a problem during hands-on workshops!). About 70 people had signed up to attend (a.k.a. about 7 times too many), thankfully other members of the OpenStack community stepped up and offered their help as mentors - thanks again everyone! In the end, about half the participants showed up in the morning, and we lost another dozen to the Internet woes. The people who stayed were mostly enthusiastic and seemed happy with the experience. According to the session etherpad, at least 5 new contributors uploaded a first patch :) Three are merged so far.

Distributing the slides early proved popular and useful. For an interactive workshop with lots of links and references it's really helpful for people to go back on something they missed or want to check again.


The start of the workshop is a bit lecture-heavy and could be titled "Things I Desperately Wish I Knew When Starting Out," and although there's some quizzes/discussions/demoing I'd love to make it more interactive in the future.

The information requested in order to join the Foundation tends to surprise people, I think because people come at it from the perspective of "I want to submit a patch" rather than "I am preparing to join a Foundation." At the hackerspace sessions in particular (maybe because it was easier to have candid discussions in such a small group), people weren't impressed with being forced to state an affiliation. The lack of obvious answer for volunteers gave the impression that the project cares more about contributions from companies. "Tog" might make an appearance in the company stats in the future :-)

On the sign-up form, the "Statement of Interest" is intimidating and confusing for some people (I certainly remember being uncertain over mine and what was appropriate, back when I was new and joining the Foundation was optional!). I worked around this after the initial session by offering suggestions/tips for both these fields, and spoke a bit more about their purpose.

A few people suggested I simply tell people to sign up for all these accounts in advance so there's more time during the workshop to work on the contribution itself. It's an option, though a number of people still hit non-obvious issues with Gerrit that are difficult to debug (some we opened bugs for, others we added to the etherpad). During one of the pilot sessions at the hackerspace, 6 of the 7 participants had errors when running git review -s  - I'm still not sure why, as it Worked On My Machine (tm) just fine at the same time.

Overall, I'm glad I did this! It was interesting to extract all this information from my brain, wiki pages and docs and attempt to make it as consumable as possible. It's really exciting when people come back later to say they've made a contribution and that the session helped to make the process less scary and more comprehensible. Thanks to all the participants who took the time to offer feedback as well! I hope I can continue to improve on this.

Leave a comment

Evolving Open-Source Night Open-Source Night - June

The monthly Open-Source night experiment continues. On Wednesday, June 19th we had the June edition of Open-Source Night. Rory gave us a slightly-longer-than-15-minutes talk on OpenStreetMap, and the kind of contributions the project welcomes (data data data, really!). I was the only one to volunteer for a lightning talk, in stark contrast with the last event where we had multiple ones both by people attending open-source night and network people who happened to be visiting the hackerspace at the time.

Rather than doing an on-topic talk about an open-source project, I did a meta-talk about Open-Source Night itself and different ways in which it could evolve.

I make no secret that I don't think open-source night works very well in its current format. My goal (and measure for success) is to help people actually get started contributing.

Note: if you were at my deep dive on contributing to open-source and planning on attending the next open-source night, please do come!! This all just means that I think there are things that can be improved :)

Reminder: The current format

We're currently meeting on the 3rd Wednesday of the month. The event usually starts with two 15 minutes talk, ideally one on the life of open-source (e.g. licences, version control, IRC, using the command-line...) and one on how to contribute to a specific project. Then there's a number of 5-minutes-long-or-less lightning talks where people can introduce the project they will be working on during the evening. Then people break into groups or independently work on an open-source project of their choice.

Or that's the idea anyway. The talks usually work well and are inspiring, though they tend to run overtime and then people have trouble sitting at a table and doing things.

The future

These are my thoughts and ideas as to where open-source night might go in the future. These are not plans. I would like to hear feedback from interested people - attendees, would-be attendees, other organisers and thoughtful passerbys.

Topics: General open-source vs Project-specific

I see value in both topics, but perhaps attendees and would-be attendees favour one or the other, both, or neither? I haven't really heard much on this, what people find most useful. I think the project specific talks at least are interesting for both newcomers and established contributors, to see how other projects do things.

I believe 15 minutes is a good amount of time to get an overview, get inspired and get ideas. And not get too bored if already familiar with the topic.

I could see the value and how efficient it would be to focus on one project for a full session and guide people through contributing to it. However I can also see how it could be offputting to people not particularly interested in the project (e.g. "I don't use that distro, why should I bother attending?"). Perhaps as separate, off-shoot events if people are interested in leading that kind of session (get in touch!).

Topics: All kind of contributions vs Focusing on code

At the moment, I try really hard to emphasise (and encourage speakers to do the same) all the kinds of contributions that can be made - and are well needed! - even though my own experience lies in code-based contributions. Maybe I should give up on being inclusive and focus on what I know best, rather than try to be all things to all people? Code-focused open-source events could go from learning to program to fixing a bug.

Initially I was hoping people would step up to talk and encourage people to join their area of interest (I think we have e.g. experienced open-source translators around...) but that hasn't happened.

This is actually a point where someone came up to me after the talk and said straight off they really liked the breadth of contributions demoed during the talks, in particular mentioning last month's talk by Guilherme on OpenMandriva that did a great job showing how someone can help, in a multitude of ways, even if they're not all that confident in their coding skills.

Format: More course-like?

A couple of days before the June OSS Night I was pointed to this article on a really, really interesting summer course on learning to program the open-source way. That's a really cool concept. Should we entertain the thought of doing something similar during open-source night? e.g. A session on learning how to use version control with exercises, very workshop like, one month, some other topic the next one, etc.?

Probably not, but something to consider as a separate course with a shorter timeline. A course with one session a month will lose people and have little momentum. Is this the kind of things people have an interest in learning?

Format: Doing vs Listening/Talking

My goal with this event is still to get people started contributing. I'm not interested in organising a monthly night of talks. Finding speakers is stressful. If the talks aren't followed by some contributing action, to me the event is failing and I'm not interested in continuing to organise it. There are plenty of events around Dublin already where people can meet, talk tech and shoot the breeze.

With regard to open-source related talks, I think that's already handled well by the ILUG folks, who are now keen to set them up regularly again under the new chairmanship :) And we can join forces if that's the most attractive part of the event to folks. If your main interest is in having a regular night of open-source talks, get in touch and I'll be happy to help you have this in Tog. I'd attend with pleasure anyway, I'm just not interested in organising it and go speaker-hunting every 3 weeks.

I still believe we can make something really cool happen by putting in the same room people experienced in open-source together with newcomers interested in contributing. So I'm not giving up yet!

There's of course also the timeframe issue: with or without talks, an evening of maybe 3 hours is not a lot of time to accomplish something. Maybe we could (also/instead?) have events on Saturdays? And/or week-end workshops, Friday eve to Sunday?

HOWEVER, in any case an evening is still enough time to accomplish something, get started, get the momentum going, get unblocked and finish your contribution later at the week-end, in your own time.

You: Why are you here anyway*? ;)

* Or why weren't you? :) I'm just as interested in the answer to that!

Are you interested in learning how to contribute? Interested in helping and mentoring newcomers? What were you hoping this evening would be about?

I then invited people to have a productive discussion with me about this should they wish to, somewhat contradicting my own doing vs talking rant :-)

Please feel free and welcome to continue the discussion in the comments or by email, I would love to pick more brains and exchange ideas about this.

Django challenge

To avoid the talk being entirely meta (and in case people didn't care that much about all the blah blah blah and more about the doing!), I issued a challenge to attendees as well: this evening, run the Django unit tests suite. If that's something you're set up for, it'll take 2 minutes. If you're familiar with the concept but don't have all the dependencies set up yet it'll take 20 minutes. If this is all new to you it might take 2 hours, but what you learn you'll be able to reuse when you start working on a project you care about in the future, and it means it'll take less long then.

One person took me up on it and it took them 10 minutes. This shows how possible it is to actually get the ball rolling during open-source night, get people to realise they're not that far away from a first contribution.

I feel I should give the disclaimer that since the last time I talked about how to contribute to Django, the Django folks added to their docs a tutorial on how to make your first contribution, which just makes the project that little bit more awesome (and this challenge, easier to solve!)

Next Open-Source Night: July

So next month. That'll be on the 17th of July. Are you interested in giving a talk? :)

If no one volunteers we'll have a session similar to the first event except with more lightning talks. Lightning talks don't have to be prepared, there's no need for slides or anything you don't fancy. It's as simple as chatting about what you plan on doing or would like to do during the evening, inviting others to join you if they'd like.

It can be like:

"Hello, I'm Chris, a contributor to AwesomeProject which is a project that does this and that and also that thing. At the moment we're looking for help in $area1, $area2, $area41, if you think that's cool and you'd like to help, I'll be sitting at that table over here, come and chat with me. Maybe I can help you find a good first task. Otherwise I'll be working on the defroglirnator for the project -- er if you have any experience in that area I'd love to chat to you too."

or maybe

"Hey, I'm J. Bloggs, I've been using Wordpress for a few years, I think it's an awesome project and I'd like to start giving back. Tonight my plan is to figure out the new contributor process - if you're interested too, we can do this together. Come and chat with me."

It doesn't matter if there is no existing contributor to the specific project in the room. Since there are people familiar with the way open-source projects and communities usually tick, they will be able to help you if you get stuck.

Ok, that's it! I'm hoping to also have the time to find a few good first tasks in a new project, maybe LibreOffice. If not, then we can figure it out together on the day :)

I'm very much looking forward to hearing your thoughts, suggestions and ideas about all this, and perhaps also see you on the 17th.

Leave a comment | 2 so far

Open-Source Night #2: March 2013

On Wednesday the 20th, we had the 2nd edition of Open-Source Night in Tog. I think it went well. Once again there was about a dozen attendees, many of whom have never contributed to open-source before. A third of them were also in Tog for the first time. It might be too early to matter but there was also very little overlap with the audience from last time.


We started the evening with 2 talks, meant to be about 15 minutes long each. Mark started the evening telling us about open-source licences and the philosophy they encapsulate/were born from. Then I walked through how one would go about contributing to Django, basically clicking through the Django website and explaining different tasks the project needs help with, particularly for bug fixing contributions.

After this, we had 2 lightning talks that were meant to last 2 to 5 minutes, to give people a chance to talk about a project they contribute to and get people to join in. This time the talks were more about ideas, which is fine, but both also ran overtime, which is less cool. I'm not sure if either found additional contributors/would-be contributors out of it for the evening.


The second part of the evening, the part that should be hands-on, didn't go so well. After the talks (which lasted for 1h30 instead of 45mins) and a tour of the hackerspace for the new people, most continued chatting instead of sitting down and getting things done. This especially saddened me for the ones who had never contributed before. The goal of the event is to help newcomers get started contributing, when they have experienced people at hand to ask questions to.

Next time

I'm not sure how to improve this next time and help attendees get started actually doing stuff. Running overtime for the talks really hurt for the rest of the evening, which is already such a short time to accomplish something. An idea: after my talk I was asked "How long would it take for someone to start from nothing to being able to run the Django unit test suite?" and maybe this kind of well-defined, self-contained task would be good to help people get started. It's not a contribution yet, but it's a first, necessary step toward it (for code contributions in any case), and it could be fun to try and mix this with some sort of open badge.

Somewhat related announcement: open-source night won't happen on April 17th next month but probably on April 24th instead. Check the calendar for confirmation. If you're interested in speaking on a topic relating to the life of open-source or a project in particular, please get in touch :)

Leave a comment

Open-Source Night: Event #1 February 20th

On Wednesday, Tog hosted the first monthly Open-Source Night.

It's an event I'd been wanting to organise for a while, with an eye on it being hands-on and slanted toward helping interested people get started in open-source, but I wasn't sure what format would work best. I'm still not sure, but in the spirit of release early, release often, I thought I'd give it a shot for a few months and iterate.

For the first event, about a dozen people showed up. About 7-9 of them had already made some kind of contribution, most people had a clear idea of the project they wanted to contribute to for the evening, and 3 were hesitant and not sure what they wanted to do.

Blackboard with project names

We started with 2 super short talks, an ill-prepared one from myself about what to do tonight: basically find the contributor's guidelines for the project you're interested in and speak to the person next to you for help, since we had such a skewed ratio of experienced contributors. Triona followed with a talk on what she planned to do in the evening with Free Penguin, an open-source sewing pattern for Tux plushes. The maintainer hasn't updated nor responded to emails in years, so it seems it will need to be forked in order to start improving the documentation. Open-source projects aren't all about code! :)

I directed the hesitant project-less people toward Cheryl and the Dreamwidth project, which has an excellent reputation for being friendly to newcomers. Even without an experienced contributor around, I thought figuring things out together would be a fun learning experience. It may not have been that effective though, people were interested and looked around but nothing got accomplished (perhaps that is to be expected for a first couple of hours getting acquainted with a project and open-source?). Then further efforts were thwarted by technical problems (bugzilla down). Cheryl's thoughts abut this is that it's difficult to get into a project one doesn't feel strongly about (a similar downside applies to projects discovered via OpenHatch, as someone else mentioned to me).

There were a couple of serendipitous meetings, like the person wanting to get started with Debian packaging who happened to be sitting besides a Debian Developer.

But overall, I think having encouraged people to come along already having a project in mind made it difficult to form groups and encourage collaboration, because people ended up working on the project they had planned to alone. It may not have been a great experience, particularly for people who didn't know anyone or hadn't been in Tog before.

I also need to become more familiar with projects who have good, specific non-programming-related tasks for newcomers. I had a general idea but wasted time trying to find the details. We had a graphic designer interested in either contributing his design skills, translating or participating in testing efforts but I wasn't able to quickly find a good "Here's a concrete task you can do now" for some of the better known projects. He did discover InkScape and became eager to learn it, so I hope to see him again in Tog in a few weeks for teaching an intro workshop to InkScape :-) (Thanks Borud!!)

Ideas on how to evolve the format for next time:

Choose one project and make it the main focus of the evening, at least at the start. Meaning only one presentation, that is a bit longer (ideally 20 minutes, max 30 -- we still need time to actually do stuff!) and give specific, step-by-step instructions on "this is where you go to find something to work on, this is how you choose a task" and afterwards have the people interested in working on the project do so together - several people to one task can work, to encourage learning together and avoid getting stuck. People are still welcome to work on whatever else they want to of course. This was suggested by Ulrich based on the recent Debian Bug Squashing Parties he attended.

Becky said there was an interest in a GitHub pair programming type of exercise. People upload code on GitHub they never touch again. Working on someone else's code with the help of the author could turn into an instructive experience. It would also be cool to see what a pull request looks like from both sides.

I think we can try both these things for next time, the GitHub pair programming could start after the presentation for people not interested in working on the highlighted project.

Now. The next step is to find a project to highlight and a willing contributor who'd like to present and guide, for the next session on March 20th. Ideas, volunteers? :)

Feedback and general thoughts on evolving the format are warmly welcome as well.

Leave a comment

Talk transcript: Making your first open-source contribution

Slides available on SlideShare (I need to fix an embedding bug on the blog, oops).

Most of you know what Open Source Software is and hopefully think it's awesome. Have you ever contributed a patch? A translation? A bug report? Would you like to do any of this?

(If this is the first time you hear the term, roughly open-source is software for which the source code is freely available, that can be redistributed and modified.)

This talk is for people who like open-source and would like to give back, but are not sure where to start, or if they're smart enough or if their skills would be valued.

And my goal is to encourage you to make the jump from 0 to 1 contribution (or one more!) :)

Because I'm a software developer, this talk focuses a bit more on code contributions. (Don't think this means other types of contributions aren't needed, help is always welcome everywhere!) For many years, I wasn't strongly attached to any particular project but got patches in here and there (Sugar, Gnome, Django...) Nowadays you're more likely to find me in the land of OpenStack.

First, let's clarify something important: you don't need to be a genius to contribute. It's not as difficult as it may initially appear. All skill levels and all types of skills are needed and appreciated.

As to where to start, first I'm going to tell you about a wonderful shortcut, and then I'll go through how it usually works.

OpenHatch is an organisation whose mission statement is: "helping newcomers find their way into free software projects." They aim to bring together all the simple bugs, help requests and help wanted, documentation, all sorted by project and by language. It's a great way to get started.

Now, the way it usually works. When you're looking to contribute to a project, you should first look around for contributor guidelines. If a project has contributor guidelines, it's an excellent sign. It means that they care and that they've thought about it, which is very important when it comes to first contributions.

Read them! You don't have to remember it all. It will give you a sense of direction and an idea of what matters for the project, what to watch out for too (patch format, coding conventions, where/who to talk to, etc.)

As an example, here's a screenshot of the Gnome documentation for new contributors. There's a lot in there! They care a lot about welcoming new people.

In any case, whether a project has contributor guidelines or not, the workflow tends to be the same. Read the guidelines if they exist :) From then on, look at the bug tracker to find something that you'd be interested in working on. Now that you know which part of the project you will be working on, build it. Find the bug, fix it and submit your patch!

I'm going to be using the first contribution I made to Gnome as an example throughout this presentation. The Gnome folks are a very friendly community, and have a special tags for bugs that are good for newcomers called "gnome-love". In other projects this may be called "easy picking", "bite-sized", "low hanging fruit", etc... It should be mentioned in the contributor guidelines.

Look at the list of bugs tagged with that keyword and find one you like that is easy. (Avoid choosing a big feature as a first contribution. You need to earn some trust first, as well as pick up the project technical and cultural conventions.)

Once you know what you will be working on, it's time to build the software. This is very important, you will be learning new tools, perhaps even new languages. For instance I chose a bug from gnome-terminal which is written in C and uses autotools, which I wasn't very familiar with. This is why it's important to select a small first bug, because you have a lot more to learn to get there.

If you can't find instructions to build the software, you have a couple of solutions. Sometimes a mentor comes together with the "easy pickings" tag, or the community has its own mentorship program. You can also go back to the magical portal mentioned earlier, OpenHatch, where "training missions" are available to get people up to speed with some of tools commonly used in open-source.

People forget they had to learn all this in the first place. Don't sweat it. This is a stepping stone.

Once you have a working build, it's time to reproduce the bug, find it and fix it! If you're lucky, the location of the bug may have been mentioned in the bug report. As said earlier, the person who marked the bug as an easy task may be willing to help mentor you through it. It's ok to ask for help if you're having trouble.

As an example of a first task, I was lucky, and I indeed picked a very simple one - changing a colour in the gnome terminal!

Once your fix is ready and tested (you have rebuilt the software with your fix in it), it's time to submit the patch. Now is a good time to refer yourselves to the contributor guidelines once again, it will be useful to find out what your patch should look like (coding guidelines), what command you should use to create the patch, and where you should send it. If there are no such instructions, the safest path is to attach the patch to the bug report in the tracker.

And... congratulations! You've made your first contribution to open-source. Take the time to pat yourself in the back and be proud, you deserve it.

The process isn't quite finished yet: the next step is to wait. Perhaps your patch will be accepted since it's a small contribution. It's just as likely you might get some feedback on how to improve it - everybody wants to make their project better so don't take it personally, take the feedback on-board and resubmit the patch. If your patch gets lost in the ether, you should consider pinging the component or project maintainer.

In my case... I was lucky :) The patch was accepted and merged in the main codebase about an hour later!

If the only answer you get is silence - don't take it personally, really. People want you to stay, a healthy project know they need new people in order to stay alive. Open-source projects are always short in resources.

If the people involved in the project you contributed to have a bad attitude, don't be discouraged. And don't stick around either, there are a ton of cool, useful projects with friendly communities who could use your contributions. Life's too short.

If you've done your research, read the guidelines, there won't be any dragons. Most people are very nice! It's great to become part of a community that cares about creating the most awesome project they can.

And as a closing word before opening for questions: remember They are people dedicated to helping newcomers find their way.

Leave a comment | 5 so far

"Making your First Open-Source Contribution" Ireland Girl Geek Dinners

Hello good people who attended my talk on "making your first open-source contribution" for the January edition of the Girl Geek Dinners in Dublin. I hope you enjoyed it!

The slides are available on Slideshare - this version is actually missing a couple of recent updates, the main one being the mention of the Open-Source Night starting in Tog on Wednesday, February 20th. Come make your first contribution or help others get there!

If you're looking for a copy of the hand-out, you can download it here.

I'll be posting a transcript of the talk in the next couple of days. It still needs a bit of proof-reading :-) (It's posted now)

Many thanks to Christina for organising GGD!

Picture of the talk
(Thanks to @Imisaninja for the picture)

Leave a comment

Interested in open-source? Come to Tog!

Are you an experienced open-source contributor interested in recruiting new people for your project?

Are you a fan of open-source who would be interested in contributing at any level but isn't sure how to?

Come to Tog's first Open-Source Night on February 20th!

These hands-on sessions aim to bring together experienced open-source contributors with people who would like to get started but aren’t sure where to start or would generally benefit from having someone to ask questions to.
Every month we will start with a couple of people speaking for 5-10 minutes, to introduce the project they are working on, what is the usual path for contributing and where they are currently looking for help. Then we will form groups and work on making a contribution for the rest of the evening.

I'm hoping to make this into a regular monthly event. The current plan is to try it for a few months and see what it becomes. This will heavily depends on who attends so, help me recruit lots of interested people from both side of the contributor spectrum in Dublin :)

Leave a comment

Friendliness in open-source

The general view of open-source communities when standing at the edges is probably a vision of endless flames, strong personalities clashing, patches being ripped to shreds on mailing-lists, RTFMs, and the general need to have a thick skin when going in there or being crushed to pieces. The high-profile projects where one might think to contribute first like the Linux Kernel can have quite an intimidating culture, keeping lurkers looking out from stepping in.

I rarely read stories about the really friendly projects that do their best to mentor newcomers.

I'm currently mentoring for the OpenStack project as part of the Gnome Outreach Program for Women. Everyone I see talking to the interns, whether or not they're directly involved with or even aware of OPW, is helpful and makes the time to be friendly and answer questions ; what they see is new contributors interested in helping out and it's in their own interest and the project's to give a hand at the start, when it is most needed.

If you like open-source and sometimes think you'd like to contribute if you could: explore the community for the project(s) you're interested in. Most of them are really nice places to be. Have a look. Ask someone on IRC or on a mailing list for where to find directions on how to get started. Healthy communities are concerned about being welcoming and attracting new blood, because they know they need it to survive and be sustainable.

And if you're still hesitant about jumping in and have a specific question I might be able to help with, get in touch :)

Leave a comment

"Making Your First Contribution To Open-Source" Irish Hackerspaces Week 2011

A CG character in front of a laptop thinking of various open-source projects

I gave my presentation on "making your first open-source contribution" in Tog yesterday evening and I think it went down well; I enjoyed delivering the talk and received positive comments about it afterwards -- although I do need to speak louder. I'm enjoying lightning talks! Now, what to speak about next... :)

The slides are available on Slideshare (or PDF). I also gave a hand-out to give people a chance to check out the links afterwards.

- - -

On another note I think an evening of lightning talks was generally well received, and there is some motivation to run another similar event in 2 months. I'd love to have this be a regular thing. We need to be more strict on time-keeping though; surprisingly it seems people tend to feel bad for not speaking long enough, so they start just talking about random stuff or opening web links of cool things to show off... and interesting or not it feels like it's dragging on, particularly when one knows there's 3 or 4 more talks to go after.

I also got feedback from first time visitors that starting late "because people will be late anyway" makes it very sucky for people who don't know anyone yet, and also less likely that there'll be time to stick around after the talks to chat with the speakers and other attendees. I think we should start right on time next time (and to be fair, the 2 or 3 people who arrived between 7:00pm (announced time) and 7:30pm (actual starting time) were members... Not worth waiting for!!). It'd be nice to start on time and then encourage people to stay with drinks and cookies, or otherwise we need to find a social butterfly that is good at integrating people. :-)

Writing this down now, so that I can remember it in 2 months. Any other comments on the evening from people who were there, or general suggestions and tips on organising lightning talks?

(Irish Hackerspaces Week isn't over yet! Check out our other events.)

Leave a comment | 2 so far

EuroPython 2011: Brian Fitzpatrick on the Myth of the Genius Programmer

Link: talk description and video

A lot of user questions for the Google Code project are along the lines of "how do I hide code until it's ready", "how can I wipe the history and start from scratch" and so on: they are about people's insecurities.

When you have elitism and anonymity, suddenly everyone is elite. There's a whole mythology that gets built around programming heroes (Torvalds, van Rossum, Walls).

There are no genius. The only thing this has created is a fear of showing mistakes. This insecurity inhibits progress, makes the process slower, brings lower quality and a lower bus factor.

Avoiding the trap

  • Lose the ego
  • Criticism is not evil: give and take it politely. You are not your code. People criticising your code are not out to get you.
  • Embrace failure (just don't fail the same thing over and over!)

The speaker shared an interesting story (probably an aphorism?) of an executive that makes a mistake that costs his company 10 million dollars. The day after, he starts packing up his things and when the CEO summons him to his office, he's ready to hand in his resignation, saying there is no need to fire him. The CEO replies "Fire you? Why would I do that? I just spent 10 millions dollars training you!"

  • Iterate quickly
  • Practice is key
  • Be a small fish, as in don't be the smartest person in your company. You'll learn much more and faster
  • Be influenced. "Alpha" programmers think they know everything and won't ever listen -- you may find that you actually gain more influence, by being willing to be influenced!
  • Be vulnerable, repeated vulnerability becomes a strength long term.


Tools won't solve sociological problems, but they may influence behaviours. Pay attention to the tools, they can influence culture and moral, for instance by encouraging "cave" behaviour where developers work on their own for a long time and dump a big chunk of code: it's bad for collaboration, reviewing, etc.

You don't need to hide a project until it's "ready." Simply don't advertise it. People may find you because they are looking for something like this.

Don't let people collaborate until it's too late: they may help with code reviews, or pointing out to you existing libraries you missed. If it's too late in the project, they have no possibility to drive, to be a strong part of the project and it's less likely they will contribute.

Certainly get a prototype ready, some running code and some design, but let it still be something that you're happy to step back on.


  • Don't try to be a genius
  • Collaborate early and often
  • Pay attention to default behaviours (the ones encouraged by tools especially)
  • Pay attention to timing

...and if you do all this, people will think you're a genius!

Some of the questions/responses

Make sure to write a manifesto with the direction you want for your project from early development, so there are no major clashes or misunderstandings later on when people get involved.

If you don't care about credit, wow will you go places. If someone "steals" your idea and they have more reach (e.g. more clout/connections), it's great! It means it's more likely the idea will be implemented, and you'll have more ideas anyway.

On influencing a new team you just joined with best/better practices: start by doing good work and building up a good reputation, then you get to pay it back on something you believe matters. You have to choose your battles, you can't step in front of every train (resistance to change is like a very fast train! Hard to stop.)

Leave a comment

Excellent talk on outreach and growing your community Moar contributors moar

I've been having a great time perusing through the PyCon 2011 video archives and watching some of the talks. Turns out most of them are 30 minutes long, which is a lovely amount of time -- a bus journey, a late afternoon break, etc, and exactly the length of my attention span :-)

Here's a link to an excellent talk on growing your community of contributors, with actual tried-in-real-life examples and how and why they work and what you can do to improve your own project. In case Python's not your thing, it's actually not very Python-specific ; there are many examples from different communities (Debian, OpenHatch, ...)

PyCon 2011: Get new contributors (and diversity) through outreach by Asheesh Laroia.

"Diversity" sort of remains in the background of the talk, rarely directly mentioned, and I think it makes sense. If you spend the time nurturing new contributors and making sure to create an environment where it's ok to learn, you're more likely to get people from different walks of life showing up.

Leave a comment

GUADEC: Inside the Banshee Awesome Factory

Eek! Looking through my old drafts I can't believe I forgot to post this. I was waiting for the LWN link to become available to all -- but I guess it's never too late to share the awesome.

Article: GUADEC: Banshee project reaches out for contributors (LWN)

This is the summary of a very good talk, "Inside the Banshee Awesome Factory" from last GUADEC, describing a number of things that the Banshee project does to attract, welcome and nurture new contributors. For instance, they make sure to make plugin development fun, by automating away the boilerplate code -- kinda similar to starting a new project in Django (I wonder if that's something Sugar could use, to create new Activities...) Every contribution is equally appreciated, including the "typo" fixes that many people would start with. They're not afraid to welcome people with little programming knowledge, and walk them through how easy it is to fix a bug or add a new feature. I suspect this works fantastically to also attract good people who are not overly confident in their skills. The speaker wasn't scared to live-demo how easy it is to add a new feature, particularly if it's similar to something existing -- actually he was a very good speaker, if you have the time you might want to catch the video of the talk itself (day 3, Paris room, 10:15-11:00).

A very cool stat I forgot about, that's in the article: in the last 2 years and a half of development, Banshee has averaged one new contributor every week. That is awesome! It's worth looking into what it is they're doing right.

Leave a comment

Gnome Development Documentation & Tools HackFest Retrospective & random thoughts

I just got home back from Berlin, where I participated in my first HackFest.

First day, first impressions

I was about 6 hours late for the first day, mostly due to weather related delays at Dublin Airport. I would have been a little late anyway (not enough days off left to fly in on Wednesday), but once there I quickly realised how beneficial it would have been to arrive a day early, attend the Welcome Dinner, and get to know people (at least names!) before trying to work with them. Lesson learnt for next time.

The first day was mostly discussions and planning what should be done, and toward the end assigning tasks to people for the following days. The whole HackFest thing is very focused, that first day was a lot of nerdy discussions except with a focus on getting things done (and thus not much patience for staying off topic). People were also careful not to make decisions for the whole community.

During most discussions, a few people were dominating/leading the conversation, which I wondered a little about at times. Some voices sometimes got ignored because someone louder started speaking or answering a question over them.

Being late meant that when a couple of topics I have an interest in came up, I didn't have yet a good enough grasp of the group dynamics to be able to chime in (my fault for being late and not speaking up anyhow). For instance someone mentioned the idea of a "Kid's corner" in the documentation for school students to learn about Gnome development. That's a topic dear to my heart, and what an awesome idea! There was no time to work on it during the HackFest but in case the idea surfaces up again I hope I will be around to listen in and participate.

In the end, the main plan became to work on a catalogue of "cool" demos to show and teach about different aspects of the platform -- first applications at a level a little bit above "Hello, World", for developers to try and expand on with their own cool ideas (the licence for the code in the documentation will allow for this, of course). Some people worked on other cool stuff.

The HackFest continues

I kinda messed up day #2. I can't help with writing code examples because I wouldn't know how to do most of them yet, and I haven't internalised best practices in Gnome Development either. So I kinda hid instead (I still had a good time! But I felt bad for not contributing enough).

I could have helped with writing, but it turns out most people wrote at fine to awesome levels all on their own already :) That left me with trying out tutorials and reviewing them with the fresh shiny eyes of a newcomer to the platform, which required the tutorials to be written first.

From day #3 I started jumping on people as they entered the office and constantly asking "Do you have anything you'd like me to look at?" so people knew to send things my way. Turns out some libraries (like libgda or webkit) couldn't build this week due to changes in gtk3 and I ended the day with Gnome Shell not starting on my machine, GStreamer behaving in the strangest way and also a better knowledge of Jhbuild ("Erm, could someone with a few minutes help me understand a Jhbuild issue?" - " *laugh* You do realise the maintainer is sitting besides you, right?"). Things merrily continued till the end of the last day, and I managed to test and review several tutorials and increase my knowledge of GStreamer, Javascript-the-Gnome-way, Clutter and Gtk, as well as learn about Mallard (the real question being, MAllard or mallARD?), glühwein, and how to say croissant in German (that's "croissant").

Sometimes someone would bring up a topic of conversation (intro to Mallard, what to include in the platform overview, how to revamp, ...) and people would assemble around the table, maybe use the projector and discuss what direction to take.

People did a beautiful job with the demo examples I got to test. They are simple, well explained, quick to try out and you do learn a lot when you go through them, while usually still getting a hint that there is more awesomeness to find if you dig further into Gnome. Most of the problems I encountered won't be problems when people run the examples on a stable Gnome 3 system in the future, as opposed to an active/fluid development version within a sandbox. I kinda failed at being a good representative of Python-as-a-first-class-citizen though: no example was completed in the Python language over the 4 days! C, Vala and Javascript will be nicely represented though.

People are very much "Work hard, Play hard" in a hackfest environment. Thanks to our Openismus hosts we got to work in a nice office, be introduced to lovely restaurants and visit a Christmas market among other things. People would go out at night and then come back to the office around 10 or 11pm and work longer into the night. I never stayed that late (happier working in the morning, as strange as it may be for a hacker).

As with my GUADEC experience, the Gnome folks are an incredibly nice bunch, very welcoming. An interested newcomer dropped by unannounced on Sunday and was taken under someone's wing to work on documentation tasks, mentor within arm reach.

I suspect it might have been a tad too early for me to attend a hackfest though (considering my lack of experience with the community and in general), even though I came here as one of the main targets for this documentation effort -- the Hobbyist, happy Gnome user and eager wannabe contributor. I'm still glad I attended and jätte-happy with my experience, and I hope my comments and feedback on the examples were helpful. Perhaps that is something I can keep helping with.

Leave a comment | 4 so far

Contributing to an open-source project: Sugar, a newcomer's perspective.

It's proven difficult to write up a summary of my experience as someone-who's-not-a-hardcore-open-source-contributor-yet-but-certainly-plans-on-becoming-one. There's an easy dialogue-killing answer to any anecdote I relate: "suck it up." I'm still trying to find a way to express all this though, because I'm sure there's something to learn from any newcomer's attempt to join a project, and also for my future self, when I'll be the one encouraging others to get involved with open-source and won't remember what it's like to stand on the edge, trying to understand how a community functions and how to find a space that fits you in there.

So. Two anecdotes on contributing to Sugar, then a description of the incredible level of confusion I've been experiencing looking at the development process overhaul, followed by some ponderings on "what's next" which I better follow up on in the future :)

Anecdote 1: Fixing a bug (InfoSlicer)

Sugar (and the XO!) had been on my radar for a while. Last summer I finally made the time to set up sugar-jhbuild on my laptop and start trying it out for myself. I was enthusiastic but despite the very good wiki I wasn't sure where I could make myself the most useful (Sugar core? Making a new activity? Fixing activity bugs?). I find fixing bugs to be a fantastic way to get familiar with a project and a code base, however I wasn't sure how to pick one because every ticket in is already assigned to someone. It wasn't obvious to me whether I was welcome to work on any or if there was some sort of "please may I work on this bug" process or if assigned people might be protective of their code (I've met a few virulent "It's my code/my bug!" people before, albeit mostly in college.) The sugar-love bugs were few.

Enters OSS BarCamp in September 2009, where I met Laura Cowen (thanks Jaime for pushing me to introduce myself!) who presented a lightning talk on a Sugar activity, InfoSlicer. Having met with a real person who was enthusiastic and sort of involved with Sugar, I thought I'd take a look at InfoSlicer. There was only one bug filed against it at the time, that quite seriously limited the capabilities of the activity. I set out to fix it. A few weeks later, I was attaching my patch to the ticket, discreetly sweating over the associated comment. Someone replied less than a day later, suggesting a different approach inspired after another activity I hadn't heard about and before I had come back from work that same day, the current maintainer had accepted my patch and also suggested another way to do it that we could work on together. I was double-elated and thanks to the "we" felt very welcome.

Unfortunately I hadn't enjoyed a lot working on the parsing code for InfoSlicer and despite promising myself I would update the activity with the new toolbar "soon" I didn't get back to it (yet, shall we say. I'd still like to do the toolbar thing sometime.)

Anecdote 2: Fixing bugs (Pippy)

'round the same time I had volunteered to show cool engineering things to a transition year (high school) student spending a few "work experience" days in my workplace. Although he was a bit older than the Sugar usual demographics, I gave him a usb stick with Sugar on it anyway: Sugar is cool and we all had unrealistic expectations of what a student could accomplish in a week. I thought perhaps he could get familiar with the project then investigate a bug. After he showed some curiosity about programming, I stirred him toward Pippy which he enjoyed greatly despite the occasional stracktraces some examples were invariably throwing up.

Most of these issues had already been reported so I thought, "I love Pippy, I'm gonna try to fix as many as I can." Along the way someone I know got a bit hyped up by my enthusiastic chanting of "Sugar Sugar Sugar" and had set out to fix a serious display bug in Pippy, #347, despite not being particularly fond of Python. I fixed a couple of other bugs, attached the patches to the relevant reports and hopped away, waiting for a review or update. Months went by. My friend lost interest. I began to pep myself up to ask about the Pippy maintainer on IRC. At the time I was trying to build up some confidence by getting my work accepted first before going about and expressing opinions or asking questions in public places (not the way people usually prefer things to be done in open-source, I realise.)

A series of coincidences happened and I suddenly was offered commit access to the Pippy repository (I mentioned that before.) Despite the best intentions, I wasn't comfortable pushing my patches to the mainline merely because I had the power to do so ; I find it preferable and better for patches to be looked at and approved by people who know what they're doing. Eventually I pushed #843 myself into the mainline, as Chris Ball kindly reviewed it as part of an email thread. I still didn't feel so good about it, managing the statuses in Trac was unclear (both status + resolution must be marked as fixed/resolved?) and the bug never ended up assigned to me (it looked like Trac's button would change both the status and assignee so I wasn't sure and then it was too late, I didn't want to revert the status back.) Basically, as I've stated before, I was still in dear need of a mentor, and I still didn't reach out. I fully understand and accept that this is my fault for not communicating well enough with the community.

Another bug I had worked on, I didn't fix correctly the first time around. When this was brought up I responded quickly, explaining where I thought the issue was and submitting a second patch a few days later. I won't be pushing this to mainline until someone else confirms it works, but I'm still happy with it because I proved (to myself, too) that in case of problems I am responsive and able to correct issues within a decent timeframe.

Meanwhile, I was also getting fidgety about #347 as without it, Pippy is impossible to use on my Eee and likely on other netbooks. Eventually I asked, still within the bug tracker, if people would mind if I pushed the current (working) patch to the mainline. Other unrelated requirements had come up in the bug report discussion, much less serious than does-not-work-at-all-unless-patch-is-applied so it felt fair to push the partial patch. Lots of people had popped up the first time around and subscribed to that bug, but there was no answer.

Not long after, someone submitted a duplicated patch to fix #347 as well as the other unaddressed aesthetic issues, using a new process still being defined. The patch got reviewed, no one mentioned the duplication (I didn't either) and soon after the patch was pushed to the mainline and the submitter became Pippy maintainer (yay! At least Pippy now has a more active maintainer, hopefully!)

It's great to see movement on the Pippy front but I felt so disheartened by the duplication of that patch that had been sitting there for 7 months and that I had to install manually on every stick I made for the past 7 months. I invested so much energy running in circles like a headless chicken, trying to do things right with my shiny commit access and waiting for feedback. I was very discouraged, the basic lesson being: I shouldn't have cared so much, especially when I knew I hadn't fully groked all the processes yet. This only (mostly?) happened because I did not reach out to the community through other channels than the bug tracker.

The new process

While I'm at it, I'd like to mention what's going through my mind with regard to development process changes that SugarLabs has been setting up lately. Sugar is basically moving toward a mailing-list only style of communication to submit patches and I've been endlessly confused since this started. I'm not sure it's the most inclusive process either though I understand the problems it's trying to solve -- mostly lack of code reviews as illustrated by anecdote #2 :)

I think it's more confusing than it used to be and makes the barrier to entry higher because as far as I can tell, now if I or anyone want to fix a bug:

  • I go browse trac and find something interesting/that I care about to work on
  • Now I also have to search through my inbox and patchwork (a new system I haven't totally figured out yet either, but it doesn't look any less confusing than my inbox with every patch/email thread thrown in there together) to see if the bug is already being worked on
  • I need to join the mailing list to submit my patch (I'm assuming, but it's probably necessary if you want to be sure to get the answers) -- that's quite intimidating and a commitment for "just" a patch. The process should also be easy for passersby if you want people to stick around.

Reading the mailing list and the patches as they get submitted is also confusing because it's difficult to link a patch to a bug and understand the background/context. In most cases you'd have to go and dig it back up from the bug tracker.

I know people are working on it at the moment, so I will wait for the wiki to be updated with clear instructions on how to effectively use the new process and systems, as the wiki still only describes how to work with trac. For now I'm watching perplexedly and wondering if really, the mailing list will be the only way for people to contribute in the future? I worry that the new process is inspired from projects that focus on hardcore technical people (Linux kernel) rather than others that also welcome passionate beginners (Dreamwidth).

Other valid solutions were proposed to fix the patch review problem and I wish I had found the bug on re-creating a "patch need review" automatic weekly email so I could have tried to do my bit to help. Great Sugar contributors believe in the new process though, enough to invest their time setting it up and setting up the tools to make it work more conveniently. Now that I've finally written this post and digested what happened and where I messed up, I should be able to focus on how I can help the project with other contributions.

What now?

Step back, start from scratch with a clean state of mind. Probably stay away from code contributions for a bit. Talk with the community. Stop messing up brilliant opportunities when introduced to cool people by email ;) Be more pushy when it comes to asking for feedback.

Looking at the releases notes surrounding Fedora 13 and Mirabelle make me hopeful: the Sugar on a Stick (Mirabelle) wiki pages are awesome, vibrant with optimism and that sub-community within the community sounds like a great way into main Sugar. Quote from their wiki I love: "When you're stuck, and have spent more than 15 minutes trying to figure out what to do next [, email the mailing list / ask on IRC]." The weekly meetings where newcomers are welcome sound like a good idea as well, it gives some structure rather than let new people break into the main group on their own (or so I imagine, I wasn't able to attend the first meeting last Monday.)

Leave a comment