TSC governance consensus process and timings

[Relequestual]

In relation to #286 (comment) - Charter section 4.2, Decision-making.

I feel like the consensus model put forward is a fair and helpful balance provided by quorum requirements and staged progression.

The article that prompted the stages for consensus assumes people are discussing things in real time (or at least, so seems to me).

I was thinking, should/how can we put time limits on the standard consensus process?

Napkin thoughts: if each stage was required to be open for 7 days, it would take 7 weeks to confirm standard decisions.
That seemed a bit too long to me, so I've asked a few people for their thoughts and advice, I'm going to try to summarise the key points of discussion and comments which have me thinking. (For context, here's the article which made me believe that quarum as opposed to unanity is better and fairier).

Why 7 days between each stage? After discussing with some of the very likely people to be part of the TSC, for the VOTING part of decision making, I concluded 7 days minimum, plus optional 7 days on request, would meet our current requirements, and was reasonable given not everyone can do the work in working hours. I suposed a similair time frame might work well for each stage of the consensus process. After discussing with others, I think. that suposition is wrong. Here's how the thiking went.

Firstly, I had feedback and thoughs from @mwadams asked multile important questions. He also pointed out we should have a process for urgent decisions, which I had already included, but now in more detail in the draft PR content).

Is 7 weeks actually too long?
Reflecting on other important decisions, one of our most important decisions, to self publish future specifications as opposed to continue to publish on the IETF, took us over a year to discuss on and off, and finaliase. Could we have done that in 7 weeks? Feels unlikely. But, maybe if we had subscribed and committed to a timescale, it might have been possible. So, 7 weeks feels like it could be a short enough minimum. However, I'm also think it's going to be too long for much less important and smaller decisions.

Is urgency a priority? Is consistency a priority?
I would say, no. Not at this time. To both questions. IMHO that's just fine.

Should the whole group be shaped by the constraints of its most constrained?
Maybe?

What happens if someone joins the team but availability means that decisions will now take 12 weeks not 7 because our policy is to maximally accommodate the least available member of the group?
errrrm...

Would it be better to allow a qurate group (a group that has quarum) negotiate on time in a particular stage or date to accomodate those interested in a specific issue, with a sensible maximum constraint rather than slowing the whole train down all the time?
Well... yeah that does sound preferable now you mention it.
Slowing the train down all the time feels like a bad idea, so avoiding that should be good!

I had some further thoughts from @Julian...

...my initial reaction is I'm never personally a fan of hard-coding a strict timeframe for every decision. Other places I interact with both professionally (historically) and also in the open source world don't work that way (mostly I'm thinking about Python as a language, but also large open source projects like Twisted or PyPy that I've contributed to).

Hum. OK. So we have evidence that it's possible to function without applying a timeframe requirement to decision making.

[TSC decisions] should involve directly pinging the people on it, and they need to get together and make a call.
Yup, totally agree. I already think we HAVE to make sure all TSC members are pingged in some way when there are new discussions are posted.

Julian links to PEP-0013 - Python Language Governance, quoting...

Every council member must either vote or explicitly abstain. Members with conflicts of interest on a particular vote must abstain. Passing requires a strict majority of non-abstaining council members.

Would it be reasonable to make a clear expectation that all TSC members must respond in some way? Maybe.
If we did, what would we do if a TSC member did not? Remove them from the TSC? Probably yes.
How long would they have to respond? 7 days?
(As far as I can tell, PEP 13 doesn't specify this? I guess if someone consistently doesn't "show up", someone else would motion to remove them and elect someone else.)

Are we then back to square 1? Well, it would be a 7 day maximum to respond it some way, as opposed to just waiting 7 days minimum.

For those of us who are privilidged enough to be paid to work on JSON Schema, such a requirement would not be problematic.

Critically, I feel we need to hear from @karenetheridge and @awwright to see what they feel would be reasonable expectations. I know time is precious, and I know @awwright sometimes is unavailable for chunks of time at times.

I'd very much also welcome any additional thoughts, and any other experienced working models which have expectations or commitments in terms of at least making commnets of some kind by a specific time.

[kinlane]

I like the idea of known structure, scaffolding, and agreed upon forward motion. I agree that you can do things without timeframes, but the wider the pool of people, the more difficult it will be to get everyone moving forward without well understood and agreed upon timelines. I feel like a couple things could be considered to alleviate friction in several directions:

• Expedite - If something is simple enough and there is urgency, have a process for proposing a shorter timeline -- that is if you can get the consensus to do so, which would add another layer of complexity, but if someone feels strong enough they could lobby members make sure they have the votes.
• Broad Abstain - Everyone member has agreed to be available and present. If there is a week or weeks that they'll be unavailable they put themselves into away mode which signals ahead they abstain, setting the tone. Otherwise you agree to be responsive on daily basis -- and you are committed.

I like having a regular cadence I can get in the rhythm with personally. I think the rhythm helps get everyone dancing to the same tune. Of course people can sit out, go get a drink from the bar, and step away. If you make the commitment to be part of the dance, be present, be available and communicate, otherwise it becomes an opportunity for imbalance.

Just my thoughts....will simmer on it more.

[Relequestual]

Thanks for your feedback on this. I'm very much looking for data so we can be pragmatic about this where possible.

I have defined a "quick consensus" model: https://github.com/json-schema-org/community/pull/325/files#diff-91d16dd057bd39f6431e90a1d78e9224eafafcedc611eba0878d77e6fda86601R106-R112
Partially based on https://seedsforchange.org.uk/quickconsensus

[benjagm]

I went through the proposal and looks great for me. A 7 days period is aligned with other projects like argo: https://github.com/argoproj/argoproj/blob/669d57c6c9db2a4688f99c912b7c6fdb05dd2b62/community/GOVERNANCE.md

I do like the quick consensus process for trivial issues.

[Relequestual]

In conclusion of this discussion, I have amended my proposed charter to include some time limits:
Relequestual@dc3785a