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.
GNOME Bugzilla already has tons of unreviewed patches. Attracting new contributors only to have their patches ignored is not a good idea.
Patch review does happen, so I wouldn’t want to discourage people from contributing on that basis. That said, we can do better at this, and part of keeping on top of Bugzilla is keeping up with patch reviews. That’s another thing we’ll be aiming to do with this experiment.
You should not be so quick to dismiss Steve’s comment. This is exactly why I stopped contributing patches to Gnome. Its a huge hassle trying to get someone to review your patch. You need to basically beg for someone to do it and even than you are still lucky if it gets reviewed. I put in many many hours into triaging and fixing gtk+ and other bugs last year and the year before, and discovered basic patches as old as 5 years for things as simple as memory leaks that still were not applied.
I think its great you are trying to improve participation but I agree with steve, bug triaging is not the major problem its patch review where things fall apart. Gnome is the worst project I’ve personally contributed to in this regard, even once you do get a patch reviewed you then sometimes have to go back to begging to get someone to then commit the patch. . The best project by far for contributing to is Firefox, if there is one thing I would love to see it is Gnome upgrading to a recent version of bugzilla and using it in the same way as the Firefox guys do. To get a patch reviewed you simply assign it to a maintainer for that module for review, it is then on that maintainers list of patches to review and puts a bit of incentive on them to review it, Once the maintainer gives it a positive review you can just mark the patch as commit needed and someone comes along and commits it for you, no hassling of devs required.
If you are interested I spent a lot of time organising filechooser bugs into categories using the whiteboard to make contribution easier and so we could organise a bug fix month but ended up getting burnt out after triaging over 100 bugs on my own. https://wiki.gnome.org/Projects/GTK%2B/GtkFileChooser it looks like the wiki links need to be updated as the component name has since changes from ‘GtkFileChooser’ to ‘Widget: GtkFileChooser’ I would be interested in resuming this work if someone else was interested in helping get it of the ground. Just for reference Federico (filechooser maintainer) was on board with the idea which is the only way I can see this working as my initial complaint goes there is not much point if the patches wont be reviewed.
I wasn’t trying to dismiss Steve’s comment – sorry if it came across that way. There is clearly an issue here, which is something I hope we can address. Some modules are quite good at patch review, btw – it really varies.
Flagging patches for review sounds great to me.
What about ui-review? Seems clear to me that it’s already in use.
Yeah I debated that… ui-review is used as a “needs design” flag. The problem is that “ui review” communicates the wrong message (ie. design consultation after the fact).
That’s not how I ever used it. One important difference, it’s not a whiteboard, but a keyword, which means it’s easier to search for:
https://bugzilla.gnome.org/describekeywords.cgi
The other thing that needs_design has going for it is that it indicates the state of the bug a bit more strongly. I see you’re point though; ui-review is established at least.
As for using whiteboards, that’s primarily for the testing phase. If this works out we could think about changing the whiteboards to keywords.
I also reported bugs, about the GNOME website, and I didnt recive an answer or any official attention! If you dont care, why should I? There are open bugs for years that didnt recive any attention. There are open bugs like this for years.
I wouldn’t assume that your bug has been ignored. I don’t reply to every bug for the modules that I’m subscribed to, but I do read every report, for example. Maintainers certainly do care, but they are only human and often have competing commitments.
That said, I think that your comment illustrates that responding to bugs sends an important signal to users and potential contributors. Being more proactive with our bug reports will hopefully encourage more people to get involved.
Does that really come as a surprise, Allan? The bug tracking system is (arguably) the most critical mechanism you have for users to communicate with developers over problems they’re experiencing.
Developers shouldn’t need to be told that providing responses to those bugs – even if you don’t have time to fix them immediately – is essential if you don’t want to drive them away…
Of course it isn’t a surprise. I just wanted to point out that it’s a bad idea infer negative intentions. People usually mean well. :)
One thing I remember that step me down when I first started contributing to ubuntu or gnome bugzillas is the lack of attention. That feels like: ok…none cares about the project and my effort to reporting (I feel reporting it’s an effort even now I have more experience). Because at first, at least me, feel the health of the project based on the attention to my bugs (obviously not now), and I expect that to happens to some more first reporters.
When I say attention, I mean something simple like the maintainer going to the bug, marking as NEW and maybe let bugzilla put an automatic answer like:
Thanks for your bug report! We stated it is a bug and we will try to fix it as soon as posible. If you want to help us, here’s a guide to contribution [Link to gnome love or whatever].
Not sure how that can be doable with current manpower… =)
Hey Carlos! Maybe we should come up with some new stock answers. I’d really like to work on the bug triage guide too.
While I doubt that we’ll be able to deal with every module, I think we’ll be in good shape if we can organise some of the apps and point contributors to them.
Hi Allan =)
Nice.
Obviously I don’t think like that now, but as you said, we have to put down that wall for first contributors.
Hi,
I would also like to point out that the GNOME Bugzilla is quite slow, the user interface is not inviting etc. pp.
Having a Bug Management Application that would be snappy and work like reddit, for example, with up and downvotes and a lot of comments and tree-like structure could be incredibly cool — discussions could be well structured and up- and downvotes could indicate the need by the community to have that bug fixed. Further integration with bountysource or a similar service would be the gold finish.
Maybe discourse could become a “Bug-Discourse” with additional features for bug management (they already support tags and have different “rooms” afaik. Just my two cents.
By the way, I tried to find you after your LGM Keynote … but I didn’t manage to find you and Jakub. Hopefully next time.
Hey! Sorry we didn’t get chance to talk at LGM. It was a shame that our talk was at the end of the conference – I had to fly back on the Saturday evening. Feel free to get in touch if you want to talk about GNOME design at any point.
Personally I would love to see Gnome making more use of Github. I find Github much more facilitating and encouraging when it comes to community interaction than bugzilla.
Has a complete move to Github ever been discussed?
This is a great idea, although of course this post highlights a big problem that faces pretty much every project relying on distributed development. The culture around bug reports and quality assurance varies greatly between software within GNOME as a whole, and you’re right that it leaves potential contributors feeling uncertain. While GNOME has been focusing on improving the developer experience, I think having a more engaging, clear, and useful way of discovering and managing bugs could kick things into gear.
I’m sure we won’t be switching away from Bugzilla any time soon, but it would be nice to make bugs something fun and interesting instead of a headache. Of course, it wouldn’t hurt to have a deeper analysis of the problem from a sociological perspective.
Some things that Mozilla bugzilla seems to have that GNOME bugzilla’s doesn’t (or at least not obviously: I’m not a heavy user of it), that might be helpful:
1. An ability to flag someone to review a patch
2. An ability to flag someone for a needinfo? request, in case you want some info before writing a patch or whatever
3. A notification on the top of bugzilla how many review requests / needinfo requests you have in your queue, an easy way to see what you have in your queue, and regular email nagging you about requests if they’ve been languishing for a while. See: http://globau.wordpress.com/2013/10/30/nightly-request-reminders/
4. A formalized system for classified bugs appropriate to newcomers under different categories, and a user interface for browsing said bugs: http://www.joshmatthews.net/bugsahoy/
That’s really useful! Thanks for the information. We’ll hopefully get some of these things when we finally get around to updating our Bugzilla instance.
As someone who triaged for *buntu a long time ago and maintained packages on Launchpad, I must say it’s important to have a good say over how you receive bug report emails. With xfce4-volumed we had a large number of segfaults and memleaks being reported (quite likely because of specific GStreamer/hardware issues) and that plagued my email account so much with hundreds of automated reports that contained no valuable/readable information to me (though it might’ve been useful to the person who coded the tool, that I can’t judge).
I ended up missing the real reports from human beings who expected an answer and had the ability to help me track down the origin of the bugs. It swamped me so much that I maintained the package more and more slowly over time. And as pointed out by others, bugzillas are great tools but not super friendly to the end user! I find Launchpad nicer (than Bugzilla, Trac, Github) when it comes to writing bug reports.
Thanks, Allan, for trying to improve the situation in this area. I have one suggestion as well.
Currently, a significant number of developers/maintainers discourage any larger discussions in Bugzilla. If the solution is not immediately clear, and different users propose different solutions and compare them, or try to persuade the developer, the response usually is “Bugzilla is not a discussion tool. Please go discuss this somewhere else, we have a lot of mailing lists.”
I understand their thinking, I have my own projects too. They want Bugzilla to be a ticketing tool with short and clear problem definitions and pending patches, not a discussion tool. The problem is that this is very unfriendly to any external contributor (not already subscribed to the right mailing lists and not familiar with the processes). They are basically expected to do this:
1. Find the correct mailing list
2. Subscribe and set up mail client filters
3. Create a new email thread, summarize the problem, propose some solution
4. Hope that the component maintainer will respond to that thread (and he might not be even subscribed to the list)
5. Hope that people previously discussing in Bugzilla will also continue the discussion on this mailing list
6. In the meantime, try to ignore all other traffic in the mailing list, which he’s not interested in
7. Don’t unsubscribe from the list for a long time, because you might then miss some reply
If another community person finds that Bugzilla report and wants to add something to the discussion, he’s expected to:
1. Find a link to the mailing list discussion in the Bugzilla (might be buried in the comments)
2. Read the previous conversation using the mailman web interface (quite inconvenient)
3. Subscribe to the list with all those troubles mentioned above
4. Try to reply to some existing message, which is quite hard to do without having the existing emails in your inbox (nothing to Reply to, difficult to reply to the thread instead of creating a new one, extremely hard to reply to a subthread)
On the other hand, discussing in Bugzilla have these advantages:
* the discussion location directly related to the issue, not in a separated place
* easier to find for other external community members (when searching for the issue in question inside bugzilla)
* no problems with reading the discussion history and with replying
* people don’t receive unrelated discussions in their inbox
and a disadvantage:
* annoyed developers, because discussions are mixed with work tickets and it’s harder for them to navigate the tool and organize their work
What if GNOME proposed some guidelines to actually support public discussions in Bugzilla, while still keeping the developers/maintainers happy? For example, a very simple idea:
1. If there is a larger discussion in a ticket, and the solution is not clear-cut, the maintianer can prefix the ticket summary with “[discussion]” keyword.
2. Users, designers and developers discuss the issue. In the meantime, developers know that they can mostly skip these tickets when planning their work, and check them just once in a while (in case they don’t want to participate in the discussion and leave that up for a designer, for example).
3. Once a good solution is found, a new ticket is created (by the developer, or designer, or an active user), linking to the discussion ticket. That new ticket will be clear and concise and developers can use it for proposing and reviewing patches, as usual.
Sorry for such a long explanation, I just feel this is one of the major areas where GNOME can improve its friendliness and community collaboration. If you can do something about this, thanks for considering.
Check out firefox’s implementation of bugzilla. They have designed a form which allows bug reports to conform to a template, I think if GNOME were to implement a similiar idea to what Mozilla have done to theirs then it would improve GNOME Bugzilla.