[policy] Evolving and documenting Drupal core's structure, responsibilities, and decision-making

For those who'd prefer to comment on the Google Doc version it can be found here: https://docs.google.com/document/d/1xDYdseCae9RWGScFmrKkf_d6TkwLR_GoyAui...

Thank you for posting that post without the word leader in it. Highly appreciated!

Documenting which process we have, absolutely makes sense, as it makes it easier for new contributors to understand what is going on.
I really like the structure of IO.js, because it has a much lower bus factor.

If a change doesn't significantly impact any given area of Drupal, it simply needs a peer's sign-off.

So, basically this is about formalizing what already happens many times.

If the change significantly impacts any area covered by a topic maintainer, that topic maintainer needs to approve or refuse it.

Can we make the text more clear and describe that it should be based upon a reason?

a timely manner,

Odd, that fragment link doesn't work. Based upon that, we should be clear, that single maintainership is problematic, as it causes way easier burnouts, due to being
the only person, having to deal with conflicting interests, for a particular subset of issues.

Once a change has the required sign-offs, any core committer may commit it.

I'm curious, will this be supported by Drupal.org in some way, so will it be for example possible to have a look at the most recent signed off issues, and for each individual, will there be clear
markers that something is signed off / has to be signed off? I'm thinking about new people coming into the community,
if we adapt this framework, we want to make people it as clear as possible, and fast, what basic principles we care about. I think we don't want to introduce an informal formal structure.

Note: This issue has 8.0.x as version, so it will apply in 2 weeks? The issue just talks about documenting it, which work

Alright, two more core committers

Note that if a change includes multiple rows in this table, there will be multiple roles involved.

There should be tools not requiring everyone to remember that. If issues are aware of their significance, some information about the next step, could be presented to the contributor.

Just fixing the "timely" link per @dawehner's comment.

Based upon that, we should be clear, that single maintainership is problematic, as it causes way easier burnouts, due to being
the only person, having to deal with conflicting interests, for a particular subset of issues.

Very true! How exactly to get more than single maintainers in a given area (or any at all in many areas) is of course the 90% of the work we have to do once the 10% work of improving the process is done.

I'm curious, will this be supported by Drupal.org in some way, so will it be for example possible to have a look at the most recent signed off issues, and for each individual, will there be clear
markers that something is signed off / has to be signed off? I'm thinking about new people coming into the community,
if we adapt this framework, we want to make people it as clear as possible, and fast, what basic principles we care about. I think we don't want to introduce an informal formal structure.

I think this is great feedback, and I also think it'd be really, really good if our issue queue surfaced this decision-making to contributors. Committers and other reviewers have suggested a desire for "checklist" functionality for issues in the past. However, making improvements to the issue queue of course takes work, and plus there's the fact that since this is specifically for core, we have to be careful for how we impact contrib with any changes we make to the issue queue. So I think it's just the issue tags for now. But +1 for making it more explicit on d.o somehow.

Can we make the text more clear and describe that it should be based upon a reason?

Should we link the objective criteria FAQ in that section somewhere? Does that address it? There is also the how to sign off section which implies (but does not explicitly state) that the maintainer should document the reasons for the signoff (or lack thereof) on the issue.

There should be tools not requiring everyone to remember that. If issues are aware of their significance, some information about the next step, could be presented to the contributor.

Also a good point. I think that what mitigates this for now is that most of the responsibility for making sure the steps were taken falls to the committers -- i.e. if something was missed, it's their job to catch it and let others know on the issue. (Same as now really.) But a better way is definitely possible with improvements to our tools.

Thanks for putting this all together!

I know that a birds eye view is essential to understand the whole piece, though my first thought was if it was more intuitive to use turn the order around. If the guide could start with what a single contributor may do on their own and when upper authorities come into play might be a good second way to look at this? Just thinking out loud, not that I have the picture fully in my mind...

Very true! How exactly to get more than single maintainers in a given area (or any at all in many areas) is of course the 90% of the work we have to do once the 10% work of improving the process is done.

So i'm curious whether we could expand the text to something like:

Subsystem Maintainers: Maintainers of one particular part of Drupal core, such as the Entity system or Comment module. In order to avoid burnout and conflict
there should be at least two people taking care of it, at the same time.

But +1 for making it more explicit on d.o somehow.

Let's create an issue to discuss that, because I think its an important part of the onboarding process: #2458333: Design / discuss how to help people understand the formal structure of Drupal core but not directly impacting this.

Should we link the objective criteria FAQ in that section somewhere?

Well, for me its missing the part where people turn on their brain and find rational arguments beside written down rules.

If the guide could start with what a single contributor may do on their own and when upper authorities come into play might be a good second way to look at this?

That would be a useful way to present this. Also ties in with how the issue queue is day-to-day (i.e. more of a funnel/sieve).

Just to amplify what I think has at least partially been said above:

Those of us who are performing Maintainer roles (component, subsystem, etc.) need to have better tools on drupal.org Should we start another issue to discuss the tools we need?

I think we also need to think about who maintains what components in what versions of Drupal.

Specifically... Currently, I rely on a *large* set of bookmarked drupal.org issue searches to manage my responsibilities, and it's very clumsy. This proposal would greatly increase the number of bookmarked searches I'd need to look at, and I'd need to look at them at least once a week in order to comply with the requirements in this document, I think.

Here are the searches I would need to be doing:

a) Issue triage (subsystem/topic maintainer): I would need to see a list of all issues in all components I maintain or co-maintain, for the versions in which I've agreed to be the maintainer. Ideally this would be one link that would contain (currently) all issues in Search module for Drupal 8, Documentation subsystem for all versions, and Transliteration component for Drupal 8. Currently this is 3 separate bookmarked searches. I'd like to see it as one page. And this doesn't count the other components that I'm unofficially kind of watching, like the Help module, the Tour module, etc.

b) Sign-off (subsystem/topic maintainer): I would want to see a separate list of all the issues I need to sign off on. These would be:
- Issues tagged "Needs documentation review", independent of component and version
- Issues tagged "Needs subsystem maintainer review" in either the Search component or Transliteration component for Drupal 8.
Again, this would currently be 3 separate bookmarked searches. I'd like to see it as one page that I would look at daily in order to provide timely feedback on these rather time-sensitive sign-offs.

Ideally, I think that the best way to provide this might be to make a UI where any Drupal user could set up an issue search with and/or logic, and let each of us create multiple search pages. I really don't want the Triage stuff mixed in with the sign-off stuff -- I might not look at the Triage page as often or treat it with the same urgency. But at the same time I don't really want to double the amount of bookmarks I need to look at in order to be a good Maintainer. The tools we have now are crude and not supporting these roles very well.

A spin-off for Drupal.org tools improvements to support this proposal sounds like a fantastic idea.

Another problem: vacation. As a sub-system and topic maintainer, and without a co-maintainer at least for Documentation, I do not think I can commit to the responsibility of always providing feedback on "needs $whatever review" issues within one week. I am not always available, and even for the components where there are co-maintainers, I do not want to have to coordinate vacations with my co-maintainer(s). What can we do about this?

OK spinning off: #2458505: Need better issue search tools to support new Drupal Core governance structure and I'm going to now fill it in...

Vacations are attempted to be addressed by point #5 in the decision-making process:

"If a subsystem/topic maintainer sign-off is not given in a timely manner, or if sign-off is not possible because the patch was authored by those who need to provide sign-off, it gets escalated to the core committers."

Basically, same as now.

OK I filled in #2458505: Need better issue search tools to support new Drupal Core governance structure to address the issue search tools. Someone else can write up the "checklist" idea. ;)

Regarding vacations and #13/#15... Maybe we need to put something about this in the Responsibilities section or in the FAQ about "timely manner". It currently says in the Subystem Maintainer section that maintainers need to provide "prompt feedback", and to me, the wording about "if it's not provided in a timely manner" in the "how it works" section sounds like this case is a fallback in case of a failure of some sort instead of a normal occurrence.

We're all volunteers here, and there is no way we can realistically commit to being available at all times to provide feedback promptly... But the way things are worded, it sounds like we're shirking our defined responsibilities or failing in some way if we don't, rather than it being OK.

Anyway. Just a small thing in an otherwise great proposal!

I can't really put my finger on it, but the matrix at the struck me as somewhat depressing – almost all of the "performs' tasks fall on the 'core contributor' which isn't even defined in this document. I'm concerned that with people feeling burnout and core development slowing to the point that the DA is funding core development, this mentality is going to make core contributors feel even more pressured.

I'm further concerned about how that will be viewed in light of the new core committers and maintainers listed. 4 of the 6 core committers are now Acquia employees and our BDFL is the founder of the company. I'm not trying to question their leadership, decisions, or contributions, rather I'm concerned about the way that this could be perceived by the community. In the past there have been concerns about Acquia's influence over Drupal, and the affect that had on the community was discouraging to contributors, and this feels like it could perpetuate more of the same concerns.

If I were a total cynic, I would read this policy and conclude, "Well Acquia is taking greater control of core, and they expect 'core contributors' to keep doing all the work for them." I'm not that cynical, because I know a lot of great people in the Drupal community and I know the core committers well, and I trust them. However that experience comes from knowing those core committers on a personal level, not any kind of policy or control structure.

I guess my question is this: What steps are being taken to ensure that a policy like this doesn't cause trust issues or perpetuate contributor burnout?

(EDIT: In reply to #17)

It's tricky though, because the people supplying patches are also largely volunteers. And when I asked a few months back on Twitter what burns people out from core development, patches sitting there with no one to care about them was #1 or #2 in the list. (The other one of #1 or #2 was lack of a clear decision-making process so check and check! ;))

The intent of this is to give subsystem maintainers a) a heads-up that something's going in that might need their attention, and b) a reasonable timeframe in which to say "wait! what about this?" But the intent is not hold up the entire committing process on their approval. Does that make sense?

So vacations are fine. How I would handle that as a product manager is if there were things saying "Needs product manager feedback" in my queue, I'd respond and let them know I'll be gone for the next N days and either a) I'd really prefer if this could wait until I get back or b) feel free to move along without me.

#18 is a great question and brings up a lot of good points. I want to thinker on it more.

The reason for the committer change-up as part of this document is Alex and Jess already effectively play this "provisional" committer role and have for months, but this is not currently transparent at all. We also have one core committer about to go AFK for 4+ weeks.

What I see happening after this policy is approved is Dries appointing additional people to the various "provisional" committer roles with the aim to make them full-fledged committers in a couple of months, after we kind of see how this process shakes out in practice. But you're right that in the meantime, this certainly has the risk of creating trust issues, particularly among those who don't have personal relations with the Acquians in this list to know that they're extremely high-integrity individuals.

Let me make it clear that I am excited and received to see Jess and Alex recognized for the work they already do, and I honestly can't think of any individuals in the community who would be a better fit for the role. I am grateful and I hope the rest of the community is for all the hard work they do, especially with getting hard issues unstuck.

I'm really much less worried about the issues with corporate influence of the project, and more worried about contributor burnout and how this policy (or even it's apparent interpretation) could affect that.

Thanks @mikey_p.

core development slowing to the point that the DA is funding core development

I just need to point out that this statement is fallacious. The momentum on core issues is higher than it has ever been in the past five years, whether or not issues sponsored by D8 Accelerate are counted (they are a small, but valuable percentage of the total work). D8 Accelerate is not a compensation for a lack of momentum; it is a way to provide focus and, well, acceleration specifically on tough release blockers. In D7, there were other ways that people were paid for work on nasty issues. The D8 Accelerate way is just (IMO) better. :)

Also pointing out that @dawehner filed #2458333: Design / discuss how to help people understand the formal structure of Drupal core to discuss how to structure a checklist or something, so that contributors can understand the sign-off process. (Possibly so *maintainers* can follow this process too.) So we have two issues now about drupal.org improvements that would be useful to support these changes.

…finalize as a document in https://www.drupal.org/project/governance.

I think it is OK to maintain this information as a project but it should be placed in the Documentation section of drupal.org IMHO.

If I looked for information like this I would look for it in the Documentation section and would never thinking about it as a project.

@thamas, that is good feedback. Where in the Documentation section would you expect the page to be? We can at least make a link there.

@jhodgdon, how about a Dashboard block for this and similar topics, too? Or maybe just add it to the top of Contributor Links? The later may be better, as the people who would refer to it probably already have this block on their dashboard.

@mpdonaido: Maybe. I don't use the dashboard myself, so I am not sure whether that would be useful or not.

I assumed that any Views for maintainer search would also be available as dashboard blocks.

Edit: I commented to this effect on #2458505-11: Need better issue search tools to support new Drupal Core governance structure which is probably the place to discuss it.

@jhodgdon I've just realized that there is a Governance page in the "About" section of the Docs: https://www.drupal.org/governance So it should go there, I think.

@mpdonadio If you are talkin' about displaying this information to the users, I think it is useful, but not enough. We should think about not registered / logged in users too. If you are talkin' about something else than sorry. :)

+1 to anything that gets this out of tags into fields or something readily available on an issue. I've already had to come back here several times, because for the life of me I can't remember "framework manager".

I've closed #2050451: Formalize the role of core component maintainers as a duplicate of this issue.

Also linked some existing issues:

• #1854480: Remove inactive maintainers from MAINTAINERS.txt
• #2050477: [META] Identify component maintainers for components with no maintainer listed in MAINTAINERS.txt

We should also retag all the issues tagged with Component maintainers to "Project governance" instead (aside from the d.o issues which can probably just be untagged and referenced as related issues). That can happen right now, even before this policy is finalized, if anyone is bored on their lunch break. :)

Huge thanks to everyone who's been involved with this so far! Formalizing this structure in a clear fashion is the first step toward improving our overall Contributor eXperience. (It's the cool thing to make everything an eXperience now, isn't it?)

Some additional comments:

- As others have noted above, additional Drupal.org tooling will be enormously helpful in ensuring the various *Maintainers are able to do their jobs, and ensuring everyone else understand who is responsible for and has authority regarding what. As there's already another thread for that I won't add more here other than +1.

- Traditionally, the non-Dries non-subsystem maintainer(s) have changed with each release. The document is mum on whether that is intended to still be the case going forward. Is it? Should we clarify which roles are expected to be per-major and which are indefinite and which are "whatever" (eg, subsystems)?

- The doc implies that the Product Manager, Framework Manager, and Release Manager are always core committers. While that makes sense for the Framework and Release Managers, I'm not sure about the Product Managers. Our current PMs are both code-savvy and Git savvy (even if it took Dries a while on the latter. ;-) ), but I can certainly envision a situation where we have someone who is an excellent product-level visionary with good user-understanding, sense of the market, and organizational skills but who is totally lost on PHP code. Those skills are sufficiently distinct that while they currently overlap we should not presume they do, and leave the door open for non-developer Product Managers. (Part of not making non-devs second class citizens inadvertently.)

- "Provisional" as a name sounds weird. From the description it's really an apprentice position. Would that be a better term?

- I suspect this formalization will succeed or fail based on the success of working out the nuance between the Committer-level maintainers and the subsytem maintainers. The document leaves much of the nuance there unsaid, which is reasonable given that there's so much context-specific information that goes into whose job it is in edge cases to make a call on something. I don't have a specific recommended change here, just calling out that this will be an important relationship and evolving the cultural expectations around it (which right now are fairly thin and poor) will be critical.

- How aggressive can subsystem maintainers be on triage? I don't mean just in cases of status tug-of-war, but for instance I would wager that at least a third, maybe half, of the open issues on core right now are either no longer relevant (old versions, code has changed too far since it was last touched, feature no longer even exists, etc.) or are only open as a courtesy because someone felt that "won't fix" as a way to reject a feature "for now" was too mean/aggressive. (And therefore the issue has been in needs work or postponed for 5 years and now in category 1). I'm sorely tempted to go through at some point and just mass-close a whole crapload of issues that are not relevant now nor have been for a while (eg, anything still tagged Drupal 5), but the last time I tried a few years ago Angie took a ruler to my hands. :-P Is closing out, say, feature requests with a "no, not on the roadmap" something within a subsystem maintainer's purview?

- Initiative Coordinator is a more descriptive name than Owner or Lead for what the job description reads as, so that's an improvement. However, at every DrupalCon of the last 3 years it's been fairly well agreed that Initiatives need to not be single-person but have a formal and named team behind them with various roles. Should that be incorporated here to be forward-looking? (Or, will we even need initiatives post 8.0.0 since hopefully we won't have 10 massive rewrites going on at the same time ever again?)

Thanks a lot for all the excellent feedback so far. Going to attempt to synthesize it in advance of a meeting I have tomorrow with Dries, but please feel free to mention if I've left anything out.

• No objections to documenting the process in general, so it's clearer to people (especially newcomers) how things work. Hooray! That's a good start. :)
• dawehner made a suggestion to explicitly state that we should aim to have multiple at least two people in any given maintainership role, in order to prevent burnout and to ensure there are ample people available for unblocking a given decision.

  I think everyone would agree that this is desired, but this is also only really possible if we massively scale back the current granularity of subsystems, and let larger subsystem maintainers self-organize around "sub-sub systems" (for example, how the database maintainers are structured). Once this proposal is adopted, we'll have a guiding framework, that will enable a second chunk of follow-up work around updating MAINTAINERS.txt to make it both accurate and more manageable. (see #1854480: Remove inactive maintainers from MAINTAINERS.txt, #2050477: [META] Identify component maintainers for components with no maintainer listed in MAINTAINERS.txt for starters).

• dawehner also voiced a concern that a certain subset of people might use this document to bludgeon people over the head with "I'm the boss of this"-style comments, rather than giving rational, objective reasons for why they're pushing back on a patch. His suggestion was to add some additional spelling of this out around any language about rejecting patches.

  I'm a little torn on that personally... I can see the logic, but it feels a lot like "babysitting," and if that kind of thing is happening a lot it's unlikely more words will stop it. Instead, it should really get escalated "up the chain" instead, as defined in the document (subsystem/topic maintainer/initiative coordinator -> core committer -> BDFL -> CWG), so I'd prefer to emphasize "what to do in case you disagree with a decision," personally.

• There are concerns by dawehner/jhodgdon/Crell/others about putting this into practice without better Drupal.org tooling support, since there are more tags for maintainers to keep track of (#11 lays this concern out pretty well), and also because the path to get an issue to RTBC and commit is more complex without providing a "checklist" of sign-offs. These are both "pre-existing conditions," but they are exacerbated by the additional explicitness this proposal provides. #2458333: Design / discuss how to help people understand the formal structure of Drupal core and #2458505: Need better issue search tools to support new Drupal Core governance structure have been spun out to discuss these more. From the Drupal.org SWG meeting today, it sounds like it's unlikely these issues would get on the DA tech team's plate until later in the year, but they could potentially be handled through community-driven improvements sooner.
• jhodgdon also suggested some wording under the "timely manner" part of how to deal with vacations, since those should be welcome and encouraged. There was a suggestion made on #19 on possible wording to handle this.
• While the document originally began as guide for Maintainers, it evolved since then to covering the gamut of how core operates. As a result, dasjo pointed out that we could be doing more to emphasize the power of the individual contributor (which is actually quite substantial), perhaps by adding a section about them first-thing, before getting into the list of maintainers. mikey_p also cited this disempowerment as a concern. +1 from me.
• mikey_p also raised some questions in #18 about how to deal with outside perception to the particular core committers who are suggested here and the company they work for. I'll try and talk with Dries about this tomorrow.
• Crell raised a number of questions in #33, including:
  • Right now product managers are committers, but doesn't this leave out someone who is a product-level visionary with good user-understanding, sense of the market, and organizational skills but who is totally lost on PHP code?
  • - "Provisional" as a name sounds weird. From the description it's really an apprentice position. Would that be a better term?

    My response to that btw, is Docker called these roles "in-training" and we didn't want to call them that because of the lack of experience implied, when everyone who'd be in one of these roles would've most likely been a core developers for 3+ years. "Apprentice" has the same "lack of experience" connotation, so not sure it's better.

  • How aggressive can subsystem maintainers be on triage? Can they mass-close issues that are 5+ years old with "won't fix"? Is closing out, say, feature requests with a "no, not on the roadmap" something within a subsystem maintainer's purview?

    My response: I'd need to see the issue I ruler-slapped to understand the context... in general I don't think I have a problem closing out old issues, but if it's still a legit bug report (for example) that doesn't really make sense, as it risks losing a bunch of work that went into finding the solution. So IMO it's kind of case-by-case.

  • Crell asks a similar question as dawhener about initiative coordinators and making it explicit that we should always strive to have multiple.

    AFAIK Dries agrees future initiatives should have teams behind them so it's just a matter of whether we want to make that desire explicit in this section.

thamas, is there anything on https://www.drupal.org/project/governance (the canonical Git copies that are version-controlled) that's not on https://www.drupal.org/governance (the documentation section)? Or are you just suggesting we drastically shorten the project description to mainly a pointer to the docs, so there's not two places for the same info?

Ok talked with Dries today about the feedback so far. He's heading on vacation tomorrow, so paraphrasing on his behalf:

• +100 to adding a section on core contributors, and emphasizing their importance.
• Tools improvements are important, but shouldn't be a hard dependency.
• For subsystem maintainers, it's fine to add a general goal to have multiple people holding each role given the benefits, but it should not be a hard requirement.
• +1 for encouraging people to take time off, whether for vacations or simply because they need a break. This can just be an informal process.
• Terms are deliberately kept unspecified because it allows re-balancing the team if necessary during 8.1.x or 9.x.
• For product managers, it would be fine to appoint someone who focused predominantly on product management and didn't necessarily focus on committing, if that's the skillset of the best person for the job. Core committers can work out the distribution of committing amongst themselves.
• +1 to "Apprentice," since that's a more accurate term. Someone can be an expert in general, but they're still learning the ropes on being a core committer (for example).
• +1 to subsystem maintainers being empowered to tightly triage their queues, as long as they're providing sound rationale, and not stepping on any of the other maintainers. We might develop guidelines in the future if things go off the rails or if we really feel we need consistency across subsystems.
• Initiatives should have a team, but there are different roles in a team, and generally only one coordinator. However, can add a sentence emphasizing the team aspect to initiatives.
• Trust issues mikey_p brings up do need consideration, but generally appointing more core committers seems like it's of greater community benefit than not, regardless of who they work for.

I think that was everything.

I'll make another edit to the issue summary hopefully tomorrow that attempts to incorporate the feedback so far while still allowing more time for comments.

@webchik I think it would be good to make more clear the goal of the project page and shortening that could be a good idea.

Also the project page says "Other governance policy documentation can be found at About Drupal: Governance." While I'm not a native English speaker I did not understand first that "other" here does not mean a different / additional documentation but it means an another "copy" of the actual information on project page.
(FYI I did not looked for differences and has no information about how the project page and the documentation page are kept in sync. But if it is done manually, that includes the possibility of mistakes.)

FWIW -1 on "apprentice"; I find it has the same demeaning connotations that "in training " did. Only one person has proposed that label, whereas several people already agreed on "provisional" over "in training".

I agree with xjm.

Well, provisional in some ways has worse connotations: temporary, interim, etc. Implies people can be replaced at any point, more so than "on their way up." However, per #37 we can always change it later. :)

Re: "apprentice" vs "provisional" -- how about "assistant" or "deputy" maintainer?

Isn't provisional used for secteam members who aren't full members yet?

Implies people can be replaced at any point

I've always assumed that this was the case. Maintainership with commit access is at the BDFLs discretion and so (i guess) is the removal of a maintainer with commit access

@mpdonadio yep provisional is used by the secteam.

Not to go too far off on a tangent, but I see nothing "demeaning" in "apprentice". If anything, OSS and programming in general needs a stronger apprenticeship/mentoring mindset. It's a learning and training role, which is exactly what I understand we're describing here.

Developers in general could stand to use a bit more humility. (And I do not exclude myself from that statement at all.)

+1 #45. Given that we already have core mentors, "Apprentice" does seem the more logical word. However, given the context of which all of this is related to, "Tentative" seems the more appropriate word. "Provisional" implies they're standing in for someone and will eventually relinquish said role, not ultimately (and more than likely) advance to full status membership.

Well, as a non native speaker I neither was aware of the meaning of "Apprentice" nor "provisional", but at least for the second word you can guess the meaning.
We want to be inclusive, so let's try to use simple words.

Some other ideas: representative maintainer, supportive maintainer. Some other idea you could think about is going back to the notion of teams, also for subsystems.
Another idea: "Call it subsystem team membership", which makes it IMHO quite clear that we don't talk about a hierarchy but rather a set of individuals working together.
All that leadership thinking is horrible in so many ways, kill it with fire!

Call it subsystem team membership

I like the concept of teams, +1 to this.

during the mentoring meta meeting, we realized that there was a part of maintainers.txt that we did not notice before #2465617: [policy, no patch] Documenting Drupal Core Mentoring lead responsibilities

Ok, made (I think) all of the non-controversial changes outlined in #34/#36.

"What is a core contributor?" is a longer thing so to avoid death by issue summary updates, added that here https://docs.google.com/document/d/1Vd_Ss1pKUGx2JQB30lcBxOpRSTxvxCIDQq0w... for us to bang on for a few days. I've turned on commenting access for everyone.

I kept Provisional alone. It sounds like it's something we could always discuss in a sub-issue if enough people feel strongly about it, given the "living document" aspect of this pointed out in #37.

I do not think "subsystem team membership" works, however, so I did not add that change. For one, because Dries stated that although a team behind a subsystem is great for all the various reasons, it is not a requirement. And for two, check out all of the ?s in MAINTAINERS.txt sometime. :) We're not currently set up at all for subsystem teams giving our overly granular subsystem definitions atm. Once we've fixed that problem, maybe we can revisit this idea in a later revision.

I also have to confess I'm a bit mystified on the nervousness/concern around the word/concept of "leader." Because let's face it: we do have lots of leaders in our community (or "people with more karma than others" or "people who've been around longer than others" or however you choose to phrase it). This is a by-product of the "do-ocracy" way in which the Drupal community is empowered to make changes. Not making those people who the community looks to for guidance explicit turns into the tyranny of structurelessness where only those deeply involved have any idea how the whole core development thing actually works and how to get their patches through. That's one of the things this document is explicitly trying to help fix.

Now cleaning up some stupid HTML things that I noticed when I was doing that. :P

Sigh. I really wish Google had a "do not ever copy my organization URL to a public doc" option. :P~

webchick: As I understand it, dawehner's concern with "leader" is not about "people in positions of explicit authority and responsibility" but a bit of cultural linguistic baggage. (Remember what country he's from; I didn't get it either until he pointed that out to me.)

Also, the pop business press is filled with "how to be a leader" articles, all of which are utter BS when you get right down to it so the word has sadly gotten rather diluted. :-)

I would recommend removing obviously from
Obviously, maintainers can and should take time off, whether for vacations or just because they feel the need to.
and make it just
Maintainers can and should take time off, whether for vacations or just because they feel the need to.

Agreed.

Ok, didn't see any critique of the definition of a core contributor in the past couple of days, so formally incorporating that into the issue summary.

Also tentatively marking RTBC, as most of the recent discussion has been around specific wording improvements, rather than about the overall concept, and as Dries noted in #37, the specific words can (and will) be improved over time.

Thanks, all!

#3 sounds good to me too. The names *will* be different per-version most likely.

+1 to #3

Ok, let me do a bunch of annoying formatting again. :)

Ok, membership/provisional membership removed from the HTML. Here's a patch to MAINTAINERS.txt that:

- *Adds* new names (leaves the old ones there to sort out later)
- Switches the role labels to be consistent with the doc.
- Moves node access and translations to a subsystem, rather than topic, since the list of topics was explicitly intended to match the gates. We'll clean this up in a follow-up to fix subsystems.

Back to Dries. :)

+++ b/core/MAINTAINERS.txt
@@ -171,15 +197,17 @@ Theme system
+Topic maintainers ¶

Space at the end of the line.

Dang it. I thought I got all of those. Thanks.

BLAH.

DOUBLE BLAH.

1. +++ b/core/MAINTAINERS.txt
   @@ -3,25 +3,46 @@ encouraged to submit issues and changes (patches) to improve Drupal, and to
    - Dries Buytaert 'dries' http://drupal.org/user/1
   

   Does Dries get a (Something something) added below his name?

2. +++ b/core/MAINTAINERS.txt
   -- Nathaniel Catchpole 'catch' http://drupal.org/user/35733
   +information on their responsibilities, and to find out how to become a subsystemmaintainer. Current subsystem maintainers for Drupal 8:
   

   subsystemmaintainer is where this should be split across two lines

@tim.plunkett... (BDFL)?

This is really awesome!

Suggested addition for the FAQ section:

Do I need to be named Alex to be a Framework Manager?
You don't have to, but statistically it helps.

@eff++ :)

LOL :)

Here's an update for #69/70, thanks!

Applied it to look at it in context and looks good.

Right now, provisional membership line is at the end of a group, we can see later how best to list provision people once we start actually documenting them.

In the issue summary, added html link # next to "What is a core contributor?" for symmetry with other sections.

I looked it over and could not find anything wrong with it, I even applied it and looked at it context, and it also still applies.

Something strikes me as conspicuously lacking : the governance of everything security related. Indeed, the security team might well be the most formalized structure we've been having for long, but that does not seem to be a reason not to include its governance here : there are references to it at various places in the document, but nothing about the team itself.

Should it not be included in that overarching document in some way ?

It could, though the Security Working Group has its own charter, and it is not specific to core. See http://cgit.drupalcode.org/governance/plain/charters/security-working-gr... and https://www.drupal.org/governance/security-working-group

These charters do indeed exist, and existed before this document was elaborated. But it still seems not-so-logical not to describe the SecWG and Security Team governance in this document, since it is (AIUI) a general framework to provide a reference for governance on Drupal core. Even though, as you mention, the SecWG (and Security Team) also have responsabilities outside core: at least referencing them, providing pointers to their own specific procedures, and their place in the grand scheme of things, even as "somewhat separate" entities, would make the document more consistent.

Some of the issue tags used to alert maintainers that a signoff is needed are already in use, so I updated the Special issue tags documentation.

Note that the following special issue tags don't exist yet and will need to be created (and the special issue tags documentation will need to be updated to link to them):

• Needs documentation review
• Needs performance review
• Needs release manager review
• Needs testing review

I would say go ahead and document them (and thanks for doing that!). They'll automatically get created the first time there's a reason to use one of them.

Also spun off #2492533: Figure out how to reference the security team in the core governance docs for #76/78 so we can discuss the best way of doing that without expanding this issue by another 20+ comments. Dries will have time on Friday once again to look at this and I'd love to get the policy itself formally documented so it's public before we start tweaking things.

I would say go ahead and document them (and thanks for doing that!). They'll automatically get created the first time there's a reason to use one of them.

They've already been documented! :D

What I meant to say is that, once the terms have been created for the first time, the documentation page will need to be updated to link to the terms (they currently have <a id=""> wrappers, but we'll have to add the href attributes).

Hmmm I may be wrong, but should the issue title be changed from:

[policy, no patch] Evolving and documenting Drupal core's structure, responsibilities, and decision-making

to:

[policy] Evolving and documenting Drupal core's structure, responsibilities, and decision-making.

As we actually have an RTBC patch attached??

+++ b/core/MAINTAINERS.txt
@@ -3,25 +3,47 @@ encouraged to submit issues and changes (patches) to improve Drupal, and to
+core committers for Drupal are (per major version, in alphabetical order):

D8 list is not in alphabetical order

@mbrett5062 I thought it was in alphabetical order by surname?

Offtopic, but worth to know for inclusivity: http://www.w3.org/International/questions/qa-personal-names#sorting

@alexpott of course you are correct, my bad. Have reviewed further and is indeed RTBC.

Sorry for the noise.

You know... There's one thing missing from this document that I think is kind of important... could be a follow-up issue too. Maybe it belongs in the Skills topic in the FAQ, and maybe it's a separate topic, and maybe it doesn't belong in this document. But I think we need to address the question of tone in responses to issues.

I know that we have general guidelines in the Drupal project (the Code of Conduct) about respect and politeness... But when someone in a position of some authority, such as a Drupal Core maintainer (of any of the various types listed in this document), makes a comment on an issue, it automatically carries extra weight beyond what a regular contributor comment would. So it seems to me that as Maintainers (again, of any type), we have an extra responsibility to keep the tone not only civil and polite, but to add an extra dose of patience, respect, and appreciativeness to our comments.

This is sometimes difficult. For instance, I am often faced with an issue where I've made the same patch review comment several times, and the problem still isn't fixed in the way I would like to see. It's often quite frustrating to be a reviewer/maintainer. But I try to start my next comment with "Thanks for the new patch! This still needs some adjustment to comply with the standards on (specific link):" or something like that, rather than "I've said this 5 times already and it still isn't fixed!!!". Or maybe it's just something I see over and over on different patches, but probably this particular contributor doesn't know about this common problem. In this case, I need to be extra sure not to convey my frustration of "this same problem again!!!" to the new contributor (or even to an experienced contributor who I know has made this same mistake before... it's not like I never have typos or lapses myself!

So...

That is a bit wordy, but... My specific suggestion would be to add something like this to this document:

----

Tone in issue responses

An issue comment from a Maintainer (of any type listed in this document), when commenting on an issue in their area of maintainership, will automatically be perceived as carrying more weight than the comments from non-maintainer contributors. Because of this, besides following the Drupal Code of Conduct (expected of any contributor), maintainers need to take extra care in their comments to be:

• Appreciative of the time and effort put in by the other issue contributors.
• Respectful of the knowledge, expertise, ideas, and opinions of the other contributors.
• Constructive and gentle in offering suggestions for how the patch or idea can be improved, including links to instructions and standards documents if applicable.

---
And then maybe we should make sure that both seasoned and new maintainers are specifically reminded of this guideline periodically, because we can all use the reminder now and then... or maybe reminded of the document as a whole? But this is really important -- violating it can drive both new and seasoned contributors away.... Maybe it should be part of that Skills bullet in the FAQ, not sure.

@jhodgdon, I think that's a great suggestion.

I think #89 is a good idea, and I may be going even more tangential here to the actual, but what gets confusing at times is when reviews/comments are made by people outside their "authority", and also it isn't always apparent to new contributors when an authoritative comment is coming from a maintainer. As a worker-bee in most of my contributions, I have been stuck in this situation several times (and ironically, I think the last one was related to an issue @jhodgdon was driving forward :) but not in an area where she is listed as a maintainer). I know who to pester in situations like this, but knowing who-is-who and what they do takes time to learn.

Yeah, that's a good point. I am only a partial "authority" when it comes to Documentation, Search, and Transliteration. On other issues, I'm a regular contributor. It may not be clear which "hat" I'm wearing... although MAINTAINERS.txt would be the central place to look.

I love the suggestion in #89 and it sounds like other people do too, so spun off #2493659: Add language about maintainer conduct in the core governance doc to discuss that explicitly.

The MAINTAINERS.txt changes are needed in Drupal 7 too.

And now that this policy is officially in place, it's time to start thinking about additional core committers for Drupal 7 also. I think at least two more are needed (one regular committer, and one provisional). It' s not clear to me whether the self-nomination process is for people who are interested in being core committers or only for people interested in being regular maintainers, but assuming the former, https://www.drupal.org/node/add/project-issue/drupal?version=7.x-dev&tag... is the place to do it if you are reading this and are interested in self-nominating. Otherwise, I'm sure I could come up with suggestions :)

By the way, is the final policy linked from somewhere?

I do not see a link to it at https://www.drupal.org/project/governance even. I had to dig around a while to find http://cgit.drupalcode.org/governance/plain/drupal-core.html?id=refs/hea... (the link I used above) which I guess is the best place to see the current version.

Oops. Quite right. Mirrored in the handbook at: https://www.drupal.org/governance/core

Also I think self-nomination works for any maintainer, though most core committers are appointed "top-down." So if you have specific suggestions for extra D7 core committers (+1 to that!) maybe also try reaching out to Dries directly.

Also, since this is at least the second time this came up, radically shortened https://www.drupal.org/project/governance to basically just point over to https://www.drupal.org/governance which is the actual canonical place.

In general, when an issue is tagged as needing a particular signoff, it is the responsibility of the maintainers for that role to provide feedback within one week.

Let me quote that line. It would be great if this would be applied not only to maintainers of certain subsystems but also to people higher up in the tree

#2057767: [policy, no patch] Revise the Druplicon logo now burns out actively contributors, which put a LOT of effort into that issue. Fairness should be applied across the community

@dawehner: That issue does not, as far as I can see, have one of the specific tags listed here that says it needs XYZ type of maintainer signoff that was missed.

Or are you referring to it being RTBC, and saying that any RTBC patch should get replied to within a week? That seems like a reasonable thing to add to the guidelines here, but I think maybe it should be a new sub-issue?

Also I see that your post here alerted webchick and Dries that action was needed and they did respond, but that doesn't change the underlying problem that it was sitting for quite a while first... but to be fair, the issue does not have one of the tags on it that says "This needs a specific type of maintainer feedback", so I don't think it falls within the guidelines here.

Right, it's also a feature, and it's well publicized that those do not get focus/attention during the lead up to release. So that particular issue definitely is in a bit of a grey area, not an indication that participation expectations don't propagate up the tree.

One thing I'm not clear on is how to manage the process when multiple components are involved.

I read this:

If a patch significantly impacts a single subsystem, the maintainers of that subsystem must be given opportunity to sign off.

then this:

If the change significantly impacts multiple subsystems, or represents a significant change in architecture or public APIs, the framework managers must approve or refuse it.

It reads like if the change is confined to one component the maintainer can reject the change (the approach, whatever,) but if it involves multiple components only the framework maintainer can do that? According to the matrix the subsystem maintainer has C/A (control/accountable) but with multiple they switch to S (suggest.) Without C, they lose the right to veto a change to their own component.

I started this thinking about a different question, though. How do we directly notify multiple component maintainers. We are suppose to use this tag, correct? Needs subsystem maintainer review (within the particular subsystem's issue queue)

But, how do we get the attention of a maintainer of another component? Pinging them individually is not a good solution, because it assumes the person working on the issue is comfortable doing so or even knows how to get their attention. Also, if that is left for the framework manager to do, it might only happen very late in the process.

Lastly, the word "subsystem" is being used interchangeably with "component," though the summary is primarily using subsystem. Is everything that isn't a topic considered a subsystem? The maintainers.txt still has a clear separation between subsystems, and modules and themes. If we refer to everything as a subsystem, the label on the issue metadata should be changed.

@davidhernandez: At this point, we've been asked to file follow-up issues for things that need to be updated (or that need further discussion) in this policy. #104 seems like a good one to discuss, but not in this issue. Thanks!

@larowlan wrote his thoughts on core process and roadmaps https://gist.github.com/larowlan/7864a8987e2ebbc24260. Just linking here.

Doesn't need to be assigned to Dries until the backport is RTBC. :)

opened #2590327: Fill out Provisional membership in maintainers.txt to fill out the provisional sections.

I stumbled across this issue today while looking at various governance issues. This was committed back in 2015. It was reopened in #97 to "The MAINTAINERS.txt changes are needed in Drupal 7 too." That D7 version of that file has been updated many times since 2015. I think this can be closed.

If there are points that still need to be discusses, I think it will be best to open a new issue and refer to this one.