Speed up decision making: define the project lead as an arbitrator/tie breaker instead of ultimate decision maker

The current governance is kafkaesque - I don't say this lightly, you can see the circles we went around in https://www.drupal.org/project/governance/issues/3252921 and https://www.drupal.org/project/governance/issues/3361198 even with explicit sign-off from Dries to do so, to try to restructure the technical working group which has only one member and take over responsibilities for coding standards which hasn't been functioning for years now.

Given a small change to one group tied up several members of the core committer team for hours, with no resolution yet, I think we should consider something like the following:

1. Delete everything under /governance or mark it all as deprecated with a link to issues.
2. Existing (active) teams do what they're doing according to their own conventions, and if there are changes (like taking on responsibility for coding standards) operate by consensus. This is technically covered by the existing governance where it mentions 'designates' - as in we can do what we like as long as Dries designates us to do it.
3. Write new governance docs in the meantime from the ground up that build in the ability to change things without single points of failure etc.

I agree with the need for moving this along without delay. However, I take a more cautious approach because I don't think we should be working with/under deprecated documentation. I suggest changing step 1 to 'Update the existing docs ASAP with minimal changes.'

Fortunately, before catch's comment I worked on updating the existing docs to reflect the discussion at the off-site. I have made an MR with those changes. I hope that this is 'good enough' to commit so we came move to 'starting from scratch'.

I came here to propose changing the release management language as a part of this -- it has frustrated me since the governance was first introduced -- and I see that is already included. Massive +1. In practice, the release managers have managed the schedule without Dries' input since at least DrupalCon Dunlin in 2016 (maybe aside from very early discussions about D9 in 2018 which were delegated to Gábor and then taken over by release managers anyway), and I'm pretty sure we've proven over the course of thirteen minors, two majors, and several hundred patch and security releases that we're doing so in a way that is predictable, increasingly sustainable, and healthy for the ecosystem.

Additional suggestions:

1. Years ago catch proposed that:
   • Committers be appointed or promoted with full consensus from the committer team.
   • If one committer opposes a proposed appointment, we discuss and see if there is a way to resolve the concern.
   • If two or more committers oppose a proposed appointment, we discard the proposal without need for further discussion.

    

2. Core committers should be able to appoint topic maintainers.
    

3. Core committers should also maybe be able to appoint initiative coordinators; it is weird for that role to suddenly be harder to get into than actually being a committer. Maybe initiative coordinators should be appointed by consensus between the initiative facilitators and product managers? As well as any existing coordinator for a given initiative (similarly as what is done for subsystem maintainers), but the language isn't there yet for subsystem maintainers so maybe that last bit is out of scope.
    

4. Finally, should product managers as a group select strategic initiatives, or the product managers alongside the project lead?

Addressed points 1 and 2. Points 3 and 4 need review from the indicated parties, I think.

For the second half of #8.3 as well as @catch's proposal to rewrite/improve all of it.

Actually #8.4 is also a pretty obvious improvement so I added that. So I think we could just use additional feedback from @Gábor Hojtsy, @Dries, and @lauriii about my point 3.

@xjm, thanks for adding your thoughts.

The points raised in #8 are valid but part of me wonders if they are out of scope and could be handled later. This issue was for making changes in response to discussions at the off site. And the first point in #8 was from 'long ago' which make me think it wasn't. Still, that and the others could have been discussed at the offsite, I just don't remember them. So, moving on.

All the suggestions except one are fine with me. I have responded on the MR to the one suggestion that I would like to change. I am OK with leaving the document unchanged and moving that to a separate issue or discussion. I would prefer we make regular incremental improvements to governance/policy anyway.

With #13 in mind, I am going to revert the one change I question so that can be discussed in another issue and not hold up this up. That can be another followup to this. I then added back 'full' when describing the committers that was added in the commit I reverted.

I hope this helps.

I created the followups from #10.

for #8.1 #3382024: Initiative coordinator and faciltiator appointments
for #8.3 #3382026: Committer approval process
for catch's comment in the MR #3382027: BEFM and FEFM are not in drupal-core.md

I think that covers all the followups asked for so far. Therefore, removing tag.

I don’t think we should call them permanent committers. They are “full committers” and that is language used in our docs. Permanent committer implies that you’ve signed up for life, which is definitely not what we want because that leads to burnout and broken governance. (Which is why we have the terms issue.)

Sorry yes 'full committer' is better.

NW for that change.

Pushed some changes following #3381857: Convert Drupal core PACSI table to Markdown for easier adaptation.

Setting to NR for the latest changes.

-11. If the change involves adding a new subsystem maintainer, a [product](#product), [framework](#framework), or [release](#release) 
+11. If the change involves adding a new subsystem or topic maintainer, a full core committer with the approval of other maintainers of the subsystem or topic must approve or refuse it.

Should we consider a case, when there will be no existing topic/subsystem maintainers at that point? Who will approve that to the full committer in such case? We have a few subsystems/topics without any maintainers. This could be relevant if we would like to add a first subsystem/topic maintainer.

I made a suggestion in the MR for the above.

I did an initial review of the merge request and I'm encouraged by the various changes. Lots of good and logical changes. While I plan to do a more comprehensive review, I wanted to share some initial changes that I'd like to see.

Change #1

-- **Project Lead**: The chief decision-maker for the project.
+- **Project Lead**: Sets the project direction.

I'd change to:

-- **Project Lead**: The chief decision-maker for the project.
+- **Project Lead**: Sets the project direction and acts as a tie-breaker when needed.

Change #2

+The Project Lead preserves the philosophy, culture, and principles of the project. They are responsible for ensuring the project fulfills its vision.
+
+The Project Lead works to ensure that the various teams and inititiaves function well. When disagreements occur that affect the project, they can be called upon to find a resolution.

I'd change to:

+The Project Lead set the project's vision and strategy, while also safeguarding its underlying philosophy, culture, and core principles. Additionally, they are responsible for overseeing the seamless functioning of various teams and initiatives within the project. In instances where disagreements or impasses arise, impacting the project's progress, the Project Lead assumes the responsibility of finding a resolution.

Change #3

-Core committers are the people in the project with commit access to Drupal core. Within the core committer team, the Project Lead assigns people certain areas of focus (defined below) to help with decision-making. Nevertheless, core committers are a group of peers, and are expected to work closely together to achieve alignment, to consult each other freely when making difficult decisions, and to bring in the Project Lead as needed.
+Core committers are the people in the project with commit access to Drupal core. Within the core committer team, the people are assigned certain areas of focus (defined below) to help with decision-making.
+
+Core committers are a group of peers who are expected to work closely together to achieve alignment, to consult each other freely when making difficult decisions, and to bring in the Project Lead as needed.

I'd change to:

-Core committers are the people in the project with commit access to Drupal core. Within the core committer team, the Project Lead assigns people certain areas of focus (defined below) to help with decision-making. Nevertheless, core committers are a group of peers, and are expected to work closely together to achieve alignment, to consult each other freely when making difficult decisions, and to bring in the Project Lead as needed.
+Core committers are the people in the project with commit access to Drupal core. Within the core committer team, the people are assigned certain areas of focus (defined below) to help with decision-making.
+
+Core committers are a group of peers who are expected to work closely together to achieve alignment, to consult each other freely when making difficult decisions.  They make decisions in aligment with the product vision and strategy set by the Project Lead and product managers.  Core Committers can bring in the Project Lead as needed to act as a tie-breaker.

Discussion

The phrase "the full core committers must agree" is used in several place. I have reservations about the requirement for 100% agreement. 100% agreement, means everyone has a veto. What if 95% of the core committers agree, but 5% do not? In general, I think an element of "Disagree but commit" is healthy in decision-making and collaboration. "Disagree but commit" means that even if someone disagrees with a decision or course of action, they are willing to support and execute that decision once it has been made. In many situations, it's not practical or efficient to wait until everyone fully agrees on a decision. "Disagree but commit" allows decisions to be made in a timely manner, which is crucial in order to be a more fast-paced environments.

Regarding the specific code snippet:

12. If the change is removing a full or provisional [core committers](#committer), the full core committers must agree.

I assume that the committer being affected has no voting power, as otherwise, achieving unanimous agreement might be unattainable.

That's my feedback for now. Thank you for working on this.

Thanks @Dries. Regarding "the core committers must agree", I think we wanted to leave the language open for the committer team to internally decide what level of agreement is required. I agree that "disagree but commit" is a useful strategy sometimes, but I think it also depends on the specific decision. E.g.:

For an issue that is tagged "Needs some_role review", it's up to that group to decide what level of consensus they want within that group. In many cases it only requires a single person's signoff from that role. I'd say that internally, the release managers use the following process:

• If an issue is has an obvious answer under current policy, or if it's not a significant change, a single release manager often posts their decision, and might mention that they did so in the RM channel.
• If the issue is tricky or is proposing a change that breaks current policy, the release manager will generally seek a +1 from at least one other release manager to validate their recommendation.
• For a significant release management change, like modifying the major release schedule, the release managers work for full consensus within that team (in addition to soliciting feedback from the other roles etc. as per the chart).

But all that is just what we've found works best for us. Other teams have different needs and might use different processes internally for decision-making, and I think it's good to leave that up to each team. This is already covered here:
https://git.drupalcode.org/issue/governance-3367191/-/blob/decision/drup...

Multiple maintainers may share the same role; in fact, it often works best to have maintainer teams, as described in the definition of a maintainer. When there is more than one maintainer in a role, the maintainers collaborate to accomplish the tasks for the role. The maintainers may decide among themselves however they wish to share these responsibilities. They might share the tasks equally, or agree that a certain maintainer within the team will be responsible for a particular task, period of time, part of the subsystem, etc.
If the maintainers in a given role disagree on a decision in their area, the decision may be escalated to the next level.

So, maybe the places we were using the phrase "the core committers must agree" we can link that language?

For something that impacts the team and project as much as adding, promoting, or removing a core committer, our current approach (and my recommendation) is to only take these steps with full consensus among the (other) full committers, as well as provisional committers within the specific role for new appointments. This is another place where we have a process already, and in an earlier draft (on this issue or another?) I added those process details, but folks pushed back on it being out of scope. I think there us a a followup issue for that already in another issue.

Regarding the proposed changes: I'm a little confused by the diff snippets above; is it possible to post your suggestions on the MR using the GitLab suggestion button?

If I'm reading it right, proposed changes 1 and 2 look OK to me. I might simplify the language of #3 a bit but that will be easier to do on the MR itself since GitLab highlights inline changes. I'm also not sure the bit about product managers belongs in that section. Maybe a separate change elsewhere?

(Uploaded the wrong version of the image.)

Yes, I can add the changes to the MR. I'll work on that.

then a majority of full core committers must agree.

While I don't like 'majority' because it implies a split in the group I think that this meets the intent of point 2 in the Issue Summary and is a step forward. Improvements can be made in follow ups.

I tried to update the Project Lead language in the MR through the GitLab UI, but I think I did it wrong. I don't think I did it right though. 🤔

@Dries, the changes are there though and read fine. All I found was a spelling mistake.

From commit 2c17067b : and deciding which issues to prioritize for a specific release.

I think this benefits from more details, here or elsewhere in the document. The definition above might require some tweaking to help explain how product management and release management best work together.

• Product management is about determining which features, improvements, or fixes should be prioritized (yes, that typically includes fixes).
• Release management is about the process of managing, planning, scheduling, and controlling the rollout of releases.

Maybe we can include the following snippet somewhere:

"The Product Manager decides which features, improvements or fixes should be prioritized based on various strategic factors. The Release Manager then makes sure these changes are smoothly rolled out to users. Together, they work to make sure updates to Drupal are stable and efficient, meeting user needs. Product management often determines what should be built and why, while release management determines how and when it gets released. "

@Dries I think the disconnect is in the word prioritised, which was my choice there but without giving it much thought, trying to get rid of anachronistic language more suited to pre-8.0.0. For release management it's more about scheduling or targeting (which priority can be a synonym of) - i.e. this issue would be better earlier, like the next patch release if possible, this issue later, this one really should be done for the next major release, this would be nice to have but can wait etc.. Then loads of wrangling on 'how' with bc/deprecations/multi-stage commits of larger issues/experimental modules etc. So something like "and deciding how and when issues are released." might work?

In the other sense of prioritization, we often have issues that committers haven't prioritized that nonetheless make it into releases, whether bugfixes or small feature improvements. Similarly there are plenty of issues that committers have prioritized which no-one has touched for months or in some cases years, because committers aren't the line managers of other contributors and can't direct work (except for the ones that are, but even that is not straightforward and not included in core governance either).

There's also issues that release and framework managers prioritise that product managers rarely or ever look at (and due to sheer volume most of the team doesn't look at most of the issues being worked on). If we were to add more detailed language, then it should reflect that reality that a lot of what actually gets prioritized is organic, or sometimes driven by external factors like the ckeditor EOL although I guess we could have decided to fork ckeditor4 or something so we do have some control there in a way.

This leaves the document with fairly detailed definitions of product and release management, but no equivalent for framework and frontend framework managers. Both kinds of framework managers are often dealing with what kind of developer-facing features to add or improve (config, entities, plugins, JavaScript libraries, Twig etc.) which very rarely if ever get input from product managers. Are those part of the product ('fixes') that product managers should be prioritizing? I don't think this happens currently. An exception is Gabor who has been very focused on major release readiness which touches on a lot of these things, but that was done outside his product management role as I understood it. Obviously @lauriii has personally done it too but as a front end framework manager rather as product management.

There's also crossover between framework and release management in terms of how to manage deprecations and additions of APIs, upgrade paths etc. especially when these are at the more 'developer end user facing' end of things -i.e. stuff that module and theme developers deal with a lot. We don't tend to delineate these very strictly and rather double-tag issues to get input from both people, and often when I'm commenting on issues like that I can't decide which 'role' I'm speaking from, or neither in some cases.

I also didn't understand how the quote mentioned in #32 mapped into day to day work until I read #33. I tried to propose language to address #33 and #32.

We have a concept of prioritization in the form of strategic initiatives. We can't enforce what people work on, but we can provide more visibility to initiatives that have strategic importance. Given that there's already pre-existing language that project lead and product managers determine the strategic initiatives, I proposed some language to the product manager definition to also mention it there.

For individual issues, we are using https://www.drupal.org/docs/develop/issues/fields-and-other-parts-of-an-... for defining the issue priority. I assume that the core committer team as a whole should be responsible for determining this ruleset?

Thanks everyone. Left some comments. There are now a number of significant changes to the governance proposed here that I don't really agree with, and I'm confused because folks already (rightly) -1ed other less significant changes I'd suggested before as out of scope.

Regarding:

A lot of what we actually do is answer queries in slack and issues about whether changes are allowed and which version they can go into etc. but we don't need to list that.

I actually do think we should list this, because being able to make good evaluations of risk is like. The core release manager skill. Not scheduling.

I went down a rabbit hole a bit looking at the proposed changes to the release management section, but @quietone correctly pointed out that those are also scope creep. The only thing we need to change there is the bit about the project lead setting the schedule. We could refine the rest of the language in a followup, and it would just need the four release managers to agree on what corrections we'd make, rather than blocking something that affects the entire project on it.

Anything that doesn't currently mention the project lead should be out of scope. Anything that does mention the project lead should only be updated to describe current practice, not propose new governance. For example:

• Current practice is that the product managers set the strategic direction in consultation with the Project Lead.
• Current practice is that the release managers set the release schedule.
• Current practice is that committers are appointed or promoted only with full consensus among full committers.
• There is no strict current practice about removing committers.
• There is no current practice about needing a second committer's approval for a subsystem or topic appointment.

I think if we stick to that, we'll be able to get this in, and then can have followups about other parts if desired.

xjm's feedback points out the scoping challenges I have been struggling with while facilitating this issue. I see that as a failure on my part and one I am to fix.

Therefore, I have reviewed the changes and pulled out anything not directly related to "define the project lead as an arbitrator/tie breaker instead of ultimate decision maker". In short, that means that, for the most part, only sentences that contained the words 'Project Lead' are changed. Everything else is to be moved to followups.

The followups needed are

• #32 - deciding which issues to prioritize for a specific release.
• Explaining what is meant by "the full core committers must agree"
• Review the definition/responsibilities/tasks for each role
• Any gaps - such as removing someone from a role

Looks good now. I fixed a few nits.

@xjm, thanks.

I have made the followups.

With the various follow-ups created and the changes restricted to the absolute necessary, this looks a lot better.

@catch, thank you.

Just noting in the IS that the followups are made.

There hasn't been further discussion here and there are plenty of followups to address other points. I think it is time to RTBC.

Alright, let's do this. Committed to main. Thanks everyone!

Reverting because apparently there were concerns not posted to the issue.

Yes, I'd love to see more input in this issue, especially from other Core Committers.

The reason I've not signed off yet, is that I've been reflecting on a few points regarding roles and responsibilities. Primarily, I've been thinking about how the core team will handle difficult decisions when there is no tie-breaker. One of the ideas I've been pondering about is whether we need to empower product managers to act as tie-breakers instead.

After speaking with many people in our community, it's obvious that not everyone agrees with our current decision-making process. A lot of people think that we're not always making the best decisions. This isn't due to the people involved, but rather from the absence of a more robust decision-making framework that promotes making more trade-offs and tie-breaking.

An example that has been raised with me on multiple occasions is about the strict security requirements for Automatic Updates, especially the requirement to include package signing in the initial release. Many believe it isn't essential to have such security requirements in v1, and that such capabilities can be added in a v2. I support this phased approach, but was not actively involved with the decision-making.

My intention is not to critique the way we handled this specific decision or point fingers at anyone. It's not even about this particular issue. I genuinely believe everyone is doing their best and acting with positive intentions. However, this situation underscores our need for more decisive tie-breaking and willingness to make trade-offs in our decision-making process. Without the role of a tie-breaker, making trade-offs becomes difficult, and we risk letting the perfect be the enemy of good.

Anyway, all this leads me to believe that we could benefit from more tie-breaking and more trade-offs. Typically in organizations, product managers collaborate with engineering managers, architects, release managers, security team members, and all other stakeholders to make informed decisions. While each role contributes valuable input, ultimately, it's often the product managers who have the final say -- or can act as the tie-breaker. This ensures a balanced approach, combining technical, security, and practical perspectives.

Although our processes usually work well, there are key moments where we need to get better at making balanced choices, considering various viewpoints and priorities, and accepting certain risks. In our current process, it can be tough to make trade-offs, and we risk letting the perfect be the enemy of good.

Long story short, I'm okay with not being the tie-breaker, especially since I haven't been very active in that role recently. However, I do see a lot of value in having active tie-breakers, and in making more decisions with trade-offs. It's why I'm increasingly convinced that we should enable product managers to take on the role of tie-breaker, and even have the ability to overrule concerns from other committers. I know this might be controversial to some, but to me it isn't.

Implementing this change would alleviate some of my current concerns with committing this issue as is. In other words, I'd love to enable product managers to act as the tie-breakers, before stepping back from my role as the ultimate tie-breaker. It means this issue would focus a bit more on shifting the responsibility of making final decisions from me to a broader group of product managers. I'm interested in hearing what others think about this idea.

For me with issue with automatic updates, is that the requirements were set a very long time ago by the original initiative team, and not systematically revisited, or at least not at all by the committer team in general until after TUF started to become a blocker in March this year (and literally people started pinging me panicking about it after not ever having mentioned it before).

IMO it would be a disaster to include automatic updates with neither TUF nor required https, it would be inherently insecure. This means that to skip TUF in phase 1, you would have to require https in phase 1.

You can see from #3351190-3: [policy, no patch] Should Package Manager require Composer HTTPS?, #3351247: Harden our HTTPS requirement, and #3364565: [policy, no patch] Make PHP's OpenSSL extension a requirement for installing and using Package Manager (and therefore, Automatic Updates and Project Browser) that there essentially had to be a re-discovery period to determine exactly what it means to not require https in automatic updates, what the wider support/requirements were in composer/packagist, Drupal.org etc. I do not feel that it was necessary to wait until the last minute to do this, it could have happened in 2022, or 2021 - then it would not have blocked the wider discussion from happening on a firm footing. I also felt like I personally ended up having to push forwards quite a lot of that on multiple occasions.

So it feels like using this as an argument where a tie breaker is needed is a bit flawed, because all this could have been dealt with before people were panicking about missing deadlines. And the issue for me is more about why were discussions about https vs TUF happening in initiative-only private slack channels that several core committers didn't have access to until June or July this year (or still might not) - that does not help any of us to make good decisions.

Maybe once all the https/require-tls decisions finally got made, it might still need a tie-breaker for TUF vs not, but solving the prerequisites to that much earlier would have led to all the March and later discussions happening with a lot less pressure and a lot more background information than they did.

I also don't really think it's a problem of committer decision making as such, but an issue of initiatives operating as silos, then suddenly bursting into the core queue needing multiple committer sign-offs without those committers having been previously involved in setting things like stability requirements. In general those requirements shouldn't be controversial - what makes them controversial is lack of clear documentation, especially of prior decisions, and running up against internally or externally imposed deadlines.

So we definitely need better processes in place to stop things getting to this point, but just adding a tie-breaker role on top of existing, broken processes, is not likely to help much.

Looking back at this issue as a demonstration of how governance change proposals would be decided, 6 committers posted comments out of 16 committers, sometimes with concerns

This isn't an accurate reflection of events though, because the issue was opened after an in-person, three day discussion, after which one of the main action items was for this change to take place.

Many of the people who haven't posted on this issue were at that three day meeting and made comments there. So they were not silent, it was just discussed in other places too.

It was my understanding that this issue existed purely to codify a decision made (mostly by Dries since he's the only person actually able to authorise the change at the moment, but also with informal consensus in the colloquial sense) and that we'd been stuck on wording trying to update a ten year old git repository that has been effectively unmaintained since it was created. I didn't realise that in fact we were relitigating the decision months after it had been decided until this was brought up yesterday.

We also had different, but not dissimilar, issues reforming the coding standards committee and taking on some of the responsibilities of the TWG, a process which also took months, despite everyone knowing what they wanted to happen, again due inflexible rules written into a git repository that were (and still are) outdated and still no clear boundaries about who is actually able to take on responsibilities for things - exactly what this issue is supposed to solve, but does not, because it's not fixed.

If this issue was indeed just updating the git repo based on a prior decision, it doesn't need active involvement from sixteen people. Anyone up for helping with it should be able to manage that (I am increasingly not up for it although I am apparently still posting). If we're undoing a decision made months ago because people have new reservations they didn't previously disclose, then that should be discussed properly as a group, and IMO this issue was never intended for that purpose.

I believe that we would benefit from tools besides formal consensus based decision making because relying solely on consensus based decision making can be very ineffective. At minimum, we should look into lazy consensus which I believe has been the intent in #3389468: Document how the core committers reach agreement on core policy issues. However, I support coming up with additional decision making mechanisms on top of that because I believe that different kinds of decisions require different decision making mechanisms.

That said, I share the perspective with @catch that I'm not 100% sure tie-breaking or trade-offs is always the biggest challenge. I can see that we could have benefitted from these but it wouldn't have solely solved these challenges. One of the key challenges with initiatives is that both large and small decisions get made within the initiative team and they accumulate over time. By the time committers get involved, it can be really hard to make any decision because there are no good options left. Some adjustments could have been a tiny push if they were aligned in the early days, but now that they are discussed years into development, addressing them would require a much more invasive approach.

In my opinion, one of the biggest challenges with the current process is that on many occasions, it seems to occasionally lead into decisions that don't take into account the big picture. On individual issues, there's a lot of focus on core gates but not on the overall impact of our decisions. For example, in #229568: Pathauto in core the Drupal core product managers have approved Pathauto to be included in Drupal core with the goal of making installing and maintaining Drupal easier since practically every site already enables this module. The issue is stuck because there are usability, accessibility, and technical concerns on whether the module and its dependencies adheres to core requirements. However, if we look at the forest from the trees, this issue would not make Drupal any less usable or accessible since almost all sites decide to install the module anyway and it has no competitors in contrib. I'm not against improving the usability, accessibility or architecture of Pathauto, but if it's not feasible or viable, does it make sense to prevent adding Pathauto to Drupal core because of that? I'm oversimplifying the issue because there could be additional considerations that would have to be made on top of this, for example, it could be harder to maintain the module in core, or maybe it would unblock resolving these long-standing issues as we did with many Views changes. However, at the moment it doesn't seem that we are even getting to this discussion.

I personally think that on a high level, the changes in the MR would take the governance to the right direction. In particular the changes related to product strategy would help empower the Product Managers to guide the whole team with the direction.

How I would envision the process in its ideal state with the proposed governance is that the Product Managers, with the initiative team define the high level objectives for the initiative. One of the objectives for the Automatic Updates initiative could be:

Site builders want their site to update automatically in a way that is secure and works in a commonly used hosting environment without any intervention from the user. Ideally this would be set up automatically for the site, but at first this could require manual steps that can be achieved within <5 minutes from intent to completion.

Next step would be to gather information from other stakeholders. In this case these would be at least the Security Team / Security Working group, Update Subsystem Maintainers and Framework Managers who would be responsible for providing input on what are the constraints for safety, and what consists of a commonly used hosting environment. Ultimately, the stakeholders could raise solutions like TUF as a requirement for the solution to be sufficiently secure.

Release management is responsible for coordinating the experimental module/theme process, such as commit timing vs. other experimental modules and making sure stability is realistic. They will also support the initiatives by helping them sequence individual issues, in particular disruptive changes during alpha and beta (schema, API changes etc.).

If the Product Managers do not believe the solution is feasible or viable relative to the benefit of the feature, they would encourage the team to look for alternative solutions, or make changes to requirements to find a solution that's feasible and viable. If there's no solution that meets the criteria, ultimately Product Managers with the Project Lead would have to make a decision if they still support the strategic initiative.

From that perspective, I believe that the governance change already gives Product Managers some power to guide the initiative requirements towards what they think makes sense for the users.

I believe that defining clear objectives in the beginning of an initiative will also help us with the challenges I mentioned, by helping us collectively keep the big picture in mind, as well as setting the right direction for initiatives from the beginning. However, on top of that I believe we also need a mechanism for the committer team to get information from each initiative during the lifecycle of its development, so that any course corrections can be done in a timely manner.

I must explain to the community that my opinion as interpreted by @Gábor Hojtsy in #52 were shared here without my consent. I prefaced my views in Slack in such a way that I thought they would be private to the group.

I encourage everyone to disregard what is stated in #52 about my opinions on consensus-decision making in regard to this issue.

Thank you.

In reviewing comment #50 and onward there some things that can be discussed in followups.

1) The expectation that more committers comment on the issue
An agreement was reached at DrupalCon such that decisions could be made in a 14 day time window in Slack. That agreement does not require all committers to comment on the issue.

2) Scope creep - expanding who are the final decision makers
This is the suggestion from @Dries, "shifting the responsibility of making final decisions from me to a broader group of product managers". The issue summary states that this is for the decision made in England "that the existing responsibility structures where he is defined as a decision maker are supposed to serve more as a guideline to where to turn when a tie need to be broken, not that he would need to block all of those decisions."

3) Where the documentation of the processes used for making decision resides.

Can someone clarify what in the current scope and in the current MR prevents this from being committed?

I believe that we would benefit from tools besides formal consensus based decision making because relying solely on consensus based decision making can be very ineffective. At minimum, we should look into lazy consensus which I believe has been the intent in #3389468: Document how the core committers reach agreement. However, I support coming up with additional decision making mechanisms on top of that because I believe that different kinds of decisions require different decision making mechanisms.

I'd also note that we make lots and lots of decisions individually or between two or three committers all the time on individual issues, and very rarely does a core issue need to go back to the committer team as a whole. When I'm not sure about an issue, I'll try to get a second or third opinion from other committers (and/or the subsystem maintainer), and then that's usually enough to keep going.

This however is compatible with consensus decision making - because it allows you to delegate stuff (like feedback on individual issue direction) to individual people and for them to have a degree of autonomy. Consensus decision making doesn't mean that 16 people all need to explicitly say yes to every action someone takes. The 'lazy consensus' approach we're adopting for most core decisions is similar - there are lots of issues that any committer might have a strong opinion about, but in practice maybe only 1/3 or 1/4 do. If all the people with an opinion about it agree, then we want to make sure that everyone knows what's proposed and has time to feedback (if we think it's the type of decision that requires this, like the new release cycle timeline), but we don't want to obligate everyone to feedback because we all have different availability and levels of interest to chime in on different things. But what the two-weeks-once-agreement-has-been-reached process is give us a semi-formal way to document that consensus has been reached on those issues, whereas previously there was none - someone just had to decide that it had been and hope they were right.

For an example of how this issue is blocking progress on issues that all of the core committers unanimously agree on, #3403142: Make longwave a full committer is right now blocked on Dries because this issue is still open. It was actually unblocked for the short period that the MR was merged.

- If the change is adding new full or provisional [core committers](#committer), [initiative coordinators](#initiative), or [topic maintainers](#topic), the [Project Lead](#project-lead) must approve or refuse it. The same is true if there is any cause for concern with adding a maintainer, or if the change involves removing a maintainer except at their specific request.
+ If the change is adding new full or provisional [core committers](#committer) or [topic maintainers](#topic), then it must be approved by the [core committer team](#committer). The same is true if there is any cause for concern with adding a maintainer, or if the change involves removing a maintainer except at their specific request.

Given that the MR keeps Dries in a tie breaking role, it doesn't move that anywhere else, I am baffled why we are blocking this on where the tie breaker role should move to when that comes into play maybe once every two years, while other issues are blocked for months at a time because of the other issues that this MR does (partially) improve.

iirc we couldn't even add longwave and/or quietone as provisional committers for weeks or months also because it required explicit sign-off from Dries which was not forthcoming despite multiple communications.

Re #59: I've approved issue #3403142: Make longwave a full committer. Going forward, I fully support Core Committers in promoting provisional committers to full status without my direct involvement.

Re #51: I think differently about automatic updates. I agree TUF is important, but I don't think we should wait for it to ship new features like Project Browser or Automatic Updates. We can add TUF later. My recommendation is to release these features earlier so users can enjoy them faster, give us feedback, etc.

Re #54: Lauri makes a great point with the pathauto example. In my mind, it demonstrates the same issue. Our requirements are too strict and sometimes don't make sense. It shouldn't be so hard to include pathauto in the core. It works fine as it is now, and we can always improve it later. We should put more on delivering important features to users as soon as possible, and be pragmatic in our approach.

In general, we need to find the right balance between delivering value quickly and ensuring our work is high-quality and secure. I don't think we have an effective system in place to manage those trade-offs.

I want to emphasize, again, that the issue isn’t with the people involved. The Core Committers, Core Maintainers, and Security Team are all dedicated and well-intentioned individuals. We all want what is best for Drupal. The real challenge lies in the need for a stronger decision-making framework.

Our current way of making decisions is almost entirely based on consensus. This method usually gives us high-quality outcomes, but sometimes it also makes our decisions less effective. Trying to meet everyone's needs can lead to scope creep, excessive requirements, stringent rules, etc.

I don’t want to delay issues like #3403142: Make longwave a full committer and am fine with deciding them through consensus. However, I don’t yet support using a consensus-based approach for everything. Drupal needs a decision-making system that’s effective at managing difficult trade-offs. Maybe a consensus-based approach is the right approach, but I'm keep to discuss that more, and get input from more people.

I don't need to be the one making all the final calls on many of these things, but I do want to help set up a better system for making decisions. A common approach in many organizations is to let product management handle most of the final decisions, but I'm also open to other suggestions.

The work we started at the Core Committer Offsite in England seems important. It sort of started with a big question, like "How can we triple our feature delivery to end-users?" (not the exact question we used). This approach could lead us towards major strategic changes in our governance, decision-making, and success metrics. It's the kind of big thinking that will help us find solutions for issues like the 'pathauto problem' described above, rather than being focused on incremental tactical improvements. While this is likely beyond the scope of this particular issue, it's certainly related and relevant.

I appreciate the open conversation about it. It can be hard to talk about. As a next step, I'm going to re-read the latest MR request and recommend a path forward.

Re #56: The 14-day decision window on Slack agreed upon at DrupalCon is likely very effective in many cases, but I'm not convinced it's always the best approach. I think it would have worked really well for #3403142: Make longwave a full committer, for example.

We agreed to try out this new method and make changes if needed. In this particular case, I believe more public discussion and more input from core contributors is important. I'd really like that.

I'm not upset with what happened. The MR request was committed based on what we agreed to at DrupalCon. No problem. Concerns were voiced by couple of people, myself included, and we rolled it back. Totally fine!

At the Core Committer Offsite, I discussed the concept of 1-way and 2-way door decisions (per Jeff Bezos). I believe this issue represents a 1-way door decision, which likely means it requires more time and thorough discussion. Maybe that the lesson learned?

Since #50, I've kept thinking about the proposal to make product managers tie-breakers.

I've seen how hard it is to make trade-offs with consensus based decision making. It is hard to +1 an idea that is suboptimal for your own performance indicators, even if you feel that it makes sense from the user perspective. As a result, we try to optimize for decisions that don't lead to deficiencies in any area, because naturally everyone wants to be successful in their respective area. This doesn't necessarily in lead into decisions that are best from the users perspective, because they might be willing to accept a feature with deficiencies, so long as it solves the original problem for them.

I think another symptom that hasn't been mentioned is that contributors have hard time finding the actual requirements, because the current decision making process is really complex. It's not just that they need to get buy-in from one person in the role, they need to think whether all people in the role are in consensus and if that consensus holds with the whole group of committers, topic maintainers, and subsystem maintainers. As a result, we've seen contributors setting the bar even higher for themselves to not run into issues later on. We've seen this happen in several initiatives.

In many organizations, release management / engineering would not be able to make final decisions on prioritizing technical debt or bugs relative to feature development. There would be a negotiation between product and engineering, but product managers would be responsible for balancing the engineering needs with the user needs in the product roadmap.

Essentially tech debt is a way to deliver value by delivering less value in future, which in my mind relates to product strategy; how much should we prioritize short term wins over long term capability to deliver value. Ultimately product managers are forced to keep technical debt in control too because if tech debt spirals out of control, the engineering can no longer function efficiently. After all, engineering is their primary way of delivering value so it's definitely an important consideration for them.

Product managers also need to be interested in solving bugs and improving DX, because they have a direct impact on user satisfaction. From this perspective product managers should be able to prioritize between these needs. In the end all of it is done to satisfy the users, and to keep the project able to deliver value in a continuing fashion.

All that said, I personally think there would be benefits in making the product managers responsible for making trade-offs when it comes to product facing decisions. I don't think we need the product managers to make trade-offs in other types of decisions, e.g. governance changes.

Based on that, I could see us adding something like "Product managers make final decisions on merging user facing issues and experimental status of modules and themes."

I didn't participate before because my opinion goes on the lines of #62 and I didn't feel I have the role to say that. But since Lauri has said it now, I want to state my support to this idea. Decisions related to the product should be informed also by data beyond the product itself, like the market status, that should help weighing the trade-offs.
Decisions like the ones mentioned to appoint new committers shouldn't be blocked by this product new role because I'd understand they would fall more into the line of "governance, philosophy, goals, principles...".

@Dries

Re #59: I've approved issue #3403142: Make longwave a full committer. Going forward, I fully support Core Committers in promoting provisional committers to full status without my direct involvement.

Does that include committing the change here so that we don't need to bypass the document to get things done? Right now even with this sentence, it still requires ignoring what's actually written in the document to do things.

Re #54: Lauri makes a great point with the pathauto example. In my mind, it demonstrates the same issue. Our requirements are too strict and sometimes don't make sense. It shouldn't be so hard to include pathauto in the core. It works fine as it is now, and we can always improve it later. We should put more on delivering important features to users as soon as possible, and be pragmatic in our approach.

The problem with this for me, is that this is always presented as us having immovable rules which the product managers must be able to smash through to get features committed, which once again is looking at every feature addition situation as ending in some kind of deadlock which must be broken. Instead we should be re-evaluating the rules (and whether the rules actually say what people think they say, which they often don't) so that they account for a pathauto situation.

The 'rules are too strict' issue for me comes about from several places:

1. The 'core gates' were added at the end of Drupal 7/beginning of Drupal 8, long before the new release cycle. They haven't been properly updated/reviewed since then, and they don't reflect what we actually do. In some cases they're too prescriptive and actively wrong (the front end one says that JS has to be compiled to ES5, and talks about the stable theme which we're deprecating and removing from core in favour of starterkit etc.). In other case they're not prescriptive at all, just propose some sensible guidelines for evaluating issues, but people come up with entirely different interpretations of what that means in practice. Some of them should be moved to an MR/issue checklist, some should be absorbed into other, more dynamic documentation like the deprecation policy (actually a howto, and constantly updated and revised), or tooling like phpcs/phpstan etc. I'm not sure they are doing us any good at all in their current state.

2. People 'over-apply' the gates - for example when Olivero was due to be committed to core, the Olivero team organised a cross-browser testing end-to-end including a full testing script, posting videos to issues proving it had been done. However Olivero had already been cross-browser tested during development and documenting that this had been done in an issue would have been enough. No-one asked for the massive cross-browser testing sprint to happen, nor do any of the gates say it would have to be done like that, it was just assumed to be the case. I actively tried to stop it at one point but it was already in motion by the time I realised how extensive and time-consuming it was going to be. For another example, the testing gate is over-applied to (see #2972776: [policy, no patch] Better scoping for bug fix test coverage for lots of discussion). Not a gate, but "don't RTBC your own patch" is also over-applied - it was designed to stop single-author RTBCs, but people interpret it as if they wrote any code, they can't RTBC, which is also not the case.

We are often having to work against these outdated and over-applied rules, but that's not a result of committers disagreeing as such, at least most of the time it's not. The current gates are brittle, they need to be robust and flexible. For example I think emphasising usability and accessibility testing is great and we should keep doing it for changes that will benefit from it, it's worked great for the recent field UX work. The usability gate has nothing in it to say that token/pathauto would fail it, it just says it should be tested. As far as I know that hasn't happened with pathauto, so why are we pre-emptively saying that the UX gate needs to be bypassed for it to land? Reminds me of taxonomy turning out to be the easiest thing that was usability tested at UMN in 2008.

The other issue with pathauto is that no-one has volunteered to work on it or maintain it in core. Does product managers bypassing the gates mean that it'll be copied from contrib and committed to core as is, as well as token module, with no maintainer? If not then how does it help it land?

@lauri

I think another symptom that hasn't been mentioned is that contributors have hard time finding the actual requirements, because the current decision making process is really complex. It's not just that they need to get buy-in from one person in the role, they need to think whether all people in the role are in consensus and if that consensus holds with the whole group of committers, topic maintainers, and subsystem maintainers. As a result, we've seen contributors setting the bar even higher for themselves to not run into issues later on. We've seen this happen in several initiatives.

Right I agree with this - but then isn't the solution for that making it so that the requirements are more clear and adaptable to specific situations? If we leave them as-is and add a product manager override, it will make them even hard to figure out.

I acknowledge the need for looking into updating the rules to make sure that they meet our current needs. It's important that we continue to address the core purpose of the core gates, which is to set clear expectations for changes made to Drupal core. Making product managers responsible for making the trade-offs would not make this less important.

Even with the updated set of guidelines, we would benefit from being able to make trade-offs. By enabling product managers to make informed trade-offs, we can improve our project's velocity and speed-to-market. This approach would help us focus our efforts more effectively, avoiding use of time on less impactful aspects. That's why I believe we should try to solve these problems on multiple fronts; by updating the decision making process, as well as the guidelines and rules.

I believe that this proposed change could shift our community's focus more towards user needs and strategic project goals. Empowering product managers to make informed trade-offs sets a precedent for the entire community. It encourages a mindset shift, where the broader perspective becomes an important consideration in our discussions and actions.

@Dries

Re #51: I think differently about automatic updates. I agree TUF is important, but I don't think we should wait for it to ship new features like Project Browser or Automatic Updates. We can add TUF later. My recommendation is to release these features earlier so users can enjoy them faster, give us feedback, etc.

My comment in #51 didn't contain an opinion about whether TUF was a requirement, and that was deliberate so your comment here is a bit of a non-sequitur. What I brought up was that the wider committer team was only brought into the discussion in March when it didn't look like it would land before 10.1 - certainly that was the first time anyone had approached me about TUF. It was also impossible to find prior discussions about TUF because they'd been either in a private initiative-only channel which most committers weren't in, or in the case of the original decisions around TUF, impossible to find (possibly in-person sprints that were never written up? Who knows). So talking about how you might have a different opinion about a last minute decision years into an initiative, is not addressing the problem of how this ended up being an issue in the first place. I think more public discussion and documentation earlier would have helped, then it might not have ended up being a last minute crunch/blocker at all.

@lauri:

I believe that this proposed change could shift our community's focus more towards user needs and strategic project goals. Empowering product managers to make informed trade-offs

The most recent time I remember this happening, was when (iirc) Dries and Angie told the workspaces team to try to ship a trash module as an early feature for the workspaces initiative so that there would be something user-facing early on.

This was done without discussing it properly with the entity maintainers and framework/release managers, who would have pointed out (and already had, right at the start of it being a core initiative, in person to the initiative team) that the entire workspaces feature rested on revisionable/publishable support in core entities and would need to add that to be successful. The end result was that we don't have a trash module in core, and we also still don't have a stable workspaces module - because the the features (and they are features as well as API support, if small incremental ones) that we actually needed for workspaces (revisionable and publishable entities everywhere) were deprioritised until everything was already off-track. For the record I'd was/am fine with a trash module/mode in core, just not at the expense of the initiative stalling.

Now we could say that all happened a long time ago, and it was quite a long time ago, but the consequences are still with us (no stable workspaces, content_moderation having all the drawbacks that workspaces is intended to solve etc.).

This is a very, very different kind of trade-off to whether token/pathauto module UX is considered 'good enough' for core, which only affects token/pathauto UX, not multiple core subsystems, data integrity etc. For me that's absolutely a product management decision. The one case where I could properly see it coming up against other roles was if token browser was using a js framework alien to core that the FEFMs were completely opposed to or something.

#67: When evaluating solutions, we would evaluate if they are valuable, feasible, usable, and viable. In this process, product manager should not work in isolation but in collaboration with various stakeholders:

• Valuable would be owned by product managers, but they may need input on developer facing features from framework managers.
• Feasible would be owned by framework managers, subsystem maintainers, release managers, and initiative team.
• Usable would be owned by usability topic maintainers and product managers.
• Viability would be owned by product managers but requires collaboration between committers and initiative team.

I don't believe that product managers should be independently deciding on solutions. Any decision on solutions would still require the buy-in and support of these roles.

Taking the workspaces initiative as an example, product managers would set high-level objectives for the initiative in collaboration with stakeholders like initiative coordinators and other committers and relevant subsystem maintainers. They would also work together to define the MVP scope. While product managers may suggest initial milestones, such as introducing a trash module, they do not have the final say. If, for instance, subsystem maintainers determine that this solution is not feasible as it is not working towards addressing the core technical challenges of the initiative, the MVP scope should be redefined accordingly. If we cannot find a solution that meets all our criteria for being valuable, feasible, usable, and viable, then we must shift our focus to other problems that have solutions that meet our criteria. Once a solution is identified and we've agreed on the MVP, product managers would take the lead in managing trade-offs between value, viability, and usability.

If, for instance, subsystem maintainers determine that this solution is not feasible as it is not working towards addressing the core technical challenges of the initiative

Trash module was feasible - that bit wasn't really the problem. In isolation, it was theoretically quite possible to introduce a trash module (or trash system baked into entities) into core in parallel to workspaces.

The problem was that introducing a trash module wasn't a fundamental requirement for workspaces (which we can describe as the ability to stage, preview, and publish changes to multiple entities via workflow). As such, working on trash module didn't help workspaces get stable quicker, it did the opposite by redirecting efforts to something else. So it wasn't a case of technical feasibility, it was literally a case of product priorities being set about shipping user-facing features in a different order, to get a 'quick win' from the initiative, which became eventually at the expense of the initiative as a whole. It wasn't the only thing that led to it stalling, there were major architectural issues with the contrib modules before it became a core initiative too, it's just the one that's most relevant to this conversation.

---

Can you explain how these two statements interact, because for me they contradict each other:

"Product managers make final decisions on merging user facing issues and experimental status of modules and themes."

vs.

While product managers may suggest initial milestones, such as introducing a trash module, they do not have the final say.

I think it would have been reasonable for product managers to say 'actually, we don't want workspaces, we want a trash module' and that might itself have been OK, for me they are independent though closely related features. But as above, that's not what happened, it was an attempt at sequencing of work which went wrong, one that added early additional scope to the initiative workload, which then didn't have the capability to finish.

Trash module was feasible - that bit wasn't really the problem. In isolation, it was theoretically quite possible to introduce a trash module (or trash system baked into entities) into core in parallel to workspaces.

What do we think could have been done better back than? What should have been considered that we didn't?

Can you explain how these two statements interact, because for me they contradict each other

I was thinking these as different stages of the software development lifecycle. Before something has been built, the product managers would need a buy-in from other stakeholders that the solution is feasible. Ultimately product managers would be responsible for deciding what is "good enough" to ship, and what are the trade-offs that can be made. If there is no "good enough" solution that is feasible, there's nothing to build.

The wording may not have been perfect and I'm happy to revisit that.

What do we think could have been done better back than? What should have been considered that we didn't?

1. It was another example of a 'one company initiative' - Pfizer controlled all of the funding, but was relying on high level reviews from people like me and @alexpott and the entity system maintainers who had no specific funding to handle it (until @amateescu was brought in very late). I personally spent hundreds of hours reviewing workspaces issues, which I felt like I had to do to avoid issues going off the rails, since I had specific experience of solving the same problems in Drupal 7 as well as being one of the entity maintainers, but it was a drag on other core work for me. At 20 hours per week on core, we're talking about catch-months of core time that wasn't factored in, and that's just one person.

2. There was a focus on shipping modules-as-features to have quick wins. We've discussed trash module already, however (and this is more with hindsight), I think content moderation was equally not helpful to do up-front. I always thought it should be built on top of workspaces so that previews and nested content entities worked - i.e. a 'workspaces lite' with the content moderation UI and workspaces under the hood would be a great module, but didn't push enough for that approach from the start. See #2972622: Split the workspaces UI into a separate module and #3143074: Content moderation unable to deal properly with translations and entity relationships for some discussion of that.

3. The pre-requisite issues like forward revision support (which was mostly already there anyway), publishable/revisionable taxonomy terms, menu items, block content, media etc, and also issues like the generic revision UI were afaict not really recognised as incremental, shippable, features but more relegated to 'refactoring/architectural blockers'. By not recognising these as incremental features, people were looking around for things in the #2 category to do 'in the meantime' while those got done. The recent field UX work is a good example of us doing the opposite of that and actually doing small improvements which build on each other as the way the entire thing gets done.

I was thinking these as different stages of the software development lifecycle. Before something has been built, the product managers would need a buy-in from other stakeholders that the solution is feasible. Ultimately product managers would be responsible for deciding what is "good enough" to ship, and what are the trade-offs that can be made.

OK that makes a lot more sense to me, thanks for expanding. So essentially, everyone is involved in trying to define scope at the beginning, but product managers are responsible for defining 'readiness' towards the end.

I think my main issue with that is that with something like Claro or Olivero, the overall scope is pretty well understood by everyone and it really does come down to a decision on how polished it needs to be for beta/stable - so at some point it's a judgement about whether those themes were an overall improvement compared to Seven/Bartik, whether remaining work can be done once they're stable etc.

For workspaces (and several other initiatives), the scope itself was constantly changing and intricately tied up with readiness/stability, so it really needs constant review and input, and also the potential damage if things went wrong (upgrade paths, security vulnerabilities, data integrity issues) were very severe.

#71.1 Having sufficient resources, like having funded committers / subsystem maintainers would be considered as part of viability. I agree that single company initiatives have a higher risk. We should encourage collaboration across organizations when possible, but I don't think we should make that a fundamental requirement because it seems that many of our initiatives are heavily relying on a single company. I believe we should focus on making sure that if a company wants to fund an initiative, we help them ensure they have sufficient availability of committers and subsystem maintainers for the initiative. This could be either passionate committer / subsystem maintainer who are willing to volunteer or the company could try to fund a subsystem maintainer or committer. Note: the fact that we have funding doesn't automatically mean we should work on that idea. We would still have to make sure the idea is valuable, the solution is feasible and it can be made usable.

#71.2 & 3 In the context of Drupal, I personally believe in an approach for MVPs that help build foundations for the future. Creating MVPs always require extra effort. However, I believe they are still valuable since they can be used for de-risking the project. For this reason, they should work within the same problem space, both from user and technical perspective. If the MVP is not in the same problem space, or largely ignores all technical constraints of the long term objectives, it is not effective at de-risking the project.

The idea of workspaces lite seems to align well with that, but given that I wasn't involved in the initiative, it doesn't seem fair for me to second guess if I would have decided something differently.

For workspaces (and several other initiatives), the scope itself was constantly changing and intricately tied up with readiness/stability, so it really needs constant review and input, and also the potential damage if things went wrong (upgrade paths, security vulnerabilities, data integrity issues) were very severe.

Issues with security vulnerabilities, data integrity issues, and upgrade paths are all important considerations from product management perspective. They may lead into losing user trust, issues with compliance with regulatory standards, or even potential reputational damage. Product managers would largely outsource these aspects to framework managers and release managers and I believe they would mainly intercept if they had strong reason to do so, e.g. success criteria not aligned with user needs.

High-level comments and summary, my interpretation only:

• It sounds like Lauri (#62) and ckrina (#63) agree with me about the need for strong product managers. Gabor might agree as well (#52). However, the opinions of the rest of the team are not as clear yet.
• I agree with Catch (#64) that we should update our rules/gates, and foster the right behaviors around them. Most work should be done without a product manager's direct involvement; people and teams should be able to work independently and have autonomous decision-making. This is why good rules/gates are so important -- they guide our daily actions and decisions. So, I fully support Catch's suggestion to revise our gates and the way we follow them. We started some good discussions at the Core Committer Offsite, and I'm eager to keep that momentum going.
• I also agree that we made product management mistakes in the past (comments #66 to #70) -- our goal should be to learn from those and hold product managers to better standards and procedures. We should always be improving.

Given that there might be some agreement on these points, and in an effort to bring different ideas together, and hoping to make some progress, I drafted some specific wording that we could potentially include in our governance document. I'm thinking it might be helpful and productive to review some more concrete language. Here is a first draft:

A product manager is responsible for defining the strategy and roadmap for the Drupal project. They work closely with the Project Lead and Core Committers to ensure that Drupal meets the needs of our end users.

The role of the product manager is to understand user needs, market trends, and Drupal's product direction. They use that understanding to oversee the development and maintenance of Drupal.

Product managers ultimately decide what work to prioritize and what new features to develop. They set the requirements for these features and decide when they're ready for release, taking into account their quality, ease of use, and how well they meet market needs.

Product managers are also tasked to balance the need for innovation with the need of maintaining a reliable, secure product. To do so, product managers assess technical debt and decide how much is acceptable in pursuit of short-term goals versus long-term sustainability. For the same reason, product managers also have the final say on risk management, including the acceptance of certain bugs or security concerns.

It's preferred for the Core Committers to reach consensus on key decisions like this. However, achieving unanimous agreement isn't always possible due to differing priorities and perspectives of what's best for Drupal. This is where the role of a product manager becomes crucial.

When there are conflicting views, product managers will act as mediators and decision-makers. The product manager's role is to ensure that decisions are made efficiently and effectively, keeping the product's overall success and sustainability in mind. In doing so, it's essential for product managers to consult with all relevant teams and stakeholders -- especially with the end users, release management team, and the security team -- to grasp every aspect impacting their decisions. While product managers lead the decision-making, their approach should be transparent and include everyone's input.

Ultimately, our goal is to strike a balance among three key approaches: (1) individual decision-making, guided by our established rules, gates, and procedures, (2) consensus-based decision-making by the Core Committers, where we can adapt any rules as necessary, and (3) relying on the product manager's judgment for more complex or significant issues, particularly when consensus isn't reached. This blend of strategies enables us to foster strong teamwork and efficiently develop product improvements.

Essentially, this is a pretty standard definition of the role of a product manager, just adapted to Drupal's context. It's how nearly all software organizations work. That said, I'm curious what you think, and if you'd change anything to the proposed language.

Also, thank you all for all the valuable input so far. This is an important discussion, and I appreciate that we delve deeper into it. Thank you for the thoughtful environment.

Lastly, I recognize that there are more things to unpack from this thread. I'll try to respond to more of it later.

Opened #3404570: Make core committers responsible for appointing new core committers and topic maintainers.

This thread is already quite comprehensive, so I'll try to be brief.

I support strong product managers. Any burden of proof should be on retaining a process that causes friction, and I'm especially loathe to situate processes in Dries' hands in ways he doesn't see as ideal.

My other rule of thumb goes like this: "If someone ultimately oversteps a permission boundary, is it auditable and easily reversible on review? If so, consider whether it should be a boundary at all." By that measure, it's not like these approvals are the final step for a major change ending up in a release, I assume. So, the consequences for finding the process overly frictionless seem low.

In case we end up in a place of conflict, that seems exactly when Dries would step in as a "tiebreaker" anyway, which also suggests low risk for this change versus the status quo.

@Gábor Hojtsy, no worries.

Just to clarify. I do prefer consensus decision making and I will probably always promote it. However, this issue, by definition, is not about making consensus. I regret that those comments diverted attention from the scope of this issue.

we should update our rules/gates,

FYI. This is on my list of policies to review. And there is an existing issue for a change to the testing gate that I need to follow up on. But I see the real work there, as here, is improving our willingness to make small incremental changes to policy level decisions and to trust ourselves to change them in the future in a timely manner.

From the reading the recent comments I have learned more Drupal history. Thanks

I see one proposal to the document. Changing the product manager role description seems out of scope and we have had trouble on this issue with scope. However, it is also about defining a hierarchy for decision. It is somewhat different that the issue title and scope and yet does have the same intent. To help reviews, I have added it the MR. I did change the format of one sentence to use a list instead of (1), (2) and (3). And then adjusted the matrix accordingly. I did not check if other changes should be made.

I reviewed the list of followups needed in #39. I think they have all been made and that the latest proposal covers #32. Therefor, removing the tag.

I've gone through the comments again and the MR is updated with the suggestions made. There is lots of good discussion from #50 onward and that resulted in @Dries's suggestion in #73 which I worked in to the MR for easy review. Is this now good enough to commit?

This issue is blocking progress on other issue so I am tagging as a blocker.

---

Personally, I support the MR as is. It is much better than what we have now. If we has a priority higher than 'Critical', I would use that! ;-)

I could not agree more with #3367191-75: Speed up decision making: define the project lead as an arbitrator/tie breaker instead of ultimate decision maker. I admittedly have not been across the full discussion, but it feels like we are trying to get it perfect before making any changes. I wonder whether the governance process being so slow in the past is resulting in folks being concerned with getting it exactly right because we may only have one shot.

I would encourage aiming for good over perfect. Being able to adapt more easily seems like the goal here, so if we find that the changes have created a new problem or failed to address an existing one, we can iterate on it.

I'm comfortable with Product Managers being the tie breaker in the case of a stalemate but it would be good if their thought process/research/reasoning was made public. With any luck that will change the stalemate and prevent needing to use a tie-break option.

My concern is that we have no structure in place to ensure diversity of the product managers. Currently there are 3 product managers from one company and a fourth who is not as active. There is a risk that in the case of stalemate (should that happen) that publicly it will be perceived as that 'we did what was best for one company'.

It would be good to open a followup to try to recruit an additional active product manager from the community with different perspectives. I've opened #3419653: Consider recruiting another product manager to discuss that.

In terms of the code changes here, +1 from me.

I reviewed https://git.drupalcode.org/project/governance/-/merge_requests/3/diffs. I hope that was the correct version. The version I reviewed includes the expansion of the product manager's role. Example language that was added: "Product managers are also tasked to balance the need for innovation with the need of maintaining a reliable, secure product. To do so, product managers assess technical debt and decide how much is acceptable in pursuit of short-term goals versus long-term sustainability. For the same reason, product managers also have the final say on risk management, including the acceptance of certain bugs or security concerns.".

I'm comfortable with all changes but one. The change I'm not 100% comforatable with is the change to "_Any_ impact on core project governance" in the RACI changing from "Consulted, Accountable, Performed" to "Informed", and the double asterix at the bottom that says "✱✱ The Project Lead may choose to be involved in these decisions but their involvement is not required.".

Per the proposed updates, part of my job is to be "... responsible for overseeing the seamless functioning of various teams and initiatives within the project.". That requires having some ability to define how our team works, how we work together, etc. It means I need to have an active role and be able to sign off on significant changes to drupal-core.md, for example. At the same time, I don't feel like I need to sign off on #3406954: Proposal - create a 'Project Update Working Group'.

This might need to be "Control, Accountable" rather than "Informed". I'd also remove the double asterisks as I will need and want to participate in governance changes like other Core Committers. For Core Committers, it changed from nothing (empty cell) to "Control, Accountable, Perform". Maybe that needs to be "Accountable, Perform" instead? This means we'd have shared "Accountability", but I'd have the additional power to veto important changes I fundamentally don't agree with. I think that means the Core Committer team can decide on issues like #3406954: Proposal - create a 'Project Update Working Group', but not make unilateral changes to drupal-core.md.

Ideally, we would have a more granular RACI so we can capture this in more detail. I say that because I think "_Any_ impact on core project governance" is very wide, and there are probably a couple exceptions I'd make. As mentioned, I certainly don't want to sign off on any change, or many changes, but I want to retain the ability to re-invigorate or streamline the Core Committer Team if really needed. Open to ideas ...

I understand the importance of not prolonging this process/issue. I suggest we go with my suggestion, and make additional refinements in follow-ups? Some of this could be refined as part of #3389468: Document how the core committers reach agreement on core policy issues, for example. In the mean time, this is an important step in a good direction.

By that measure, it's not like these approvals are the final step for a major change ending up in a release, I assume. So, the consequences for finding the process overly frictionless seem low.

It's the opposite, where we've had deadlocks is usually precisely about which release a change might land in (or at what level of experimental stability) where it's either going to be released and hard to remove. or miss a minor branch that it otherwise might land in. For me the bigger issue is that this ends up happening so late in the process, and only when some kind of release deadline was approaching - i.e. pretty much every minor release, someone whether a core committer or other contributor will start pinging me about some kind of release or framework manager sign-off I often hadn't heard about before. -If we handled it all much earlier and more pro-actively it would happen less, although things change so it still wouldn't eliminate it.

I've left a comment on the MR, I don't think the current proposed language sufficiently differentiates between tie-breaking a deadlock and completely overruling all other roles.

Also do we have a follow-up about topic maintainers? As with committers, I think the committer team should be able to approve those (we have one issue that is not blocked just yet but will be as soon as it's ready).

Very interesting and astute issue! Looking forward to reading everything in detail 🤓

but it would be good if their thought process/research/reasoning was made public

— @larowlan in #83

Yes! Can we add that to the wording? 🙏 (This also would help make any Core Contributor be more informed, and would guarantee a transparent rather than an occasionally opaque decision making process.)

For me the bigger issue is that this ends up happening so late in the process, and only when some kind of release deadline was approaching - i.e. pretty much every minor release, someone whether a core committer or other contributor will start pinging me about some kind of release or framework manager sign-off I often hadn't heard about before.

My own experience has been that generally people really start pushing for sign-offs when there's already risk of it being too late for the decision to happen. I've suffered from this too. I remember thinking that the committers probably have more important challenges to concern themselves with. To address this, we need more proactive involvement from the committers to enable decision making early in the process. We need a culture where it's clear that the committers want to be involved and that reaching out to them with a low bar early on is not just allowed, but expected.

On top of that, I think it would be helpful to have a discussion on how different roles would like to sequence decisions, e.g. at which stage of the process do we start becoming uncomfortable to mark a module stable. I don't know that we should set hard limits but it would be helpful to hear what these timelines look like because now the only timeline we track is the actual deadline.

I'm comfortable with Product Managers being the tie breaker in the case of a stalemate but it would be good if their thought process/research/reasoning was made public. With any luck that will change the stalemate and prevent needing to use a tie-break option.

I believe product managers should conduct their work transparently, and give other roles an equal opportunity to be heard. I believe the current change already documents these both: "While product managers lead the decision-making, their approach should be transparent and include everyone's input.". Do you think that sufficiently covers it, or do we need to make some changes to that?

I don't mind if product managers get the final casting vote when there is a deadlock, but this leaves open the possibility of product managers overruling all (or even most of) the framework and release managers about a particular decision, which in such a case would make release and framework management impossible to carry out.

In practice, it would not be easy for product managers to make a decision where all of the framework and release managers are against the decision. Many of our decision require commitment from all of the roles, and this is hard to achieve in a situation where everyone in those roles is against the decision. For this reason, this would not be effective, even if the governance technically allowed it.

Thinking about that example a bit more, it seems that a situation where the release managers and framework managers are against product managers would likely point to a bigger problem. In this situation, it seems more appropriate to have discussion about the vision and the strategy. In particular if the vision and the strategy are clear enough, if there's alignment on them, and if the team is committed to executing them.

To me this seems more relevant to scenarios where there are some people vetoing a decision, but there's at least some support for the decision from all roles. These are the scenarios where this could help us avoid postponed and diluted decisions.

We opened #3391592: Define goverance changes that the core committers are responsibile for for discussing how the committers make changes to the governance. I reverted the governance row change from the PACSI matrix to address #84. This also makes it consistent with the "How are decisions made?" list which states the following:

If the change affects the governance, philosophy, goals, principles, or nature of the project, it must be approved by the Project Lead.

Re-reading every comment in this issue seems not as worthwhile as reviewing the current merge request, which I assume contains the combined proposal after consensus was built in the >80 comments on this issue.

So that's what I did.

While I'm very familiar with the Drupal core contribution process, I had actually never read https://git.drupalcode.org/project/governance/-/blob/main/drupal-core.md before. So I'm reading this with fresh eyes, which is both a blessing and a curse: some things may be not obvious to me that are obvious to everybody else here — apologies if so 😅

I am also probably (blissfully) unaware of what is a sensitive change, question or suggestion — again, apologies if so.

As somebody who's been contributing to Drupal core for over a decade, I'm trying to understand what the indirect impact on core contributors like me could be. I of course want the Drupal project to move faster, but I also want it to remain alive and well in the long run — for the next >20 years 😊

I've reviewed all textual changes, and asked a bunch of questions, and left suggestions to improve clarity (probably especially for people not familiar with this document already). I have not checked the RACI matrix yet, because I need those clarifications before I can properly review that.

IOW: I mean well, IDK what's sensitive, I might be asking silly and sensitive questions alike 😇

Adding intitiative leads has its own issue already, maybe we can try to do that first (as we did with the core committer one already) so it's less confusing in here #3389481: Adding inititative coordinators should not rely on Project Lead I think it's entirely uncontroversial and it would mean either less change here or less disconnect with the other changes.

In practice, it would not be easy for product managers to make a decision where all of the framework and release managers are against the decision. Many of our decision require commitment from all of the roles, and this is hard to achieve in a situation where everyone in those roles is against the decision. For this reason, this would not be effective, even if the governance technically allowed it.

I tried to think of an example where we ended up in this situation or close to it. I think the closest is #1741498: Add a responsive preview bar to Drupal core where webchick and @Dries nearly imposed a commit of responsive preview several times, despite objections from multiple other committers and core contributors.
e.g.

We have a BDFL, and sometimes his job is to D

#1741498-323: Add a responsive preview bar to Drupal core

Eventually that issue got postponed, but that was more due to the realisation that Drupal 8 wasn't in a releasable state, and the beginning of attempted 'feature freezes' than the discussion ever being resolved properly. You could say that the bad experience everyone had on this issue means it won't happen again, but part of learning from that would be reflecting these things in the docs.

The additional problem with that issue was that all of the people working on it as well as the committers who were talking about overruling everyone else worked for a single company which I don't need to name (and not as a coincidence which often happens, it was a company project). But that goes back to @larowlan's point in #83.

If we don't think this could happen again, then I don't think we need to build the possibility for it happening into the governance document, it can just talk about tie-breaking rather than overruling.

From Wim in "First: core committers each make decisions (they each "vote" if you will) based on the rules/gates/procedures. Second: that hopefully leads to consensus, and if so, we're done! Third: if not, then product managers get to decide. Fourth: if product managers' votes result in a tie, the Project Lead becomes involved, to break the tie. Was that the intent here?".

That is correct as it relates to product decisions, but maybe it is not clear enough in the text?

Re catch in #90: "In practice, it would not be easy for product managers to make a decision where all of the framework and release managers are against the decision. Many of our decision require commitment from all of the roles, and this is hard to achieve in a situation where everyone in those roles is against the decision. For this reason, this would not be effective, even if the governance technically allowed it."

For me, product management is all about encouraging pragmatic decision-making to accelerate innovation, rather than just resolving conflicts. This is a very important distinction.

In our current model, we often struggle with making effective trade-offs. Every role (e.g. framework manager, release manager, usability, accessibility, etc) strives towards the highest quality work. This is normal and admirable, but it also fosters a culture where we seek perfection at the expense of 'good enough'.

Today, every role is focused on finding all the flaws in a proposed merge request, and often demands that all the flaws are addressed. This has led to high quality and stable code, but also caused innovation and progress to be really slow. Contributors have grown really frustrated with that.

This is where empowering product managers comes in. A product manager can help decide when something is 'good enough'. A product manager making such a decision can provide some relief to the individual roles, who are naturally inclined to seek perfection in their domains.

For instance, a release manager or framework manager is tasked with delivering the most stable and high-quality release possible. Because that is their primary tasks, it's naturally hard for them to compromise on that.

A product manager deciding that something is 'good enough' can alleviate some of that pressure. In most organizations a product manager acts as a mediator, ensuring that the drive for quality is balanced with the need for innovation and progress -- always through the lens of the end-user. This prevents individuals from feeling as though they've failed in their roles simply because perfection was not achieved.

So rather than being focused on conflict resolution, we should view the role of product management as an opportunity to evolve our culture towards one that values and empowers making trade-offs. If we can embrace that and allow product managers to make trade-offs, we will see innovation accelerate. It's how most organizations work and not something we're inventing for Drupal.

I hope that is clear from the proposal. I hope you also agree with that. If not, we might need to discuss that more and/or evolve the text, assuming people agree.

maybe it is not clear enough in the text?

It was not clear to me at least 😇 Rephrasing would be very helpful to ensure every reader has the same understanding.

I hope that is clear from the proposal.

That definitely wasn't clear to me either. trade-off appears 26 times on this page. It appears 0 times in the document. I think that term should be explicitly present! 🤓

The changes in the document appear centered on which responsibility + power each role has, more so than the intended outcome. #92 describes the intended outcome much more clearly IMHO — I think this specific fragment from #92 could be added almost verbatim to the document (emphasis mine):

For instance, a release manager or framework manager is tasked with delivering the most stable and high-quality release possible. Because that is their primary tasks, it's naturally hard for them to compromise on that.

A product manager deciding that something is 'good enough' can alleviate some of that pressure. In most organizations a product manager acts as a mediator, ensuring that the drive for quality is balanced with the need for innovation and progress -- always through the lens of the end-user. This prevents individuals from feeling as though they've failed in their roles simply because perfection was not achieved.

So rather than being focused on conflict resolution, we should view the role of product management as an opportunity to evolve our culture towards one that values and empowers making trade-offs.

I especially like the underlined part, because that calls out the human/psychological/emotional component that I believe often slows down progress: each of us striving for perfection, and that sometimes not being achievable within reasonable timeframes.

I am adding a change to the RACI table for what I understand was wanted by Dries in #92.

Discussed this today with @Dries, @xjm, @quietone and @larowlan. We have agreed that Wim's feedback in #3367191-93: Speed up decision making: define the project lead as an arbitrator/tie breaker instead of ultimate decision maker will be addressed as a follow up task that @quietone will pursue.

The next step is for Dries to give it a final review and commit the change.

Additionally, @quietone will produce some wording about adding in a pre-planned review for decisions, where we once made we set a timeframe for a review of the impact of the change, if any. For example, we set a marker to review a decision after it has been in place for six months to assess how it is working and whether it requires any tweaks.

At the same meeting we also agreed to have a follow up to review this in 6 months after commit. I am adding a tag for that.

This came up during a Drupal CMS leadership meetings at DrupalCon Nara, which included five Core Committers.

We were all wondering if this had been committed, only to discover it was not. Ironic, and my oversight.

It may need a re-roll, but let's move forward and commit it. You have my approval.

I attempted to rebase it, but it was not trivial.
#3474813: Use Drupal Core Leadership Team terminology in governance changed too much of the formatting

I will work on the rebase

I completed the rebase and yes, it was difficult. When that was done I compared the results with the original diff to catch any mistakes.

The Product Manager section changed quite a bit recently and that was the most difficult. Since this MR was lasted worked on a new table of responsibilities was added which I added to and also removed items from this MR that are now in the table. All the decision making text from this MR is still here.

These additions are kept but I am not sure about them and I am tired. The first sentence is covered, in my mind, in the section introducing the leadership test. And maybe the latter sentence could be an item in the list of responsibilities.

They work closely with the Project Lead and Core Committers to ensure that Drupal meets the needs of our end users.

They set the requirements for features and decide when they're ready for release, taking into account their quality, ease of use, and how well they meet market needs.

I re-read the changes in the MR and the changes still make sense. I approved suggestions from Pam – they were all related to grammar and didn't change the content of the change in any way.