Voting starts in March for the Drupal Association Board election.
(Split off from. See that for the whole backstory.)
This issue is to discuss "Part A" of the following diagram:
Here are a few "case studies" on why something for Part A (ideation/prototyping/planning) is a good thing to have, and why it should probably not be the core queue:
This issue starts out simply enough. Some folks want to band together to create a new theme for core with a visually updated design and ideally based on components, so they can use it as a proof of concept for. So far, so good. However, it quickly became a discussion focused on implementation details, even down to what framework we would use and why using a framework or not using a framework was a stupid idea. :\
This initiative had been talked about by Dries on his blog since early this year. The implementation team tried to do the right thing and showcase designs early and often to the Drupal Usability Team, and respond quickly to feedback in refined designs. But because it wasn't clear if "sign-off" was achieved, or conversely that sign-off was needed, implementation here didn't start until far, far late in the game.
It seems like we could solve these and many other process issues by making a hard, enforced separation between "stuff we're thinking about" and "stuff we're working on."
There are many cool tools for doing ideation (such as https://ideascale.com/) and also prototyping (such as http://notableapp.com/) and we could use those or even build our own in Drupal. But that's either introducing friction (yet another login/lack of integrated notifications) or massive engineering effort into the process. (It may well be worth pursuing one of those options in the longer-term though; issue queues are scary places for non-developers to congregate.)
However, in the spirit of making an MVP for making MVPs ;) seems like for now we could use a separate issue queue on Drupal.org, something like "Drupal core ideas." This could have the following components (categories):
Each issue in this queue would go through its own Active > Needs review > Needs work > Reviewed & Tested > Fixed cycles, for each component (as appropriate), starting with Idea. And the goal of this queue is to create the signed-off-on plans that become the "finalize foo module" plan issue for each of the initiatives mentioned above, which then gets transferred to the Drupal core queue.
An idea consists of the first three sections (Background/Problem/Proposed Resolution) of the initiative proposal template. (Obviously, if more details are known, those could be filled out as well, but the idea will be evaluated based on these.) The goal is for an Idea to be fairly quick and easy to both write up and understand. The Idea bounces from Needs review to Needs work until eventually folks feel that the idea has merit enough to raise it to a Product Manager for sign-off, and mark it RTBC.
For user-facing issues, during the weekly UX meetings, product managers would review RTBC Idea issues with the Drupal UX team, pulling in others or escalating to the BDFL as necessary.
For developer-facing issues, @tbd on how those are reviewed in a timely fashion.
Once an idea was approved, the issue moves to the "Plan" component.. The "Plan" issue goes through the same Active > Needs review > Needs work > Reviewed & Tested > Fixed cycles, this time pulling on Subsystem maintainer review, Topic maintainer review, $foo Manager review, etc. as needed.
In the event a protoyping phase is needed (e.g. for Outside-in, or for a new API such as Theme Component Library (pseudocode)), we could mark the Plan issue postponed on a "Prototype" issue, and the designer could use whatever tools they want to do protoyping, posting a comment with the place for people to test whenever there was something to look at.
Finally, when the Plan issue gets marked "Fixed" in the "Ideas" queue (meaning all of its sign-offs are done), it moves to the Drupal core queue, so we capture the "Why" as well as the "What/how". The issue would move to "Fixed" as these features became stable parts of Drupal core.
(I don't like how "waterfally" this is, mind you. I think some of these things could happen in parallel; for example, the Workflow Initiative was working on existing known revision system problems while waiting for their plan to be approved; prototyping can be happening while the idea is still being pitched, etc.).
Creating this clear separation of "Ideas" vs. "Implementation" results in the following benefits:
1) Because there's nothing to write a patch against, it at least attempts to enforce "we're not talking code here yet."
2) Because of that, ideally, it's easier for people such as end-users, project managers, designers, content authors, and other folks who are traditionally not represented well in the core queue to participate.
3) It creates one central place for all the things that are being thought about, vs. having to know the magic string to search for in the Drupal core queue amongst 30,000 issues.
4) It is very clear when conceptual things are blocked on review/feedback, or things that still need work to achieve sign-off status.