Amongst many other things during the Gtk+ Hackfest 2008, it was brought to my attention that Gtk+ maintainership is sometimes perceived as some kind of leet circle, hard to join for newcomers.
I can’t really imagine how "hard" it is for newcomers to join Gtk+ maintenance these days. The learning curve probably is steeper now than it was in the last decade, but then, we do have documentation now and didn’t have any back then… ;-)
In any case, I think that definitely none of the Gtk+/GLib core maintainers would want to bar someone else from contributions or helping out with maintenance tasks. So to aid that process, I’ve written down what I keep telling people who approach me about this in person. A lot of it might seem overly obvious to veterans, but for newcomers or contributors looking into extending their activities on the project I hope to provide helpful starting points.
Much of Gtk+ is still maintained as a huge monolithic whole. That is, a very few people are taking care of a wide variety of components. I think ultimately we would all be much better off, if we had more people being responsible for individual components like particular widgets (e.g. GtkNotebook) or widget families (e.g. GtkBox, GtkHBox, GtkVBox). So the following are steps and tasks useful for anyone wanting to get into Gtk+ component maintenance.
First of all, we have the GtkTasks wiki page, a task list with various ways in which people can contribute to the Gtk+ project and start getting involved. In particular for the following positions, no one has signed up so far to volunteer on a regular basis:
-
Patch/Bug Monitoring & Filing - collect bugs from mailing lists and IRC to make sure they are being filed.
-
FAQ Maintainer - this involves monitoring the mailing list(s), taking CC:-mails from other people on possible FAQ material and regularly updating the FAQ accordingly.
-
Build Monitoring - run and maintain Gtk+ tool-chain builds on various platforms.
-
Making Releases - we are looking for someone assisting in the release process and to take over release building during some periods in the future.
-
Implementing Test Programs - there’s much work needed in our unit test coverage, so we’re always looking for people willing to implement more unit tests.
For general information about the maintenance situation, the State of the Gtk+ Maintenance write-up is still fairly valid. However many good things have been suggested by the community since, such as the GtkTasks page and the Hackfest. At the end, the write-up addresses how occasional contributors or developers at different experience levels can help out the project. For instance with activities such as: Bug triage and verification, Review and clarify documentation, Revision hunting for regressions, Refactor code areas, Work on optimizations, and the list goes on.
If none of this sounds interesting to potential new maintainers, be warned that regular maintenance means having to put up with pretty much all of these at some point. ;-) However, probably the most straight forward way to take on maintenance for a particular code portion (usually a particular widget) is to start becoming familiar with it and work on improving it right away:
-
Cleanup indentation - lots of contributions to Gtk+ in the past have weakened coding style in various areas. In general we use GNU coding style plus a few extra rules similar to the Gimp coding style.
-
Perform code cleanups - look for outstanding migrations/refactorings in the code or if the implementation could be simplified/streamlined in areas.
-
Check documentation and examples - contributing by improving the existing documentation, testing existing examples and providing new ones is a very straight forward way to learn about a new component. Also, documentation patches are usually easily and quickly approved.
-
Provide unit tests - writing new unit tests for existing component APIs is even better than providing documentation examples. You get immediate feedback and they should in general be easy to approve to go into upstream. Also, it is definitely an area where Gtk+ and GLib still need lots of work.
-
Review bug reports and patches - go through the Gtk+ bug load of a particular component, see what issues could be closed or need info. Find patches that could be applied or need work and provide/fix patches along the way. Also, feel free to provide review for existing patches where you feel confident to provide reasonable input. For existing maintainers, looking at other people’s review is one of the best ways to figure if another person is up to the task of taking over component maintenance.
-
Actively nag existing maintainers or people with SVN accounts for trivial patches (like Cody and Mathias who signed up for Patch testing & committing) to review, approve and apply your changes.
-
Participate in the project forums like gtk-devel-list and #gtk+ (needed to nag people from the core team and other developers), and read and reply in other related mailing lists.
The first few points actually mean working with the code by providing patches, and filing new bug reports with those patches attached. While this may at first increase our bug load, if someone shows sincere interest in taking over component maintenance, sticks to the coding style and provides useful patches, there’s nothing stopping us from granting new SVN accounts so contributors can commit their own patches after approval.
Finally, the project is welcoming every new contributor. But be reminded that no approval is needed from anyone to start your work. In actuality, asking for it will most probably get you a reserved or negative answer, because improving the project is all about working on it, not making or requesting promises. So, everyone is invited to read through the task lists/descriptions and get their hands dirty immediately. A fair bit of self incentive is needed to take on maintenance of a component anyway, so you’ll have to get yourself motivated on your own there won’t be anyone else doing it for you.