With 3.12 out the door, it’s time to think about what we want to be doing for 3.14. I have a long list of design projects that I want to work on for the next release, but I also want to spend some time on how the GNOME project is working and how we can improve it.
One of my reoccurring interests is how we, as a project, can ensure that each module is in a healthy state. We want modules to have active developer teams around them, and we want it to be easy for people to get involved – not just because it is good for our software, but also because openness is an important part of our mission.
This interest in helping people to contribute isn’t just reserved for new, inexperienced contributors. There are experienced coders out there who are interested in GNOME but haven’t found a way in. Even members of the GNOME project itself don’t always know how to contribute to different apps and modules.
Making it easy for people to contribute takes work. Simply putting the code online is not enough: we need to provide potential contributors with the information they need, and we need to give them feedback and support as they work. We need to enable them to participate by creating the conditions in which it is easy to contribute.
There are a number of reasons why people sometimes find it difficult to participate, and we aren’t going to solve them all overnight. Thinking about this topic, though, one of the main reasons why people struggle to contribute is that it is difficult, if not impossible, to know which tasks to work on. In my opinion, the way that we manage bugs in GNOME is a major factor here [1].
In GNOME we often don’t do a good job of indicating which bugs we want to be fixed, and we don’t spell out what needs doing to fix them. This leaves potential participants with no way to contribute. A long list of unconfirmed bugs, often with no guidance on what needs to be done to resolve them, is a brick wall. It can be the end of the story for potential contributors.
This is the issue I want to address. Interestingly, though, improvements in this area can also help with other aspects of project management: if we are clear about which bugs we want fixing, it prompts forward planning, and it stimulates discussions about which issues should be prioritised over others. It also creates opportunities for conversations about the direction of modules, which can help to include contributors in taking on leadership roles.
To make it easier for people to participate in GNOME, our bugs need to be organised so that they give clear guidance about where contributions are needed. This requires that we have a different process for how bugs are processed and categorised. I’ve spent some time talking about this with various maintainers, as well as members of the Bug Squad, and I have come up with a set of procedures that could work.
This procedure won’t be for everyone, and I am not proposing that GNOME adopts it on a project-wide basis. What I am suggesting is that a small number of applications try it out for the 3.14 cycle as an experiment (I’m focusing on applications because I think they are the best place for new contributors to get involved). If it has a positive impact, then we can think about involving more applications in the following cycle. If it doesn’t, then that’s fine: we’ll have learnt something.
How it could work
The main goal for the bug management procedure I’ve come up with is to remove uncertainty from bug reports. This is something that we are bad at: thousands of ambiguous bugs sit in Bugzilla, which contributors have little chance of knowing what to do with. The procedure uses this schema for bug reports that are on the path to being fixed:
- UNCONFIRMED: new bugs that haven’t been validated. These reports are uncertain – they might not correspond to real issues.
- NEW: reports that have been validated, and therefore correspond to actual issues.
- NEW with “needs_design” whiteboard: valid bugs that are waiting for a design to be produced in order to fix them.
- NEW with “available” whiteboard: NEW bugs that are ready to be fixed. These bugs should have an identified solution which has been stated, and they shouldn’t be blocked by other bugs.
In this schema, “available” bugs are the reports that you point potential contributors to. They are items of outstanding work that can be tackled today. You can link to the list of these bugs from your wiki page, blog posts, or IRC topic. Having an available status is also helpful to maintainers: it helps them see which tasks are pending.
This bug schema also makes UNCONFIRMED a meaningful category. These are the bugs that triagers and maintainers need to process in order to give them a definite status. A large or growing number of UNCONFIRMED bugs in your product is a sign that you need to do a sweep through to clean them up.
In this approach to bug management, you need to regularly review bugs that don’t fall into the “available” category, in order to try and resolve them, either by identifying a solution (and therefore making them available) or by closing them as WONTFIX or NOTABUG or so on. It’s a fairly aggressive approach, in which you have to routinely say what is desirable and what isn’t, but in doing so you open the doors to new contributors who know what the project wants and how they can help.
What’s going to happen next
My plan for 3.14 is to trial this bug management approach with a small number of applications. I’m already working with Debarshi on the Documents bugs, which he has blogged about, and I’m also looking at Contacts with Erick. Once one or two more applications are involved, I’ll post an update on how to get involved.
We want to see if this approach helps to attract new contributors and to manage projects more effectively. We also want to see if the bug classification schema needs to be improved in any way. Towards the end of the cycle, I’ll be talking to people to see how they think it went: was it useful? Do any changes need to be made? Would you recommend this approach for other modules?
If you’re an application maintainer and are interested in this initiative, I’d love to hear from you. Also, I really, really want to hear what people think about the classification schema and the process around it.
[1] I realise that, in focusing on bug reports, I am restricting this to code contributions. In doing so, i don’t mean to suggest that patches are the only way to contribute to GNOME. This is merely a way of enabling participation in one – obviously important, but by no means exclusive – area.
