Lightweight governance process for onboarding new specifications

[John Clingan]

We chatted last week at the Live Hangout that it may be time to formalize how we add new specifications to MicroProfile. I signed up to start the discussion, so here we go!

To date the process is basically any team of individuals can collaborate on a new spec/TCK, can target a MicroProfile release, and it becomes a formal spec.. There is basically no formal gate, although I suspect folks will speak up and start a discussion if a proposed spec is deemed either not ready or inappropriate (nothing to do with a microservices platform, for example). As MicroProfile grows in popularity and adoption, it's time to consider a more formal process. I'll start the discussion with a proposal that we can iterate on, or others can put up their own proposal, which is all goodness too.

My proposal is to have two discussion threads on a new proposed spec. The first thread is voting only. +1, -1, and some ratio threshold means approval (2/3? 3/4?). The voting thread is open for a period of time (two weeks?). The second  thread is intended to be a discussion thread on the vote. No discussions in the voting thread and no changing votes (to make vote tabulation easier).

Why MicroProfile google group threads? I'd like to constrain the vote to MicroProfile community members and not leave it open to the world to vote. Currently we more-or-less define our community that as those subscribed to the google group. We have > 1000 members. The concern I have about opening voting to the world is from those that do not have "skin in the game" voting "+1". It's not out of bad intent, simply out of casual "yeah, good idea" votes without realizing the commitment it takes to deliver implementations. Creating a new specification means that MicroProfile implementations (vendors, community implementations) have to implement them to be "MicroProfile X.Y compatible".

I think this is a good start to the discussion. I do have a concern that casual group members will vote without fully understanding the long-term ramifications, or people joining just to vote (this should not be a MicroProfile recruitment opportunity, IMHO). I wouldn't mind mitigating these issues too. I have a second proposal, but let's see what comes of this thread :-)

Anyhooooo, I'll stop and wait for feedback.

[James Roper]

Hi John,

I think limiting it to the mailing list is a good idea. Being on the mailing list may not be much skin in the game, but it is a lot more skin than a casual Twitter user noticing a poll that has been retweeted in their feed. And not to mention, to vote you'll actually have to be watching the mailing list.

Also, to mitigate some of the problems you mention, I think possibly there should be an understanding that we (MicroProfile leads? ie you and Kevin? or committers?) may reject a vote if there's reason to believe that the vote has been unfairly manipulated in any way, eg, if someone does a recruitment drive to get the people that will vote in line with their agenda to join and vote. Not because that will necessarily happen, but because having that understanding reduces the chance that it will happen, because it makes it clear that trying to manipulate the process won't be effective, so there's no point in trying.

Cheers,

James

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/127f9925-2fbe-4526-8b6f-8328a86e2976%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

James Roper
Senior Developer, Office of the CTO

Lightbend – Build reactive apps!
Twitter: @jroper

[Raymond Auge]

On Thu, Aug 16, 2018 at 10:12 PM, James Roper <ja...@lightbend.com> wrote:

Hi John,

I think limiting it to the mailing list is a good idea. Being on the mailing list may not be much skin in the game, but it is a lot more skin than a casual Twitter user noticing a poll that has been retweeted in their feed. And not to mention, to vote you'll actually have to be watching the mailing list.

Also, to mitigate some of the problems you mention, I think possibly there should be an understanding that we (MicroProfile leads? ie you and Kevin? or committers?) may reject a vote if there's reason to believe that the vote has been unfairly manipulated in any way, eg, if someone does a recruitment drive to get the people that will vote in line with their agenda to join and vote. Not because that will necessarily happen, but because having that understanding reduces the chance that it will happen, because it makes it clear that trying to manipulate the process won't be effective, so there's no point in trying.

Cheers,

James

On Fri, 17 Aug 2018 at 08:23, John Clingan <jcli...@redhat.com> wrote:

We chatted last week at the Live Hangout that it may be time to formalize how we add new specifications to MicroProfile. I signed up to start the discussion, so here we go!

To date the process is basically any team of individuals can collaborate on a new spec/TCK, can target a MicroProfile release, and it becomes a formal spec.. There is basically no formal gate, although I suspect folks will speak up and start a discussion if a proposed spec is deemed either not ready or inappropriate (nothing to do with a microservices platform, for example). As MicroProfile grows in popularity and adoption, it's time to consider a more formal process. I'll start the discussion with a proposal that we can iterate on, or others can put up their own proposal, which is all goodness too.

My proposal is to have two discussion threads on a new proposed spec. The first thread is voting only. +1, -1, and some ratio threshold means approval (2/3? 3/4?). The voting thread is open for a period of time (two weeks?). The second  thread is intended to be a discussion thread on the vote. No discussions in the voting thread and no changing votes (to make vote tabulation easier).

+1

- Ray

 

Why MicroProfile google group threads? I'd like to constrain the vote to MicroProfile community members and not leave it open to the world to vote. Currently we more-or-less define our community that as those subscribed to the google group. We have > 1000 members. The concern I have about opening voting to the world is from those that do not have "skin in the game" voting "+1". It's not out of bad intent, simply out of casual "yeah, good idea" votes without realizing the commitment it takes to deliver implementations. Creating a new specification means that MicroProfile implementations (vendors, community implementations) have to implement them to be "MicroProfile X.Y compatible".

I think this is a good start to the discussion. I do have a concern that casual group members will vote without fully understanding the long-term ramifications, or people joining just to vote (this should not be a MicroProfile recruitment opportunity, IMHO). I wouldn't mind mitigating these issues too. I have a second proposal, but let's see what comes of this thread :-)

Anyhooooo, I'll stop and wait for feedback.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/127f9925-2fbe-4526-8b6f-8328a86e2976%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

James Roper
Senior Developer, Office of the CTO

Lightbend – Build reactive apps!
Twitter: @jroper

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CABY0rKMucbEiKPmvcnsZgzPgeADn8sp5%3DEtXpYGaTPDCLmnbwA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Raymond Augé (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

[Alasdair Nottingham]

Hi,

When you say 2/3 threshold do you mean 2/3 of votes or 2/3s of the community? The latter might be a challenge.

Alasdair

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

[John Clingan]

2/3 of voters, but defining voter is part of what needs to be done.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/81A6935B-3C55-4553-8308-FE6CB64B4926%40gmail.com.

[Alasdair Nottingham]

2/3 of people who exercise their right to vote, or 2/3 of those who are eligible to vote? I know we haven’t defined who gets to vote yet, but I think you are proposing everyone subscribed to the google group. If there are 1000 people what happens if we get low voter turnout, does it mean the spec cannot pass?

Alasdair

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/6c8bdc65-b68c-4f70-b206-cea649ef66a4%40email.android.com.

[John Clingan]

Thanks for all the feedback so far. Any additional feedback before the Live Hangout later today?

[Steve Millidge]

I think there needs to be a two step process. First to become a formal MicroProfile specification i.e. make a first release. Second to be added to the umbrella specification. Given adding a spec to the umbrella spec imposes some requirements on implementers of runtimes that want to support microprofile this second step has bigger implications.

Steve

[John Clingan]

I have the same concern as well. New specifications at the platform level do impose additional work on implementations. That work does deliver value, but does not guarantee developer adoption. Good topic! Anyone else have thoughts on this approach?

[John Clingan]

I threw that out as a strawman to encourage discussion. I think the only two easily measurable scopes are:

1. Members of the google group
2. A member of the google group for a period of time (to discourage "join just to vote"). 3 or 6 months, for example.
3. Committers

I'm open to growing that list, but it has to be easily measurable.

As for "2/3", IMHO it would be "2/3 of those who voted yes", assuming Yes, No, and Abstain are options.  "2/3" is also something I just picked, but it could be "3/4" or whatever. IMHO, 1/2 isn't a high enough bar. However, given steve's point of "a spec not immediately becoming a part of the platform", "1/2" is worth being a part of the discussion. 

Oh, a log of who voted and their vote should also be publicly logged.

This is all just my opinion only, of course :-)

On Monday, August 20, 2018 at 7:23:07 PM UTC+2, Alasdair Nottingham wrote:

2/3 of people who exercise their right to vote, or 2/3 of those who are eligible to vote? I know we haven’t defined who gets to vote yet, but I think you are proposing everyone subscribed to the google group. If there are 1000 people what happens if we get low voter turnout, does it mean the spec cannot pass?

Alasdair

On Aug 20, 2018, at 1:08 PM, John Clingan <jcli...@redhat.com> wrote:

2/3 of voters, but defining voter is part of what needs to be done.

On Aug 20, 2018 6:39 PM, Alasdair Nottingham <alasdair....@gmail.com> wrote:

Hi,

When you say 2/3 threshold do you mean 2/3 of votes or 2/3s of the community? The latter might be a challenge.

Alasdair

On Aug 16, 2018, at 6:23 PM, John Clingan <jcli...@redhat.com> wrote:

We chatted last week at the Live Hangout that it may be time to formalize how we add new specifications to MicroProfile. I signed up to start the discussion, so here we go!

To date the process is basically any team of individuals can collaborate on a new spec/TCK, can target a MicroProfile release, and it becomes a formal spec.. There is basically no formal gate, although I suspect folks will speak up and start a discussion if a proposed spec is deemed either not ready or inappropriate (nothing to do with a microservices platform, for example). As MicroProfile grows in popularity and adoption, it's time to consider a more formal process. I'll start the discussion with a proposal that we can iterate on, or others can put up their own proposal, which is all goodness too.

My proposal is to have two discussion threads on a new proposed spec. The first thread is voting only. +1, -1, and some ratio threshold means approval (2/3? 3/4?). The voting thread is open for a period of time (two weeks?). The second  thread is intended to be a discussion thread on the vote. No discussions in the voting thread and no changing votes (to make vote tabulation easier).

Why MicroProfile google group threads? I'd like to constrain the vote to MicroProfile community members and not leave it open to the world to vote. Currently we more-or-less define our community that as those subscribed to the google group. We have > 1000 members. The concern I have about opening voting to the world is from those that do not have "skin in the game" voting "+1". It's not out of bad intent, simply out of casual "yeah, good idea" votes without realizing the commitment it takes to deliver implementations. Creating a new specification means that MicroProfile implementations (vendors, community implementations) have to implement them to be "MicroProfile X.Y compatible".

I think this is a good start to the discussion. I do have a concern that casual group members will vote without fully understanding the long-term ramifications, or people joining just to vote (this should not be a MicroProfile recruitment opportunity, IMHO). I wouldn't mind mitigating these issues too. I have a second proposal, but let's see what comes of this thread :-)

Anyhooooo, I'll stop and wait for feedback.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/127f9925-2fbe-4526-8b6f-8328a86e2976%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/81A6935B-3C55-4553-8308-FE6CB64B4926%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

[Emily Jiang]

There are more questions to be answered:

What if most of 2/3 are from the same company? Is this still valid? Obviously, for a healthy spec, supporters need to come from different companies or individuals?
Do we need to divide the votes among the companies? This will be very sticky. Very soon this will run into the 'seats' issue.

I am kind of thinking: spec must not be vetoed by anyone. If this one, the issue must be spelled out clearly. Then, the highlighted issue must be solved before it can be included. In this case, there won't be a vote based on feelings but fact. There will be less potential headaches.

my 2cents.

Emily

Alasdair

Alasdair

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/127f9925-2fbe-4526-8b6f-8328a86e2976%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/81A6935B-3C55-4553-8308-FE6CB64B4926%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

[Ondro Mihályi]

I like the 2 phase process - first individual specs are voted to approve a final release. Then we vote which specs to add to the next MP umbrella release.

I propose this style of voting:

- anybody on the mailing list can vote with +1, 0, -1, but the vote is not binding, just a recommendation, and certainly not a veto

- a committer can vote with +1,0, -1 followed by the word "binding" (or just B) - we can easily check if the binding votes are from real committers. A -1 binding vote would mean a veto

- every commiter will write a company s/he represents (a company name or "individual")

Then we can count the number of committer votes (binding), company votes (total of committer votes from a single company), and number of total votes.

I'm not going to suggest the best way how to evaluate the votes, but I don't like ratios like 2/3. They are either too strict (if the total is all the people who can vote, e.g. all the committers) or too weak (if the total is the number of voters, because most voters vote +1).

I can imagine that we would require the following for an approval of a spec release:

- at least 5 votes +1

- out of all votes at least 3 binding +1

- no binding -1

- votes +1 from at least 2 different companies/individuals

For including specs in an umbrella release, we can roughly double the requirements (10 votes +1, 5 binding +1, no binding -1, at least 3 companies)

Veto doesn't mean that all is bad but that additional work is needed.

--Ondro

[John Clingan]

Thanks Ondro. I have mixed feelings on "-1" binding. It worries me that one committer can hold up a spec (or a release), but on the other hand a spec can negatively impact one implementation over others. I need to think about this and we need to gather more feedback. The two-tier approach (community and committer) is interesting.

[Guillermo González de Agüero]

If the voting fails because one -1, there might be a second round 1 month later after addressing concerns, where a single -1 doesn't veto anymore.

That way makes binding voter enough confidence that their opinion is taking into account, but not too much power by being able to block anything at convenience.

In most cases I assume -1s will be due to specs lacking some "cricital feature, without what it doesn't makes sense to deliver" and not because people think a spec should have never be started (in that case, they would have voted -1 for creation anyway).

A similar process worked well with the JPMS on Java 9.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/9019dc3d-609b-4ae5-a7ee-bbae7f3dd44c%40googlegroups.com.

[Emily Jiang]

I was thinking about the same: the minimum requirement for releasing a spec is zero -1. In this way, we don't have debates between the votes ratios, binding, no-binding votes, votes between companies, but focus on addressing the real issues if any, which is more important than anything else. Once the issue is solved, the spec can be released. 

Emily

[Ken Finnigan]

I'd be concerned with a single -1 to veto approval without there being valid reasons to do so.

Otherwise, what's to stop an individual voting -1 against the community as a whole for personal reasons?

Ken

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/4fab5202-586e-4717-b492-e137986d39cf%40googlegroups.com.

[Emily Jiang]

Yes, any -1 should come with a detailed issue. I think this issue should be raised on the github. Then the spec workgroup should work with the issue originator to get the issue closed via code changes or agreed as non-blocking issue so that the release can go on.

Emily

[Ken Finnigan]

That's a good idea.

Maybe it needs to be something along the lines that a -1 isn't valid without links to appropriate GH issues outlining what needs to be resolved?

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/32ed7874-a1f7-40f4-b010-95ffa055f370%40googlegroups.com.

[Emily Jiang]

+1
Emily