Project D7 redesign sprint - Oct. 24-25 - SF Bay Area

If you've been involved with Drupal for any length of time, you have most likely used the features provided by the Project Suite (project, project_issue, project_release, etc.) on drupal.org, which provide community-critical features such as:

  • Issue tracking
  • Issue e-mail notifications
  • Release management
  • Release packaging/downloads
  • Project usage tracking
  • Project searching

Without the functionality provided by this suite of modules, it would be much harder for the Drupal community to get its work done, and to distribute the fruits of that labor for others to use.

However, if drupal.org is "probably the oldest continuously-running Drupal site"[1], then the Project Suite is one of the oldest code bases in Drupal outside of core. Although it was originally authored and maintained by Kjartan Mannes, it went through a multi-year period where it was maintained by a variety of contributors, each doing a small part to keep it functioning on drupal.org as Drupal matured. Unfortunately, this led to a 'just make it work' approach to site upgrades and new features.

In recent years, thanks to the efforts of dww, hunmonk, mikey_p, bdragon, and others, the suite has been significantly rehabilitated, making it both more maintainable for drupal.org and more generally usable. However, many warts and design flaws still remain.

The release of Drupal 7 offers a unique opportunity for the future of the Project Suite. Many of Drupal 7's new features enable building this kind of functionality much easier. We maintainers intend to redesign the suite from the ground up using Drupal 7, and then provide a data migration path from the D6 database schema. This is a big job, but frankly, so is updating the Project Suite from one version of Drupal to another. We're inspired by the approach and success of Drupal Commerce in doing a similar effort with the wisdom they gained from working on Ubercart, so we're hoping to accomplish something similar in this problem space. Instead of focusing on just building a product, we want to build a good framework that different products can be built on top of (including a product that can be a drop-in replacement for the D6 version of the Project Suite).

To that end, we've organized a Project Suite D7 Redesign Sprint for October 24th and 25th, the Monday and Tuesday following BADCamp. The goal of this sprint is straighforward: develop a plan to rebuild the current functionality provided by the Project Suite using Drupal 7, making it both more maintainable by the community, and more usable as a project management tool. The module co-maintainers will both be present for the sprint, and other interested parties are invited to attend (both in person or remotely via IRC (#drupal-project on freenode) and the issue queues).

We're still locking down the logistics for the sprint itself, including the venue. It depends on how many people are going to physically participate vs. people who want to contribute remotely. Although we'll probably be talking about this all weekend at BADCamp and might start earlier, the formal sprint will be approximately 9am-9pm on Monday, and 9am-6pm on Tuesday. Please leave a comment here on this post with your intentions of joining the sprint so we can make final arrangements. Be sure to clearly specify if you'll be here in person or not, which days/times you're available, etc. I'll privately e-mail everyone who wants to come with the final location so you don't necessarily have to worry about checking back for updates about the details.

After the sprint we'll publish a follow-up post with more information on the plan, and how others in the community can help with the job of the actual rewrite. To get the process started, I just updated the issue summary at [meta] Port Project to Drupal 7 so interested parties can follow (not subscribe!) to that. ;)

We're looking forward to seeing many of you here in the beautiful East Bay this weekend for BADCamp, and we hope some of you can stay and join us for this sprint!

Thanks,
-Derek and Chad

Comments

:-(

Oh, I wish I would had known sooner. This definitely would had convinced me to head out to BadCamp

I'll be participating remotely via irc and the issue queue.

Sorry for the late notice!

I know -- I wanted to get this post up about 2 weeks ago but life and work have been crazy recently...

Thanks for your interest, though! Hope to see you in IRC and the issue queues...

And we'll almost certainly have follow-up sprint(s) to work on implementing the plans we come up with at this one. ;)

Cheers,
-Derek

I'd like to participate

I'd like to participate remotely. I'll be at work for part of it, but if you want to skype me in, I can listen to conversation and use chat to contribute where I can.

can help

I don't have any experience with the project* modules but I'm in between jobs so have plenty of time and would love to help out if I can. I live in Palo Alto and can go to wherever the venue is. I'll plan on coming both days but my availability might shift depending if job interviews get scheduled for part of those days.

Reporting for duty

I will be there both days IRL.

day 1

i'm there on day 1.

Differ

Just wanted to point you guys to the Differ module I have in my sandbox. It is based on Damien Tournoud's DrupalCon presentation on a Field-API-based issue-tracking module. It is far from finished (I don't think it even works as is), but maybe you can use it as a starting point for something. I probably won't be able to be in IRC myself (let alone in SF), but I wish you guys all the best for this massive undertaking. :)

First day only

oh and also i can be there the first day :-)

Focus on collecting better data

David Eaves, who has done a great deal of work with the Mozilla community, spoke at Pacific Northwest Drupal Summit. Ha made a very clear plea for better tracking of data related to people's participation and contributions in projects and their issue queues.

His thesis is that social capital is our capital: How do we expand and grow and improve it? Why not track and manage it?

  • Total commits; Activity per month; This person has not had a patch in 40 days. Maybe we should call them.
  • Track code review wait times. Developers get frustrated if they submit code, and it disappears. Simply not knowing is deeply frustrating. Simply tell them what the average wait time is-- if it's 12 days or whatever.

Melissa Anderson, Randy Fay, Peter Davis, Alex Bronstein, Joshua Brauer, and Jon Duell helped him gather and interpret the data, and would know more about it than i do.

Other things a ticket system should do to filter the otherwise overwhelming number of submitted tickets before it forces those doing the work to behave rudely:

  • automatically search, and try finding the five tickets that might be the answer to your problem.
  • Encourage people to Inquire (why are you trying to do x, what is the real goal), Paraphrase (our issue summaries, yay!), Acknowledge (your point is valid), and (only at the end) Advocate (here's what i think we should do).
  • Broadly, do not put any restrictions on people contributing. For Mozilla he gave the examples of allowing anyone to do anything with add-ons, and then addressing the problem that add-on authors don't have an incentive to keep the memory consumption for their particular add-on at a reasonable level by putting this data where users downloading add-ons can see it.

    These notes are very much in my words, and incomplete and in the wrong order. Unfortunately PNWDS sessions were not recorded but i very much encourage everyone to watch David Eaves DjangoCon Keynote.

I'll be there

I'll be there

Looking at other issue tracking / project management tools

Let's borrow a page from WSCCI and do a thorough review of the ways-of-doing-this-outside-Drupal.

Eaves was blunt:

It's time for you guys to use a real bug tracking system-- i recognize that Drupal can do it, but very hard to get meaningful data out of it. The belief that Drupal can do everything is a profoundly wrong-headed belief. You have to accept the premise that there are things Drupal is not good at. Recognize strengths. You cannot do issue tracking and code. Go support an open source project that does that.

The next ten years of open source will be very painful if you cannot get real data out.

After a surprisingly successful (but not sustainable) mash-up of Drupal 5.x project module and Organic Groups, Agaric has tried a bunch of PM tools, and are currently very happy with Redmine/ChiliProject. But as much as i want to sound responsible and say "there are tools that do this better than Drupal", i know Drupal can do this job, and it is the best positioned to move from software project management to community project management-- and then we're talking a gift to the world greater than Drupal itself.