This site has been retired. For up to date information, see handbook.gnome.org or gitlab.gnome.org.


[Home] [TitleIndex] [WordIndex] 

GTK+ Volunteer Tasks

This page is an openly-editable wiki page used to structure volunteer contributions for the Gtk+ project.

Contributors/volunteers willing to work on particular items quasi regularly should sign up with their name and email address for a particular task so efforts can be coordinated. People should also remove their entries if they have to step back from tasks at some point, so others know which tasks are up for grabs.

The actual task list is subject to change as we identify needs of the project (here is the initial Task List Proposal).

Permanent Tasks

Transient Tasks

Resources

Notes

#Person

Please sign up for a task by adding your real name and a working email address. Multiple people may sign up for a task, they should communicate with each other to avoid duplication of effort however.

#P1

Bugs regularly need to be sorted out and patches filed therein need to be tested and possibly adapted. A detailed description is given here: http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg00148.html (Re: Supporting Gtk+ Maintenance)

Beyond merely checking if a patch still applies or not, here is a list of basic patch review tasks that can easily be handled by volunteers:

* If a patch adds a significant new feature, it would be nice if it added a short blurb to the NEWS file

* If a patch makes a change that could potentially require some adaptation from existing GTK+ users, it should put a note in README.in

#P2

Patch snippets that get pasted/submitted via email/irc/etc. and that core developers can approve off head still need to be actually applied, compiled, tested with our test suite, be committed and potentially back- merged onto other branches. Someone signing up for this should have reasonable C knowledge, hang out on #gtk+ and be frequently reachable via email. Ideally people signing up for this already have Git commit access, if not, see: #Access

#P3

Sometimes bugs are being described on mailing lists or IRC without any record being taken on them in Bugzilla. It'd help to have someone who is responsible to wade through all emails on gtk-devel-list (and if possible other Gtk+ mailing lists and #gtk+) to make sure no bug description or patch snippet is lost by asking people to file bugs in Bugzilla and by filing things himself if necessary. It'd be nice for multiple people to sign up here, to split the mailing list loads. An SVN project related Google talk shortly describes this position in the SVN project: http://video.google.com/videoplay?docid=-4216011961522818645 (How Open Source Projects Survive Poisonous People)

#P4

The Gtk+ website http://www.gtk.org/ is kept in the gtk-web Git module and needs regular updates and fixes. At some points even redesigns may be in order. This task requires monitoring gtk-devel-list for possible new website content and some self interest in cleaning up the current site. (about Git access: #Access)

#P5

Many questions are regularly being asked and answered on the Gtk+ mailing lists and on the IRC channels. Frequently asked questions with answers should be collected and need to be integrated into the Gtk+ FAQ, tutorial or sometimes even the reference documentation: http://www.gtk.org/faq/ http://www.gtk.org/tutorial/ (about Git access: #Access)

#P6

It'd benefit the project to have someone in charge of contacting the developers regularly about meeintg agenda items, keep track of action items and to arrange/schedule those weekly meetings again.

#P7

The GLib/Gtk+ bug list in bugzilla is overwhelming and only slowly processed. Some bugs definitely have the neccessary contributors but lack core maintainer attention. In order for these bugs to get the required review attention, it'd be nice to have somone to repeatedly collect and nurture a list of bugs that are good candidates for inclusion and wait for review attention. This list can then be regularly presented during IRC meetings or on mailing lists to get the needed core developer attention. The wiki could be a suitable place to maintain such a list: GtkLove - Gtk+ Bug love list (bugs in need of developer attention)

#P8

It is important to ensure that GTK+ keeps building on all supported platforms (X11/Linux, X11/other Unixes, Win32, directfb, OS X), but the core maintainers can not always do that, since they don't have access to all these platforms. Part of this task could be to ensure that the build instructions for all platforms in the documentation are complete and uptodate. This is particularly important in the run-up to a stable release; traditionally, we have only ensured that a stable .0 release works on X11/Linux, and let other platforms follow later, but we could improve on that.

#P9

The unit test coverage for GLib and Gtk+ is fairly limited, so test program contributions are greatly apreciated. The following email gives a brief wrap up on the implementation of test programs: http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00181.html

#P10

For the last few years, releases have been made almost exclusively by Matthias Clasen . In 2008-05 he requested assistance with making releases and the ability to offload releases on to someone else for some periods. Someone with an Git account and previous experience in making releases for other projects should be suitable to step up to this task. More detailed information is provided in the upstream RELEASE-HOWTO.

#T6

Someone needs to lead/nurture the effort to collect Gtk canvas requirements from the community and in a second stage evaluate existing canvas projects for Gtk+ project inclusion feasibility as described in topic (4) during FOSDEM:

#T7

As agreed in gtk-devel meeting 2008 june, 3rd, we are going to migrate api docs comments from separate tmpl files to inline comments. the whole effort is organized in a GNOME-Goals like manner.

#Access

In order to get started with a task that requires commit privileges, such as gtk-web module editing, do the following:

2024-10-23 10:58