Editing here: https://docs.google.com/document/d/1r0Y3uxjIyIF9RKsktRfKhJQFuDbpbATvCYP7...
Background
High-level information that a contributor should know to understand the proposed initiative.
Problem
What's the motivation behind this proposal?
Proposed resolution
At a high level, how do you plan to solve this?
Process and where to find it
Does the initiative have a team site/group/etc.? Where will the work be done? Can it be added to core as a new experimental module
https://www.drupal.org/core/experimental →
, or does it need to make changes across existing subsystems and therefore need a feature branch? Is there a sandbox/existing contrib module/other repo?
Proposal roadmap
A rough roadmap of the specific work planned. (Note that your roadmap will likely evolve as you work on the initiative, so don't try to make this section perfect! The goal is to get you and other stakeholders to think about this from the start, and to communicate as you evolve it.)
Keep in mind the release cycle timeline
https://www.drupal.org/core/release-cycle-overview →
and allowed changes in different phases of the release cycle
https://www.drupal.org/core/d8-allowed-changes →
. Ideally, your work should be added in a backwards-compatible way for an upcoming minor version (not necessarily the next one), and avoid disrupting existing sites, modules, themes, etc. For example, a new UI or feature might first be provided as an optional experimental module, then made the default for new installations once it is complete. Or, an API might first be added as @internal, then made public when stable, then the old API deprecated. The backwards compatibility policy
https://www.drupal.org/core/d8-bc-policy →
defines in detail what disruptive changes can (and can't) be made in minor releases.
Take into consideration which parts of your proposal will require changes to the user interface or interactions, and make sure you plan ahead for iterating on designs and prototypes. See https://groups.drupal.org/node/510551 for more information about how we are improving the user experience process for core.
Try to identify wholly functional phases or milestones http://blog.crisp.se/wp-content/uploads/2016/01/mvp.png and take into account the issue scope guidelines
https://www.drupal.org/core/scope →
when considering individual steps to reach those milestones.
Not in scope
What you will NOT do.
Related work
Existing things that are related to your goals and how (or how they are different if not related).
Existing core features
Stuff core already does related to your goals.
Open core issues
Bugs and other feature requests in the core queue that will block or be affected by your work.
Contributed projects
Contributed projects that provide similar functionality. (If your goal is to provide some of a contributed project's functionality in core then you should probably talk to the contrib maintainer first and see what they think, although the BDFL might make a determination in the end.)
Team and resources
Who is already on the team, and what resources you have or need. Consider if there is a proposed initiative coordinator. (Initiative coordinators act as project and community managers with a strategic agenda, and help guide a team of people interested in helping the initiative to succeed. Initiative coordinators don't have direct decision making powers; rather, they work to build buy-in among those who do have decision-making powers: product managers, subsystem maintainers, topic coordinators, etc.)
If your initiative will affect the user interface or user interactions, make sure to take into account the need for design and usability iteration. See the proposal for revising the user experience process https://groups.drupal.org/node/510551 for background information.
Signoffs
Get the buy-in of stakeholders before you start work. The issue is RTBC when the stakeholders agree on the plan and it has the needed signoffs. See the core governance overview http://cgit.drupalcode.org/governance/plain/drupal-core.html for the signoffs you need. In general, you will probably need signoffs from release managers; product managers or framework managers or both (depending on the work); and possibly subsystem or topic maintainers (depending on the work). Work that impacts the nature of Drupal itself (its governance, philosophy, goals, etc.) also needs signoff from the BDFL.
Signoffs needed
A list of maintainer names who need to give signoff.
Signoffs given
A list of links to issues/comments in which each signoff was given.
