PS: There is no clue about the right issue queue yet.

Problem/Motivation

#2457875: [policy] Evolving and documenting Drupal core's structure, responsibilities, and decision-making introduces a format structure of the Drupal core project.
In order to make it easy for new people though, just using tags will result in a bad time for new contributors.

Things which should be presented somehow:

  • What are the next steps needed to get this issue in
  • Who to ask for
  • ...

Proposed resolution

Remaining tasks

  • Discuss and design how it could look like
  • Implementation
  • Feedback from the community
  • Roll out

User interface changes

There should be some

Comments

xjm’s picture

jhodgdon’s picture

Project: Drupal.org site moderators » Drupal.org customizations
Version: » 7.x-3.x-dev
Component: Other » User interface
Parent issue: » #2457875: [policy] Evolving and documenting Drupal core's structure, responsibilities, and decision-making

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.

YesCT’s picture

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.

xjm’s picture

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.

joelpittet’s picture

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.

xjm’s picture

@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. :)

joelpittet’s picture

Thanks @xjm, lessoBSCure++

YesCT’s picture