The project management team, with input from some d.o. admins, decided to create a dedicated Drupal.org Redesign project as well as a separate project for the redesign's theme, Blue Cheese. Currently, the issues are being re-classified, except for issues that are in the infrastructure project and related to staging.
Drupal.org redesign issues were filed to a variety of projects (d.o. infrastructure, d.o. customizations, d.o. webmasters and some others). At the time of writing, there were approx 180 open issues.
Why have we done this?
-
Dedicated redesign-related projects would make it easier for our 20+ new contributors to categorize things more easily. The main reason for creating project pages is to make sure we have a common place to track issues. They won't have to wade through a ton of unrelated tickets.
-
Since there's a dedicated team of admins, project managers, themers etc, they can get in there and do what we like with our issue queue without interfering with the other admins.
-
It will make it a lot easier to point people to the project on d.o., rather than a long and unwieldy URL containing tags.
-
Due to the way email subscriptions work on d.o., people will be far more likely to subscribe to all issues on the Blue Cheese project than they will to subscribe to all of infrastructure.
- Likewise, now the infrastructure guys won't be notified of every redesign issue (many of which will be irrelevant to them).
Unfortunately, the negative effect of this is the other project maintainers that have projects relevant to the redesign won't see the issues in their project overview page.
Hope this clears up a few questions. Thanks.
Comments
Combatting invisibility
I think this could be mitigated with "meta" issues. Like say there's an issue in the d.o redesign queue that requires a few decisions from the Project module maintainers, you could add issues to Project module's queue with the details, make a new issue in the d.o redesign issue that's "postponed", and link it to the dependent issues in the Project module queue. This gets you the best of both worlds because things are still tracked centrally but the "meat" is also located in the queue that's most appropriate.
That sounds like a super
That sounds like a super idea. Why didn't I think of that?! :)
Yes, I'll def. do that for any projects that aren't infrastructure. The infrastructure issues either a) genuinely don't belong there or b) will remain in infrastructure because they related to the staging sites or something like that.
==================================
http://about.me/lisarex
Actually...
(comment modified)
I think it is still most useful to have new module/project issues added to the Redesign project (we've already given this instruction to the implementers as well).
I'll monitor the redesign project issue queue and create meta-issues in the project's issue queue as needed.
New issues that are specific to the project could also be marked with a component called 'module' http://drupal.org/node/640696 and/or tag.
There are about 51 module/project issues tagged 'drupal.org redesign' and I'd be happy to leave the remaining ones where they are, but create a meta-issues for them in the redesign queue. This seems like less work.
==================================
http://about.me/lisarex