How to help with the project* modules

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!
Posted by dww on April 16, 2007 at 9:45am
Last updated by cpliakas on Sat, 2011-06-04 14:00

The project* collection of modules (Project, Project issue tracking, and CVS integration) is the largest set of code running on drupal.org besides Drupal core. They are the key tools that power all Drupal development, including the Drupal issue queue and Drupal release system. Because of the huge user base, high visibility, complex requirements and feature requests, and size and scope of the existing code base (and issue queues) there is a ton of work to be done. This wiki page is how I (dww, the primary maintainer of project*) will try to communicate the best ways for other people to get involved in helping. One of the ways to help is to improve this list, so please add your own ideas here.

This list is roughly in order of what kind of skills you'd need, but not exactly. It's not in priority order, since all of it would be helpful, and it's hard to prioritize given there might be many people with different skills or interests. So, just read the whole list and decide what parts of it you'd like to help with. In terms of the issue queues, you can obviously prioritize things marked as critical.

  • Join the New Release System group.
  • Read the handbook pages about the project* modules on drupal.org. Figure out how to install your own local test site running 5.x Drupal core and the latest versions of these modules. Improve and/or extend the handbook pages as you go.
  • Read this post about the drupal.org testing installation profile. See if you can help make that profile more complete, if you can get it to work, if you can contribute documentation on how to use it, etc.
  • Read these 2 issues about testing on http://scratch.drupal.org :

    They're slightly out-dated, but the basic idea is still valid: see if you can find any new bugs, and if so, report them. Both of those pages include detailed instructions on where to report any bugs or problems you find. Please don't submit duplicates, see below. ;)

  • Read through the Project* issue queues:

    Familiarize yourself with what's there now (this is a fairly huge task on its own). Then, here are the ways you can help clean-up the queues to make them more manageable for other users and developers:

    • Find duplicate issues and mark the newer issues duplicate, including a link to the oldest issue in the queue about the same thing.
    • Older issues that are no longer relevant should be marked "Fixed" (e.g. things that are now working because of the new release system, etc).
    • If an issue's title isn't clear, try to figure out what the issue is about and give it a more descriptive and acurate title.
    • See if you can reproduce any of the bug reports on a local test site. Start digging into the code and see if you can figure out anything about what's going wrong. No matter what, report your findings in a follow-up in the issue so other people can see your results. Just knowing if you can (and how to) reproduce a bug on a local test site is a huge step towards fixing the problem.
    • ... (feel free to add other suggestions here)
  • Keep an eye on the webmasters and infrastructure issue queues for bug reports and feature requests that really belong in one of the project* issue queues:

    Since project* is so central to the functionality on drupal.org, people often request features or report bugs to these issue queues, not necessarily realizing that there are separate queues for the project* modules themselves, and these bugs or features almost always exist or would work on other sites running the project* modules. If you find issues in either of these queues that is general to Project* code, not specific to how it is setup on drupal.org, move the issue into the appropriate project* queue.

  • Keep an eye on the drupal.org forums for questions about project* and see if you can answer them, point the person to the appropriate issue if it's a known bug or feature request, etc.
  • Read the CVS handbook. See if you can find ways to make any of the pages more clear. If you've got documentation powers on drupal.org, try to fold comments into the body of the page and delete them. If you're unsure, just ask me (see below).
  • Read the Maintaining a project on drupal.org handbook. See if it makes sense. See how much of it should be folded into the general project* documentation, or if there's a better way to organize this information.
  • If you haven't already, read the patch handbook. Then, take a look at the "patch queue" for these modules (all issues marked as "Patch (code needs review)"):

    See if the patch still applies to the version it's reported against. If not, set the issue to "Patch (code needs work)". If you can, resolve the conflicts and re-roll the patch for that branch, post your new patch to the issue, and set the status back to "code needs review". If it's a patch for a feature request, see if it applies against HEAD, or the DRUPAL-4-7--2 branch, and set the version of the issue accordingly. No matter what, if the patch applies, test it. Again the patch handbook has great instructions on how to apply, review and test patches, so read that if you're unsure what to do.

  • Test all of these modules using PostgreSQL. There are some known issues in the queue, so review, apply, and test those patches first. If you find any new problems, submit detailed bug reports about them.
  • Dig into the code and see if you can understand any of it. ;) If you figure out something that seemed cryptic at first, write some helpful comments in the code and provide a patch for it. If you find a function without doxygen comments that explains what the function does, what kind of input it expects, and what output it produces, write the comment and post a patch (feel free to include more than one function's comments in the same issue/patch).
  • Check out the list of Future work for the new release system, and see if any of it interests you enough that you'd like to start working on a patch for something. If so, follow-up to the issue, assign it to yourself, and start sketching out your thoughts on what needs to happen. Feel free to just ask questions in the issue about implementation details, etc.
  • Add to this list.

I'm often available on IRC in #drupal (my nick is also "dww"), and I try to lurk in #drupal-dojo whenever I get the chance. Feel free to add a comment below if you want to get my attention about something. If you have a question about an issue, just followup to the issue itself, since other people might be able to answer it.

That should be more than enough to get anyone started, no matter what skills you have to offer. ;) Please dive right in and help in whatever ways you can. Drupal.org and project* need you!

Thanks,
-Derek