Document how the core committers reach agreement

@xjm commented in the other issue that "Our current practice since Gábor was added is full consensus, not a majority.'

That is what I have experienced as a core committer and would prefer to continue that practice. Perhaps we can just add a sentence to "How are decisions made", maybe a new point #2. Something like, "The core committers use consensus decision making. to reach a decision'.

We had a short meeting about this at DrupalCon Lille. We did not discuss in any depth about when there's persistent disagreement on an issue due to time constraints. However, we did come up with a proposal for how to decide that the committers agree on something once the people actively discussing it have otherwise reached consensus. This is designed for 'policy, no patch' or governance issues mostly. These should be the easy ones, but they often get stalled for months after they reach this point, due to the lack of a process for marking them fixed.

We didn't come up with the wording for the actual issue summary, but it was my job to document the discussion, and then try this issue as a test case for the new policy itself (insert recursion joke here).

The very short version is 'post an RTBC issue in committer slack, this starts a two week timer, if there are no blocking objections, mark it fixed in two weeks. Any core committer can raise serious objections or ask for a delay to give them time to provide more feedback, this would put the issue back in 'needs review' or 'needs work' and then the process would start again next time it's RTBC.

@quietone in committer slack mentioned the monthly Drupal core meeting, that was after the discussion I think (or at least I saw it afterwards). While I think the monthly meeting is a good place to bring these issues up, if we said they can only be brought up at the meeting, that would make the maximum window six weeks for a decision rather than two weeks - i.e. if we reached consensus immediately after a meeting slot and then waited until the next issue to post it. So for now I've not included that in the issue summary, but we could definitely try to pick issues that are close during that meeting, mark them RTBC, and then start the timer from there, i.e. use the meeting to get issues into this state.

We very briefly described a short circuit in the case that we know an issue has unanimous support, so that we don't artificially have to wait two weeks on those issues. We didn't come up with something for 'urgent, non-controversial issues' in the case we have unanimous agreement but one committer is unavailable who we think would probably be fine with the decision, that might need a bit more discussion.

We didn't discuss this bit at the meeting, but I personally don't think we should put this explicit mechanism in the governance, instead I think we should try to use it for issues (including this one), and we can tweak the timeline and feedback mechanisms if needed without having to start an entirely new governance issue each time. So for this case this issue itself would be the documentation of what 'the core committers must agree' is. We could add more explicit documentation later in a separate issue once it's being used successfully.

Moving directly to RTBC so we can try this out :)

I hope it helps. I have created an MR with the suggestion from #4.

I suggest that a new guide or page in the Core committer handbook → can be used to document the mechanism or mechanisms used.

Just to clarify my remark advocating full consensus, I was referring to the appointment, removal, or promotion of core committers, which I feel deserves separate process than governance or policy decisions that affect the whole team. We can always alter a policy if something doesn't work out, but altering the team itself has longer term impacts, and should be handled privately and require full consensus.

I am +1 on RTBC governance improvements and policy issues being adopted via the process documented above.

Policy issues can also include patches, so just removing the "no patch" part from the IS. Also moving @here because inevitably someone is asleep and excluded by that depending on which continent the person who @heres is on. I think sometimes we can ping people individually to give them a last chance if it's an issue that significantly affects their role or where they'd raised previous concerns that were hopefully (but not confirmed to be) expressed.

Thanks for the MR. I found two things that seem to have gotten weird somehow in the recent updates, so more followups.

Should the detailed process from the IS be documented in the committer handbook as a policy, or added to the governance as a new section?

I was thinking about this proposal today, the potential page in the Committer Handbook and plain English.

I suggest we use the term 'confirmation period' instead of 14-day timer/window/period. And then I started modifying the text to plain English. And then I can up with this.

When a governance or policy issue reaches consensus, the Issue Summary is updated with the proposal and the issue is set to "RTBC".

In committer Slack, the issue is announced in the dedicated 'decisions' channel for confirmation.

The announcement starts a 14-day confirmation period. The person posting the announcement should set a Slack reminder for the end of the confirmation period.

The confirmation period can be extended at the request of any committer. This allows for people who are not available during the confirmation window. As well as if anyone wants to think more about the issue or have an as-yet-undocumented objection. In this case, it's up to that person to follow up when they're available. If they do not respond after the extension, the timer is restarted.

During the confirmation period;

• non-blocking changes such as wording changes or other small changes that align with the already built consensus can be made. The Issue Summary is updated accordingly.
• If a blocking comment is made, the issue is set to "Needs review" or "Needs work" as needed.

If there is explicit, unanimous support for the issue, the confirmation period is terminated, and the issue is set to "Fixed".

After the confirmation period, if there is nothing blocking the proposal, the issue is set to "Fixed".

#12 looks like a good change to me.

So much easier to review now. Looks perfect. #12 also looks good, but still should probably get its own issue?

I think this looks good (with the #12 process documented in a handbook page) as long as its used for the day to day processes of Drupal core committers. As soon as it may be used to change the governance process itself (such as after #3367191: Speed up decision making: define the project lead as an arbitrator/tie breaker instead of ultimate decision maker → ), I don't think its fair to document how its done outside of the governance, that would make the handbook a "higher order law" than the governance doc IMHO. It would make it non-transparent that changes may happen to how the governance may be changed, while we aim to make the governance changes themselves transparent.

Whether the text needs changes thus IMHO depends on what's the answer to what we apply it to. So far @xjm and @quietone indicated they propose to apply it to governance changes in the future, feedback from others would be welcome. Also please let me know if I don't make sense :)

The problem for me with documenting the specific 'reach consensus on an issue, post it in slack, it's fixed if no objections after 14 days' is that it's not the only way we might reach a decision. For example this issue was originally decided at the core committer offsite in person where there were no objections at all, would we make ourselves post it in slack and all thumbs up emoji it just to follow the governance process?

I think it's better to have flexible governance than governance which you constantly have to bend or break to get anything done, which is why we're all here on this issue in the first place.

Could we do something like 'Mechanisms for decision making will be decided internally by the core committer team and will be documented in the handbook'? I'd also be OK with a 'and may include foo and bar'.

The existing decision matrix defines what the core committer have control over and what they do not. According to the matrix, the core committers have no control for "Any impact on project governance". The areas of control are, "A single subsytem", "Multiple subsystems", "A topic area", and An official initiative". That matrix is not changed in this issue.

Since the matrix is not changed in this issue, the change applies to the currently defined 'allowed' decisions, which is not governance, Therefore, I think the concerns in #15 can be better addresses in another issue.

If core committers have no say in governance, then how can we say they "use consensus decision-making for policy and governance issues"?

@Gábor Hojtsy, thanks for pointing this out.

Since a suggestion has not been made I am removing the 'when' part so the that change just says that the committers use consensus. This should now simply be describing what the committers actually do.

Gábor Hojtsy and I have been trying to get together to discuss this for a while and we finally managed that last week. Then I got sick and have not been able to follow up on this.

We had a lovely conversation which was very helpful. For me, it does happen that hearing someone is easier to understand than reading their words. However, it has not changed my personal opinion on the need to add the process to the governance doc. What I did come to realize is that adding it to the governance doc is worth a try. Like all things, it can be changed if it is not working. We agreed that I would update the MR.

Therefor, the implementation details from are in a new document, confirm-consensus.md. Then, since there are now two documents about core, the new document and drupal-code.md are moved to a new directory, 'core'. Moving drupal-code.md caused a change to a link in README.md

#18. Trying to address this by removing all references to governance.

This is now simply adds documentation for the 2 week Slack method.

Is this sufficient?

Just updating the title to note that this process applies to decisions about *core policy* and not technical decisions.

Latest version looks good to me now - let's get this change in and continue in other issues. We've been using this for some things and it seems to work.

Moving to RTBC.

I reviewed the originating issue and updated the issue summary in an attempt to clarify the purpose/goal of this issue.

I'm +1 on this change, and tried to merge it. Unfortunately, I ran into an error, and also ran out of time.

It looked like the patch was slightly outdated:

$ patch -p1 --dry-run < 15.diff
checking file README.md
checking file core/confirm-consensus.md
checking file core/drupal-core.md (renamed from drupal-core.md)
Hunk #1 succeeded at 60 (offset 2 lines).

I tried rebasing it, which seems to have fixed it, by leaving a comment with the string /rebase in the MR:

2. If the changes in the "x commits behind" do not conflict with anything in the MR then you can rebase via the UI. There is no 'rebase' button, but just enter a comment with the single word /rebase including the leading / and this will trigger a rebase.

From Rebase a merge request → .

Thank you! I was able to merge it now. Appreciate the help.

You're welcome! I am glad I could help.

Automatically closed - issue fixed for 2 weeks with no activity.