[development] The future of the project module(s)

[Robert Douglass]

That's great news Chad! The project management tools are already the 
part of Drupal.org that works the best, and the three of you working 
together will be able to hone that shine =)

-Robert

Chad Phillips -- Apartment Lines wrote:
> After conversations with Derek, Dries, and Killes, I'd like to 
> formally announce my new role as the official co-maintainer of project 
> module, and related modules (cvslog, project_issue, etc.).  Derek and 
> I will be working together to provide support and direction for this 
> very important suite -- as co-maintainers, we'll share final say on 
> how things work in the project world, subject to the needs of drupal.org.
>
> This is extremely good news, as Derek has labored too long alone with 
> a workload that outdistances what a single great coder can do.  ;)
>
> I'll be coming on for day-to-day duties starting August 1st, which 
> luckily will be in plenty of time for the 6.x conversion.  At that 
> time we'll also begin prioritizing and knocking out items on the 
> currently very large to do list.
>
> Finally, listed below is a brief summary of our mutually agreed 
> big-picture priorities for project*:
>
> 1) Improve how it supports the d.o's development process 
> (functionality, bug fixes, usability, etc).
>
> 2) Continue to make it general enough to be used at other sites.  
> We're finally turning the corner with this (e.g. with 
> http://jquery.com/plugins now a project*-based site, and certainly 
> others).  This step probably includes deploying a drupalorg.module 
> soon, for truly d.o-specific code that should be moved out of project* 
> completely.
>
> 3) Make the code easier to maintain and work with, to facilitate 
> others contributing patches, testing, etc.
>
> 4) Move towards reusing existing functionality instead of 
> re-implementing everything in project* (e.g. followups as comments, 
> generic subscribe functionality, actions integration, eventually CCK 
> integration, perhaps views + workflow, etc, etc).  This should help 
> with #3, as we rip out large portions of ugly code and move towards 
> re-using well-supported existing code from other modules.
>
> Chad (aka hunmonk)
>