Drupal.org development process 2.0

Will this lead to a lot of duplicate tickets and/or repeated information, since most of these things will also need to be captured in project-specific issue queues? For example, a UX change to the project module will also need to go in that module's queue. I suppose the "Drupal.org changes" issue could just give a brief summary and include a link to the project.module issue for more information?

@tvn This is great to see its always been quite hard to follow all of the d.o issues. I'm quite confused why all of these items are not simply issues. Making them a different beast, will mean that I can't track them in my issue queue, I can't follow by e-mail, etc. etc. Can't we just add these fields to an issue? I fear that from first iteration till the 10th iteration, what you will be doing is adding more and more issue queue like functionality. I do understand the need to split it off.

1) As contributor, I'd like to be able to "filter" on whether it received a performance/ux review.

2) The V's for each review are cute, but that will be totally unscalable when you have 20-50 items on one page. I'd like to know when it "Passed" review or "Needs review" or "Working on fixing review items"

3) Just wondering if we can cut away some of the Stages. It gets a little bit unwieldy with so many in between states. I understand that this is needed for PM. But other than that many of stages will have 1-5 issues in them? for a short period.

Thanks for helping us to think this through!

I'm a vocal proponent of a better way to manage improvements to Drupal.org. I felt the pain directly and deeply when I managed the Git migration and have felt it more from the outsider's perspective as I've watched (and, from time to time, helped with) the Drupal.org D7 upgrade.

Thinking about Drupal.org projects, I see three main process areas. Issues certainly move between them, but I find it useful to zoom in on them separately for a while when thinking about process optimization.

Deciding what feature requests are good ideas
Is the suggestion a good idea? Has it been thought through from all the stakeholder perspectives? Who okays it? How is that known? Without being deeply involved, it's nearly impossible to obtain a high level view of what everyone wants.

Doing the work and getting feedback
Even small features can span more than one project. When that's the case, it is possible to pull things together with tags, meta issues, and the new issue relations but that's still error prone and time-consuming to maintain. Without being deeply involved, it's nearly impossible to obtain a high level view of everything being developed.

Getting the work deployed on Drupal.org
It's not easy to see what work needs to be deployed or to know how to ask. Experienced people know to tag with the 'needs deployment' tag, but there's no great way to see if it's been tested, etc. Deployments these days are performed by DA staff and a handful of experienced volunteers. The infrastructure to facilitate reviews (UX, security, performance, etc.) is coming along and with it a way of tracking it needs to exist. Reviews need to be done in the context of Drupal.org, not the context of a single module or a collection of modules.

Some thoughts ...

@mcrittenden, In the case of a single issue for a single module being deployed in isolation, it's definitely an extra step. It's somewhat less onerous for multi-module features, where it serves more like a meta-issue. Whatever can be done to minimize the feeling of make-work is valuable! At the same time, an extra, clear step that puts an emphasis on deployment instructions, reviews, and testing seems valuble. Now that the D7 upgrade has launched, hopefully we'll see an increase in the number of features that can be worked on, and we'll need to easily see where work gets blocked - at least those are my thoughts.

@Bojhan

Can't these be issues?

The probably could, if ...

The Status is customized. The Status settings are completely inappropriate for a workflow that doesn't directly encourage patches (patches belong in their respective queues). Fighting the community assumption that the Status should be the same for issues affecting the production web site vs. the development of a product isn't feasible.

Likewise, the Category and Priority fields need to be able to be customized, although they're less of a liability than the Status field.

I believe this is theoretically possible by creating a new Project content type, but I'm not sure what that looks like in reality.

1 - filter to see what's received performance/ux review & 2 know when it "Passed" review or "Needs review" or "Working on fixing review items"

Yes, Yes, Yes!

3 - many of stages will have 1-5 issues in them? for a short period.

YES, if everything is good you're exactly right ... many stages will have just a few issues for short periods of time. That would be the sign of everything working well!

I'm not sure I precisely understand what you're suggesting when you say "cut away", but I can imagine simplifying the number of links at the top, for sure, maybe into three categories: Features being developed, Work ready to for review and Work ready to move with sub-headers for each server, or something. Not sure that this is the best forum for me to try to describe it.

More discussion of the audience for the page would help figure out the best display. Because it's not just about PM, it's about anyone in the community (the DA, the board, business owners, etc.) being able to go to a single place and learn what's happening, at least in my opinion.

I'd love to discuss this with interested people on a hangout where we can draw circles and arrows and talk fluidly.

I read through the detailed Proposal presentation... I have some concerns. I'm going to separate them out into a few comments, so that each can be addressed (hopefully) separately.

My first concern is about how decisions will be made -- in the step on page 9 "The Process" between "Idea" and "Under Development", which is illustrated on Page 10 "First Stage: Idea".

So, let's say I have an idea. I add it to the Tool:

a) Who decides whether it is a good idea or not? The Proposal seems to say it is "Appropriate team leader" ... uh, what does that mean? who is that?

b) Is there a process for making sure that the appropriate WG is contacted/involved (we have WGs now for Documentation, Development Tools, Content, etc.) -- if the idea affects an area that is under their supposed governance?

c) Is there a process for getting community/stakeholder input (the people who will be affected by the tool)?

d) In the past, when I've worked on d.o improvements, one of the HUGE and very painful problems has been that after working on developing something for a long time, and going through many iterations, in the end the infrastructure or security team says no. How can this be addressed much much earlier in the process (involving infra/security earlier) so that community members do not get burned (and burned out) by this?

(see my previous 2 comments - this is about the Proposal linked above)

My third concern is about Working Groups. I'm a member of the Documentation Working Group, and we are soon going to need a way to make a Proposal that would probably encompass a bunch of inter-related "Ideas". I do not think that the tools/processes in the Proposal really address this need -- they seem to be aimed at individuals who have an idea about improving a specific thing on d.o,... and I doubt that we are really the only WG that might need to do this type of thing.

Basically, we are working on coming up with a conceptual plan for how Documentation could be better, both for Contributors and Users of documentation, and the improvements to Drupal.org that would be necessary to facilitate the improvements. And hopefully, since we're supposed to have a mandate to define what tools we need, there needs to be a way to make sure that the needs we have defined are addressed in some way (as much as is feasible, anyway).

But we're all busy people, and we probably don't have the time to push through the several different specific d.o improvement ideas that this might entail, nor are we necessarily developers (well, I am, but I really don't have time to add this to what I'm already doing as a volunteer in the Drupal project; and not everyone in the Docs WG is a developer, nor should we be). And maybe the ideas proposed by a WG should have a different weight than ideas that do not have a Governance group behind them? Or maybe not? I really don't know, but it doesn't feel like they should be treated exactly the same.

So... what can be done to address this type of a use case for the "drupal.org improvements" process?