Design / discuss how to help people understand the formal structure of Drupal core

Is #2458505: Need better issue search tools to support new Drupal Core governance structure a partial duplicate of this?

I think this is more about making a checklist for contributors, and the other one is about tools for maintainers for searching issues, so I think they're separate issues.

Adding parent on this one though, and moving to drupalorg module. And I second the need for this issue.

related #2013222: Add "Issue tasks" to project issues and correlate tasks with handbook documentation and other issues about putting context sensitive information on issues about what is next to do.

So there are actually several pieces of information related to signoffs that an issue could/should contain:

1. What signoffs might apply to any issue, and how this relates to our peer review process.

   • This is the full list in How are decisions made?.
   • Feedback for each signoff should be sought as soon as possible when it is clear that they are needed and when there is sufficient work to review, regardless of what signoffs are already present, so that contributors do not spend time on an incorrect direction for a change.
   • The signoffs themselves, however, should usually be on a final version of the change, since early versions might be incomplete and later versions might introduce changes that would not be signed off on.
   • The list is ordered logically from specific to general impact, but in reality the ordering is not fixed. A usability maintainer can sign off before a sybsystem maintainer, etc.
   • The minimum expectation would be that all non-committer signoffs should be present before an issue is marked RTBC (though as mentioned above, feedback should be sought earlier from committer and non-committer maintainers to avoid wasted effort and reduce burnout).

    

2. What signoffs apply to the particular issue. Taking #1847596: Remove Taxonomy term reference field in favor of Entity reference as an example, this issue needed:

   • Taxonomy component maintainer signoff, because it had significant impact on the Taxonomy component.
   • Arguably Entity Reference maintainer signoff, because while it did not have impact on ER on its own, Taxonomy is now the main implementation of ER in core, so in this case it's important to ensure that it was implemented correctly.
   • Usability maintainer signoff, because it had significant impact on usability.
   • Framework manager signoff, because it significantly changed architecture and public APIs, and (arguably, as above) impacted multiple components.
   • Product manager signoff, because it affected Drupal's product experience for a very common usecase.
   • Release manager signoff, because it introduced disruption and therefore could impact the release timeline.

   So in that issue, it would have been great if the issue could easily signal to users that someone had identified that those signoffs were relevant, but not (e.g.) Documentation maintainer signoff. (@jhodgdon helped improve the documentation, but the impact on documentation was not significant but rather merely covered by the docs gate). Currently, this would be implemented by adding the various "Needs" tags.
    

3. Which of the above signoffs have already been made, by whom and when and where, with a link to any feedback they provided with that signoff, as well as signoffs that are needed but missing.

Re #4, for signoff would or were you consider new tags? "Needs XXX signoff"

A way to help maintainers keep track and focus attention on issues needing their attention. And something that can be removed once complete to identify more ore less which comment signed off.

@joelpittet, the plan is already to use new tags. See the FAQ on the main issue. This issue as I understand the purpose is about using something less obscure than tags to surface the information. :)

Thanks @xjm, lessoBSCure++

tagging. being referenced in LA talk https://events.drupal.org/losangeles2015/sessions/drupalorg-changes-supp...