meta: ctc-agenda label is misused according to the Project Governance

[ChALkeR]

After #9072 landed in October, it (strictly speaking) removed the possiblity to bring things up to the CTC agenda without a prior failure though the consensus-seeking process.

Before:

Any community member or contributor can ask that something be added to member or contributor can ask that something be reviewed the next meeting's agenda by logging a GitHub issue. Any Collaborator, CTC member, or the moderator can add the item to the agenda by adding issue to the CTC's attention by applying the the ctc-agenda tag to the issue.

After:

Any community member or contributor can ask that something be reviewed by the CTC by logging a GitHub issue. Any Collaborator, CTC member, or the meeting chair can bring the issue to the CTC's attention by applying the ctc-review label. If consensus-seeking among CTC members fails for a particular issue, it may be added to the CTC meeting agenda by adding the ctc-agenda label.

This (strictly speaking) blocks mentioning some issues on the ctc-agenda for other reasons, like making sure that more CTC members are aware of some change, like I tried to do in #11304 (comment) (I had to remove the label), or like bringing more attention to the issue and providing some information at the meeting to speed up the ctc-review process.

More examples of issues/prs that should not have received the ctc-agenda label (at least at the time they were labeled) per the Project Governance: #10599 #10155 #10187 #10116 #10792 #10505 (hover to get a description). There may be more.

Yes, I'm being boring, but I think that such written rules might stop other members from bringing things up to the ctc-agenda and that we should follow our own rules.

The easy way would be to patch the GOVERNANCE.md document, allowing bringing up issues to the CTC meeting agenda without a previous failure of a consensus-seeking process. If that is not something we want, we should better follow the process and escalate to the agenda only the issues that failed the conensus-seeking process, but I believe that will slow things down at some places without significant benefits.

/cc @nodejs/ctc

[Trott]

I interpret can in the doc the way may is defined in RFC 2119 and not like should or must is defined there. In that interpretation, other uses of ctc-agenda are not precluded.

Perhaps we should reword that passage to stick to those well-defined terms (may, should, must) and eliminate the perhaps-ambiguous can?

[Trott]

(As the author of #9072, I can certainly say that my intention was to discourage bypassing asynchronous processes, but not to forbid it.)

[Trott]

Oh, I see now that one straightforward interpretation of what's written is that if ctc-review is not applied first, then it's not proper to apply ctc-agenda.

Yeah, in practice, that's not what we do (although it would be great if we could try to do that most of the time). The text should probably be modified to reflect actual practice.

I'd also add that ctc-review usage is not as described in the doc. The purpose of ctc-review was not supposed to be "hey, CTC, take a look at this!" We already had @-mentions to take care of that. The purpose of ctc-review was "We need to make a decision on this. If you have concerns, say so, because consensus will be assumed if a couple CTC people give this their approval." The idea was to default to asynchronous decision-making and only use the meeting when needed. Unfortunately, perhaps partially because the name ctc-review might be misleading, it is almost never used as intended. Not sure there's much to do there other than update the doc to reflect practice. :-(

[gibfahn]

@Trott

The purpose of ctc-review was not supposed to be "hey, CTC, take a look at this!" We already had @-mentions to take care of that.

The purpose of ctc-review was "We need to make a decision on this. If you have concerns, say so, because consensus will be assumed if a couple CTC people give this their approval."

I'm unclear on the difference here. I thought ctc-review was for an actual vote, and @nodejs/ctc was just for saying If you have concerns, say so, because consensus will be assumed if a couple CTC people give this their approval.

[Trott]

@gibfahn I was wrong to say that it is "not as described in the doc". The details were left out of the doc, probably by design. The ctc-review label was originally created to label issues where consensus was being sought. Consensus consisted of at least 2 CTC members advocating for something and no CTC members opposing it. The issue was to be left labeled like that for at least 72 hours before deciding that there had been adequate time for folks to offer their views.

In practice, it has become as you described. And furthermore, that seems consistent with the doc. (So my belly-aching about it is unjustified!)

[Trott]

I think we're all good on this now. @ChALkeR Please re-open if you disagree.