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:

  • Does make check work after applying the patch?
  • Coding style: without writing down all the details of GTK+ coding style here, does the patch follow the coding style of surrounding code? (Watch out, gdk-pixbuf follows different coding conventions than the rest of GTK+)
  • If the patch adds API, make sure all new APIs are added to the right headers, to the $MODULE.symbols files and to a suitable section in $MODULE-sections.txt in the docs.
  • New API must have docs; check that it has a "Since: $VERSION" tag, where $VERSION is the next stable version, and follows the established conventions for doc formatting, like
    • use %TRUE, not TRUE or #TRUE or @TRUE, same for FALSE and NULL
    • use foo() to refer to functions, to get cross-references
    • use @arg to refer to function parameters and struct fields

    • use #TypeName to refer to types like objects, enumerations, etc

    • use #TypeName::signal to refer to signals, to get cross-references

    • use #TypeName:prop to refer to properties, to get cross-references

  • Public API should have g_return_if_fail() checks where appropriate, internal functions not.
  • Memory management: are local allocations correctly cleaned up? Look at error paths too. Does the memory handling of property getters and setters follow established conventions?

* 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:

  • sign up for the task, possibly communicate with other volunteers;

  • submit small patches in diff -up format via email to gtk-devel-list@gnome.org or another contributor who already has commit rights;

  • after some initial mutual familiarization phase, you can apply for an Git account if you have the backing of some core developer: http://live.gnome.org/NewAccounts

Attic/GtkTasks (last edited 2013-11-23 00:02:11 by WilliamJonMcCann)