Report from Project 7.x-2.0 BADCamp Sprint

Taking advantage of the immense Drupal talent in town for BADCamp we decided to host a sprint to redesign the Project* suite for Drupal 7. We had a great turn-out of Drupal rockstars who wanted to help get Drupal.org closer to running D7 and to help with the future of our community's collaboration tools. In person, we had:

Attending remotely (for at least parts of the sprint), we had:

Accomplishments
Battle plans

Everyone had a lively discussion at the start of the sprint on the basic UX and architecture for the D7 versions of the Project* suite. We decided that although we definitely want multiple node types that can behave as projects and issues, we didn’t need to make these their own top-level entity types and that we basically want everything leaving them as nodes gives us. Plus it’s less work for data migration.

In terms of the issue user experience, instead of the code and UI/UX complexity of trying to turn comment forms into issue editing forms, we’ve decided it’s going to be better all the way around to just let people edit issues directly and change all the meta data that way. When this happens, we’re going to generate a comment describing the change. We’ll use the revision log message from your edit as the body of the comment, and also include all the differences to issue fields (so reading an issue will look pretty much like it does now). The UI will be enhanced so it’s not just clicking on the edit tab, but effectively, that’s how it’s going to work. We had some debates about if these should be actual comments or a per-issue activity stream since both approaches have a number of pros and cons. We’re leaning towards just using comments since lots of other plumbing will continue to Just Work(tm) if we do that. It’d sure be nice if core supported multiple comment entity bundles on a single node type, but alas, that’s not the case. So, we might switch gears and move to an issue activity entity approach down the road.

We also decided that release nodes have so much custom magic, they’re going to be our lowest priority for doing a deep port to core fields. We’d like to do that eventually, but the win we get from doing this for projects and issues is huge, while the win on releases is less obvious. Since we have limited time/resources, we need to pick our battles.

New Git branches

dww started the morning by creating and pushing 6.x-1.x branches for http://drupal.org/project/project and http://drupal.org/project/project_issue, then created 7.x-2.x branches of both, cleared out a ton of obsolete code, and pushed those to git.drupal.org as well. This is where many of the changes from the sprint are being pushed.

Viewing node changes as comments

To enable the new issue queue experience of directly editing the issue to change anything, chx worked on cleaning up the http://drupal.org/project/revisionreference project for use on issue comments. Those efforts are currently living at http://drupal.org/sandbox/chx/1320416. And by day two, we now have http://drupal.org/project/nodechanges which does all the magic of posting comments that display the diff whenever a node is edited with a new revision.

Machine name field

beejeebus and hunmonk built the http://drupal.org/project/machine_name module, which provides a machine name field for any entity. This takes advantage of the D7 FormAPI machine_name form element #type and exposes it as a Field API field you can attach to any entity bundle. We’re using this for the project shortname on project node types, but since it could be useful to anyone, we published it as a separate project.

Project node type with core fields

hunmonk wrote code to define a default project node type with core fields for title, body, a machine name field (see above) and the project’s allowed components. This lives in the 7.x-2.x branch of http://drupal.org/project/project. We explored the possibility of doing this via a Feature, but it turns out that makes it harder to customize these node types and manage them in your own features. So instead, the node type is just a default type created when project.module is installed, and sites are free to customize this type (or create others to act as a project node type) and manage those customizations however they see fit (using features or otherwise).

Project issue node type with core fields

dww wrote code to define a default project_issue node type with core fields for things like priority, status, category, etc. He started fleshing out the more tricky fields like component where the allowed values on the issue should be populated by a multi-valued field on the parent project and the assigned user (which needs to know the specific issue node and project that issue belongs to for determining the allowed values). This code is in the 7.x-2.x branch of http://drupal.org/project/project_issue.

Project install profile

mlncn built the http://drupal.org/project/projectinstall install profile. Although we’ve had the http://drupal.org/project/drupalorg_testing profile for many years, we just wanted a drush make file and install profile to make it easy for sprinters (or anyone else) to assemble all the requirements for the Project* suite to get a D7 dev site up and running. Especially since we’re trying to move as much functionality out into generic solutions as possible, we need a simple way to satisfy all the dependencies. We’ll probably build out a D6 branch of this in the future to serve as a simple place to get a simple issue tracking collaboration site up.

Data migration

Moshe worked on starting to build out the project_migrate family of modules to be able to migrate data out of the D6 schema into the new node types and core fields we’re fleshing out for the D7 versions of everything. This code doesn’t yet live in a sandbox (Moshe had to leave a bit early to catch a flight) but it’ll be folded into project, project_issue and the drupalorg_project D7 sandbox ASAP.

UX/UI research

kyle_matthews worked on researching the user experience and interfaces for a number of existing issue tracking systems to find common patterns and functionality and see how that compares to our existing interface and our ideas about the new interactions we’re planning to build. The results can be found in this flickr set http://www.flickr.com/photos/82268668@N00/sets/72157627969963444/with/62... and at this Google doc: https://docs.google.com/document/d/1gGipnivb_uIa7Qez6ypU4hwpL9_9dxP_0KQw...

Drupal.org porting preparations

drumm mostly worked on looking at Drupal.org-specific porting tasks, planning out automated dev and staging environments once more dependencies have been ported to D7, etc. Meanwhile, beejeebus started a sandbox for a D7 version of the drupalorg_project module (which is part of the http://drupal.org/project/drupalorg project) so we can already start putting drupal.org-specific code into the right place. For now, that all lives at http://drupal.org/sandbox/justinrandell/1320382 (since we didn’t want to create a 7.x-1.x branch of the drupalorg project yet since that makes it much harder to maintain the live Drupal.org).

hunmonk built and exported the initial features for the Module and Theme node types that will be used on Drupal.org, and pushed them to the sandbox.

Next steps

There’s still a ton of work to do. Even from a project management standpoint, there are a ton of issues that need to be posted, plans drawn up, etc. Since we didn’t have a dedicated project manager on the sprint, we decided to prioritize Getting Things Done and trying to circle back to draw up future plans once we’ve had a chance to digest the results of our work and have some of the follow-up discussions that need to happen. For now, anyone interested in helping can follow either/both of these issues:#834252: [meta] Port Project to Drupal 7#963426: [meta] Port Project issue tracking to Drupal 7
There are also now 7.x-2.x-dev versions in both issue queues, so you can keep an eye on these:http://drupal.org/project/issues/project?version=7.xhttp://drupal.org/project/issues/project_issue?version=7.x
Stay tuned for another update once we’ve got a more specific roadmap hashed out and/or another sprint planned.

Thanks again to everyone who participated!
-Derek

Original Article: