process: specify lazy consensus

[jacoscaz]

This PR build upon and depends on #48 , which in turns depends on #47 . However, while those two are aimed solely at making our process explicit without changing it in any way, this PR is an attempt at specifying and narrowing our use of lazy consensus while keeping process light and approachable.

Contrary to its two dependencies, therefore, this PR is a proposal for a slightly more articulated process and should be reviewed with a more critical eye.

[webr3]

You need it, or better, but looks hard to manage - perhaps something like https://www.gitconsensus.com/ or similar could be introduced?

[jacoscaz]

You need it, or better, but looks hard to manage - perhaps something like https://www.gitconsensus.com/ or similar could be introduced?

@webr3 I appreciate the suggestion but I happen to detest reactions. Which doesn't mean the group should stop using them, I'm very aware of being the odd one out in this case. However, I'm not going to adopt a process that is based on reactions. Particularly in this group but also in many others, there's a lot of examples of participants contradicting their own reactions within the span of a few comments. I'm also quite wary of automating group dynamics, particularly where consensus needs to be built. I'm aware this means putting more work on the chair; to me, that's a worthy tradeoff.

[webr3]

Lol, fair enough and commendable. Consider me +1 for whatever you see fit, you being unblocked to facilitate the group is my priority 1 here

[melvincarvalho]

Generally with github reactions you can show approval with an upvote. And disapproval with a downvote. I normally think if you disapprove, you should leave a note as to what you disagree with.

[jacoscaz]

Generally with github reactions you can show approval with an upvote. And disapproval with a downvote. I normally think if you disapprove, you should leave a note as to what you disagree with.

That's good etiquette indeed, @melvincarvalho , but personally I find that reactions facilitate giving in into the kind of knee-jerk feedback that doesn't help me locate consensus. They flatten the discussion onto a binary, discrete choice while I find that most value tends to be somewhere on the spectrum. I recognize this is totally personal and subjective!

[jacoscaz]

Tagging a few active participants to make sure this is on their radar; as always, no pressure meant. If / when you get around to this, also have a look at the two PRs that this one builds upon.

@namedgraph @acoburn @woutermont @kidehen @jonassmedegaard @TallTed

[jacoscaz]

Feedback anyone? Also see https://github.com/w3c/WebID/discussions/50 .

[woutermont]

Sorry for reviewing this so late. I feel the document as a whole has a good vibe, but it really misses some concrete instantiation of the described process, e.g.:

• How do we/you raise awareness on new issues? This is one of the most important aspects of lazy consensus. Manually tagging a handful of people is very arbitrary and quickly misses out some less active participants. Typical practices are (bi)weekly meetings, or at least a (bi)weekly overview of current issues/PRs via the mailing list.

• How long should we/you wait before taking lack of dissent as consent? It is best to have this specified somewhere, again not to handle arbitrarily. We specify both a shorter term and a longer one, and pick one depending on the importance of the decision.

• Where are decisions tracked; and importantly: where is any remaining disagreement with the decisions tracked? PRs only go so far, and are not easily archived. When a group holds meetings, the minutes typically suffice for this, but as long as we don't, I suggest at least keeping track of decisions and disagreements in a separate document.

[jacoscaz]

/chair hat on and off

Sorry for reviewing this so late.

@woutermont not late at all!

• How do we/you raise awareness on new issues? [...] Typical practices are (bi)weekly meetings, or at least a (bi)weekly overview of current issues/PRs via the mailing list.

Weekly overviews of current issues and PRs via the mailing list sounds pretty good to me. I also like the idea of meeting every once in a while, though I believe we wouldn't be able to hold meetings as frequently as needed in order to make good progress. IMHO, whereas (bi)weekly meetings would be somewhat unrealistic, I think I would be able to write weekly overviews.

• How long should we/you wait before taking lack of dissent as consent? It is best to have this specified somewhere, again not to handle arbitrarily. We specify both a shorter term and a longer one, and pick one depending on the importance of the decision.

I also thought about this, which was also suggested by @TallTed . I can't remember where I've seen it but I recently stumbled into a group using 2 weeks for the shorter term (for smaller changes) and 4 weeks for the longer term (more significant changes). Assuming a weekly review on my part as per the above, that seems adequate to me. Thoughts?

I suggest at least keeping track of decisions and disagreements in a separate document.

Definitely. Chair's notes or something like that.

[jacoscaz]

@woutermont done! If you review this it'll make it easier for me to ask for a new review should others suggest further changes.

[woutermont]

Good additions!

Just one more thought: if we follow lazy consensus, it's a bit strange to require some portion of the active members to have provided feedback before merging. After all, no reaction within the given time span can be seen as consent. Moreover, when at some point the number of active participants is higher, that would raise the bar for 'enough feedback'.

[webr3]

+1 to everything, especially @woutermont last point about requiring feedback

[jacoscaz]

if we follow lazy consensus, it's a bit strange to require some portion of the active members to have provided feedback before merging

@woutermont @webr3 yeah but, on the flip side, not having any limit would technically mean that a PR could be merged simply because it exists at all... Which might be a case of overthinking on my part. I'll drop that. Thanks for the feedback!

[woutermont]

not having any limit would technically mean that a PR could be merged simply because it exists at all...

Yes and no: it will be merged if it exists under the conditions of lazy consensus as set forth in the document: 2-4w open, after having been declared for all participants on the mailing list, and not having received negative feedback.

[jacoscaz]

it will be merged if it exists under the conditions of lazy consensus as set forth in the document

Yeah, precisely. There's an edge case in there that makes it possible for a PR to be merged without review. But it's statistically so, so, so, so, so unlikely that even merely thinking of it qualifies as worrying too much. Chalk it up to inexperience :)

[webr3]

3 seems like a nice number, and should be easy to achieve - in either direction, 3 approve + silence for merge, or 3 dissent + ongoing convo for block?

[jacoscaz]

3 seems like a nice number, and should be easy to achieve - in either direction, 3 approve + silence for merge, or 3 dissent + ongoing convo for block?

@webr3 I already dropped that constraint as per your and @woutermont 's feedback, no more numbers.

[jacoscaz]

/chair hat on

Given that this PR:

• has been well received so far
• specifies our use of lazy consensus but doesn't deviate from it nor introduce any significant exception

Barring major objections I'm going to merge it tomorrow to start the week with our process in place and the first chair notes.