Three weeks ago, Elijah asked me to write an entry explaining how to participate in the release process. I told him I'd do it the next day. So, here we are, three weeks later :-)

It all started with a discussion in the release team about how we could involve more people in the release process. Sometimes after the discussion, Elijah sent this mail. But I believe not enough people have seen it and I'm pretty sure there are a lot of people reading the planet who wonder what can I do for GNOME?. If you're wondering this, search no further.

There are a lot of ways to contribute to GNOME, and GNOME Love is well known. Some people think it's difficult to get in, but it's not. It's really easy and you can even help with our release process. There are many areas where you can help for the release process, but three of them are the most important:

• Writing release notes. The release notes are essential in our releases: this is the first thing people read, to know what's new in the latest GNOME. The notes need to be clear, list all the cool new features and enhancements. They need to be ready a few days before the release, in order to enable translators to translate them. Everyone can help with the release notes. It's really easy. You can do some screenshots or you can write the text. We even have a page on the wiki listing the release notes items. There are already some volunteers ready to help for the release notes, but a small team would be fantastic! If you're interested in this, please contact marketing-list.

• Bugs and patches nagging. There are a lots of bugs in bugzilla. In fact, there are so many bugs that, sometimes, the maintainers can't look at all of them. And they forget some bugs. Big crashers. Localization/internationalization bugs. Patches. Even approved patches. Some of those bugs are easy to fix, some are showstoppers. If we want to have really good releases, we need to fix these bugs. But this implies that we need to find them and know about them. This is where the nagging game is: someone sends a list of bugs to the right mailing list and after a while, maintainers get so ashamed that they have to fix the bugs ;-) Good examples of nagging are: showstopper bugs, internationalization bugs (they have to be fixed before the string freeze), bugs with an approved but not committed patch, bugs with unreviewed patches, etc. You can easily generate some useful list of bugs with bugzilla, so it's not hard. Interested in this? Send a mail to gnome-bugsquad!

• Testing the releases before they go out (smoketesting). Before we do the actual release, we always build the whole GNOME and test it a bit to verify there's no huge crasher. That's what we call smoketesting. It's really easy: you only need to use jhbuild for this and Elijah wrote a nice howto. So, here's the deal: before each release, the release team issues some module sets for jhbuild. Everyone can then build what will be the next GNOME release and verify it compiles fine and works. If it doesn't compile or if there's a showstopper bug, then contact the release team or the maintainer of the relevant module. It should help make our releases be more solid. And with more people smoketesting, the releases should be rock solid! I'll post a blog entry tomorrow to let everyone be able to smoketest GNOME 2.13.2.

See, there is a lot of stuff where you can help. If you want to help in some other way but don't know how, look at this page. And if after this you're still lost, don't be afraid: ask. If you don't want to send a mail to a mailing list, send a mail to someone. If you don't get an answer, try again. You know, GNOME contributors are busy people. But also nice people :-)

Do you want to contribute? I know you want.