Man, it’s so cool when new people show up and just start exterminating bugs left and right. It doesn’t happen very often, but Thomas Thurman showed up recently, tried fixing a couple Metacity bugs, emailed asking about what else he could do, and then took the large list of possibilities I responded with and appears to have decided that his answer to ‘which of these things should he pursue’ is ‘all of them’! Very cool. He’s already fixed a number of them and the patches just keep coming.
Hopefully, I won’t suck as much at patch review this time around. I’m afraid Björn Lindqvist, who had similiarly been fixing lots of stuff for us, probably decided to get interested in other projects when I went through a big unresponsive period last year. Sorry about that Björn, and much thanks for the many bugs you did fix.
Unfortunately, though, the next 2-3 weeks are going to be insane and will be *very* hard for me to be responsive to much of anything. But I’ll do my best.
John, those are great goals, but in general making official focuses on a subset of the range of possible improvements for Gnome would do more harm than good. And I say that as someone who spends almost all of his development time on Gnome by fixing bugs. I think Manuel Amador probably said it best when something like this came up previously:
For some odd reason, when people get told, say, “gnome 2.8 will
focus on performance”, only the hackers which like performance
hacking will be stimulated to work. IT’s almost as if you told
everyone “gnome 2.8 will ONLY do performance work”. Focusing
generally stymies those who think they don’t share the focus.
That’s not to say that we can’t try to increase the focus on bug fixing. Luis had a good comment in that same thread as well:
FWIW, it is my experience in previous gnome development cycles that
these things happen when one person takes responsibility for them
and nags widely and actively, ideally sowing code along the way.
Saying ‘everyone please set your own goals’ or ‘audit your own
stuff’ leads to sitting around at the end of the cycle and
wondering why the goal wasn’t achieved.
Obviously, fixing bugs yourself is one way of contributing. But there are lots of things non-developers can do to help increase work and attention in this area:
- Join the bugsquad and triage bugs
- Search for bugs that have been fixed recently or are being worked on. Blog on them. Providing a spotlight on some cool work going on motivates others to do similar work
- Try to find steps to duplicate common but hard to reproduce bugs. Add the information to the relevant bug report. (Here’s an example of one I did back before I became a Gnome developer)
- Volunteer to create showstopper review lists. These can help a lot, but this has been heavily neglected the last couple of cycles and we need more help.
- Try to find other volunteers to help with creating those showstopper review lists. This could include things like making a wiki page with general guidelines on making good showstopper review lists (some basic steps and examples already provided in that email, it just needs to be put together and then sent around to others for review and comments). Or blogging about it when someone else makes one. Or blogging about trying to get someone else to do it (man, am I lazy or what?)