Define our "bar" for new extensions

[duglin]

First pass at trying to define our "bar" for new extensions.

Signed-off-by: Doug Davis dug@us.ibm.com

[duglin]

ping @inlined - what do you think?

[clemensv]

Sounds good. That ensures an extension isn't entirely someone's solo adventure. LGTM

[rperelma]

We are using two interested parties here as the bar, whereas in 298 we are using three. I don't feel too strongly, but three seems maybe better?

[duglin]

my initial thought was that adding a new "normative" spec should have a higher bar than a non-normative extension. But if the group wants the consistency then I'm ok changing it.

[erikerikson]

Sorry to troll a little but what happens if N projects define and use foo with semantics A and N other projects use foo with semantics B? Do we keep track of usage/scoping? I could see it being useful to do so.

This seems possibly an additive concern for a future PR.

[erikerikson]

Thought exercise: does the sequence attribute and associated sequenceType meet this bar? Does it have:

interest, and intended implementations, from at least two independent projects.

If so, I'm not aware of either and I haven't seen mention of those in the PR. Regardless, it meets the condition of having an important potential role in facilitating a predominant strategy for maintaining distributed system correctness and an increase in use would be positive from my perspective. As such I find myself not valuing this particular element of the bar's definition.

A last point.... This could also apply to the language about protocols to accept. By establishing conditions does the agency of the voting membership get reduced? Must we accept some extension given the trivially but not meaningfully satisfaction of our conditions? More shortly... Are the votes of members not primal? I would hope instead that this would help those interested in potentially submitting additions decide about the plausibility and preconditions up their acceptance by the group. I may well be missing existing statements in the governing documents, apologies if so.

[duglin]

Sorry to troll a little but what happens if N projects define and use foo with semantics A and N other projects use foo with semantics B? Do we keep track of usage/scoping? I could see it being useful to do so.

This is only an issue when/if they choose to bring their extensions to our group. Then it becomes a little bit of "first come, first served". If the 2nd one comes along and can't be merged into the existing extension then they're still able to propose theirs but I would think we'd ask one of them to do a rename so there's no conflict - probably the 2nd one. I'm a bit nervous about saying too much here since this isn't really meant to be too formal - its more like a playground to me, just with a skinny bouncer at the door. 😄 If people really want to add text around this, I'm open to suggestions, it does seem like it could be done in a follow-on PR as @erikerikson suggested - thus unblocking the other work.

[duglin]

@erikerikson to your 2nd comment... good questions. I added the notion of 2 interested parties because I assumed (based on the protocol "bar" discussions) people wanted our criteria to be more concrete and less subjective. If we left it as something like "important potential role in facilitating a predominant strategy for maintaining distributed system correctness and an increase in use" then I feel like we have a "gut-feeling" measuring stick. Which, TBH, I'm not totally against for something I view as a playground but it does make the possibility of gaming the system a bit higher - but something maybe we just risk. What do other's think?

[duglin]

Changed per today's call to say that extensions require at least 2 voting members to voice their support for its inclusion.

Comments based on today's call:

• we're looking to keep the bar fairly low since these are just extensions, but also try to minimize game playing or being forced to adopt something that the group may not want to accept
• as with any of the governance rules of the project, they are subject to change over time as the group sees fit
• we decided to allow the author of the PR to also be one of the supporting members (if they're voting members) because 1) originating the idea should not penalize them from voting, and 2) if we didn't, people could get around it easily by finding a proxy to submit the PR for them - again we're trying to avoid some game playing

[duglin]

All, please look this one over before the call. I'd like to see if we can get an initial pass at our "bar" done so we can unblock other work. Keep in mind, we can always wordsmith/tweak things later as needed.

[rperelma]

LGTM

[duglin]

Approved on the 9/27 call