🇧🇪Belgium @Dries

Jean-Paul Vosmeer → credited Dries → .

pameeela → credited Dries → .

pameeela → credited Dries → .

pameeela → credited Dries → .

fubarhouse → credited Dries → .

pameeela → credited Dries → .

pameeela → credited Dries → .

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.

I'm also +1 on this proposal. It's a fantastic idea, and the proposal feels very robust.

I also agree with @quietone in #25 that the unaddressed points are non-blockers that can be worked out by the group itself.

Great job! Thank you for your efforts. I'd say: let's go ahead with it.

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

I'm comfortable with all changes but one. The change I'm not 100% comforatable with is the change to in the RACI changing from "Consulted, Accountable, Performed" to "Informed", and the double asterix at the bottom that says .

Per the proposed updates, part of my job is to be . 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.

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. It's important to me. For Core Committers, it changed to "Control, Accountable, Perform". Maybe that needs to be "Accountable, Perform" instead (up from nothing)? This means we'd have shared "Accountabiltiy", but I'd have the additional power to veto important changes I fundamentally don't agree with.

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" could mean different things to different people. Also, depending on the specific change, the RACI could be different. I certainly don't want to sign off on any change. 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 → , for example.

pameeela → credited Dries → .

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 as well (#52). However, the opinions of the rest of the team are not as clear.
• At the same time, 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.

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 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 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 the release management, framework management, and the security teams -- 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 use can adapt the 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 maintain efficiency, foster strong teamwork, and rapidly generate innovative ideas.

Essentially, this is a pretty standard definition of the role of a product manager, just adapted to Drupal's context. It bridges the industry-wide understanding of a product manager's role with some specific application for 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.

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.

Re #54: 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 📌 Make longwave a full committer Fixed , 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?

Re #59: I've approved issue 📌 Make longwave a full committer Fixed . 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 📌 Make longwave a full committer Fixed and am fine with deciding them through consensus. However, I don’t support using a consensus-based approach for everything. Drupal needs a decision-making system that’s effective at managing difficult trade-offs.

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.

A big +1 from me. Well deserved, @longwave!

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.

xjm → credited Dries → .

Making things easier is good and much needed. And DDEV is great. So I'd fully support it.

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. "

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. 🤔

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

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.

pameeela → credited Dries → .

This looks great to me! Thank you for working on this. This can be merged.

You make a good point about the difference between the Community Working Group (CWG) and the Core Committer proposal.

I see them operating at two different levels. The CWG's main focus is to uphold the Drupal Code of Conduct (CoC), while the Core Committer proposal in this issue aims to give the Core Committer Team more control in creating an effective team.

The proposal in this issue allows the Core Committer Team to have more say in how they manage themselves. They could remove members for various reasons, not just for violating the CoC. These reasons include things like not sharing the team's vision, causing negative dynamics within the team, personal conflicts between team members, and more. These example reasons are outside of the CWG's scope as they are not violations of the CoC.

I also believe that the CWG holds a higher authority than the Core Committer team for issues that are in their scope. So, if the CWG removes someone from the Drupal community for Code of Conduct violations, the Core Committer team would follow their decision and also remove that person from the Core Committer or Core Contributor Team.

While it might be easier to introduce a separate evaluation process for all this, many non-profit organizations usually include this evaluation as part of the term renewal process. It's common to bundle them.

However, as I wrote before, I'm open-minded about this. I mainly wanted to respond to your comment and explain how I see the relationship between the CWG and the Core Committer Team. I'd would love to hear what others have to say on the matter as well.

Thanks for that feedback. The two proposals are quite different in complexity, but also in scope:

• The initial proposal covers (1) renewals and forced departures, focusing on (2) choices made by both the individual and the team.
• The alternative in comment #5 solves for (1) renewals only and (2) only considers the individual's decision.

When we think about self-governance, it's important to have the option to renew or extend terms, but it can also be important to be able to move out people, if needed.

Imagine there is a Core Committer who creates issues, doesn't collaborate effectively, or doesn't align with the project's current needs. Now, when it's time to renew their term, many team members might not want them to renew. With the proposal in comment #5, that person can decide to stay even if others are worried about it.

I agree that my proposal does add some complexity and demands more time and effort. However, this added complexity also helps mature our governance model, and moves us closer to self-governance.

Perhaps it would have been better to start by asking: what do we want to solve for? Is addressing forced departures and improving team dynamics something we want to build into our process at this point in time? I'd be ok with reducing the scope, if that is what the team prefers.

So far people seem to like this idea of renewable terms, including myself. However, we haven't yet figured out how to actually renew these terms and that is an important part of the discussion.

I've been thinking about finding a democratic approach to handle term renewals, and specifically for the Core Committers. A democratic approach has pros and cons, hence it's an important part of the overall proposal to consider.

Because the mechanics of such a renewal process can be complex, I created a child-issue for it at #3374499: How to renew Core Committer terms → .

So far people seem to like this idea of renewable terms, including myself. However, we haven't yet figured out how to actually renew these terms and that is an important part of the discussion.

I've been thinking about finding a democratic approach to handle term renewals, and specifically for the Core Committers. A democratic approach has pros and cons, hence it's an important part of the overall proposal to consider.

Because the mechanics of such a renewal process can be complex, I created a child-issue for it at #3374499: Renewing Core Committer terms → .

Dries → created an issue.

I'm also in favor of incorporating a system that enables smooth sabbaticals. Here is a first proposal to flush out that idea a bit more:

1. Sabbaticals can be taken between two terms, lasting up to 9 months.
2. Alternatively, individuals can take sabbaticals during a 2-year term, with a maximum duration of 9 months. To eliminate administration and avoid tracking or calculating term expiration dates, a sabbatical does not extend the term limit.

We could consider extending it to 12 months. After a certain period, it may be more appropriate to re-apply. To me, 9 months seems reasonable, but I'm very much open to suggestions on that!

Gábor Hojtsy → credited Dries → .

Added another related issue 📌 Remove trailing slashes on void elements Closed: duplicate .

I reviewed this change and it looks good! I'm +1 on committing this. Thank you for helping with this, Gabor!

I fully support the proposal to make poker10 a Drupal 7 maintainer. They have been a dedicated and consistent contributor to the Drupal project for many years. Please proceed with making this change. Thank you, poker10, for all your valuable contributions.

nicxvan → credited Dries → .

That looks good to me. Thank you!

In general, I'm a big fan of introducing terms.

I also think it is a great idea to try and stagger terms. Based on experience with other teams, the staggering can be difficult to accomplish in practice. That is ok though; it doesn't have to be perfect.

I'm ok with the proposed term lengths. They seem sensible, and they can be easily adjusted latter.

Term limits is something worth discussing, later. If you are not familiar: term limits force people to take a break after x terms. Usually, people are forced to take a 1-term break, before they can rejoin the team. In this model, managing backfills and continuity becomes be really hard, but it is also very healthy. It forces you to build a pipeline of viable candidates, it encourages succession planning, it discourages 'single points of failure', and it forces people to take a break.

I don't recommend we introduce term limits at this point. I like the simplicity and continuity of the current proposal. It puts us on a good path forward, with the flexibility to make adjustments later.

My main concern is that not many core committers / maintainers have chimed in on this issue. At a minimum, I recommend we discuss this some more within the core committer team. I'd like to see some more +1s before finalizing this proposal.

I'm +1 on this. It's a good idea to formalize both roles and I'm on board with the proposed write-ups.

Side note: I agree that initiative facilitators and committer facilitators would collaborate on the agenda of a meeting. In the end, it is the "strategic owner" that should have the final say on the agenda of a meeting; e.g. the committers would have the final say on the agenda rather than the facilitators. To me, this is implied. We work well together, so I don't believe this has ever been a problem in practice. I'm really not worried about it, but we could certainly clarify it with an extra sentence, if people feel strongly about it.

I'm +1 on this patch and removing some of the language.

Let's complete #3327844: Convert governance docs to markdown, redirect d.o page to Gitlab UI as canonical version → before committing this.

Thank you, @jhodgdon.

Let's go with Markdown in Gitlab. Good suggestion, @drumm.

Markdown seems easiest as the documents have been converted already, it maintains the governance, and it unblocks the migration work.

The only downside is that non-technical users could be confused by all the Gitlab related navigation and nomenclature that will surround the documents. I don't believe that to be a deal-breaker.

A special thank you to @quietone for converting the documents! I appreciate the help.

I was finally able to look at this!

First of all, thank you for preparing an application.

After review, I only see upside to submitting our application, and no downside. In fact, this sounds exciting to be part of!

I reached out to Tim Lehnen and Tim Doyle from the Drupal Association in email to coordinate how to submit the application.

Thank you, again!

Great to see we are getting closer to a solution.

In addition to improving the queries, it might not be a bad idea to show a warning on /admin/reports/status when there are entities with more than $number revisions. At a minimum, we should inform a site administrator about this.

As a next step, I would not be opposed to a new feature in core to prune revision after $number days/weeks/months/year/never. We should tackle that in a separate issue though.

Rolled back. Let's figure out a proper solution.

catch, you mention a performance problem but you didn't provide any details. Care to shed some light on this? How bad is it?