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?) 😉
Elijah, not quite agree with you. Problem is here that we should have concrete goals for Q&A and polish, because, quite frankly, features doesn’t matter when they simply doesn’t work. Yes, GNOME is free software, everyone should participiate, etc. etc. BUT we should have goals anyway, because it can give us feeling later that we have achieved something. And not only that – it could motivate advanced users to join bugsquad and help a hand. In the end they will see results and…they will be simply happy and motivated to help more in future.
But then again, I reread your post, and to the part “what we should do” I agree wholeheartly, I would see more blog entries and disscussions about bugs which are hard to solve/triage/reproduce. I love the way Gstreamer guys to do that.