Policy on granting commiter status

[Steve Millidge]

I've noticed that there is an open vote to add 4 more committers onto the Microprofile project. 

My questions is, given that a committer has a very specific role within the Eclipse Development Process https://www.eclipse.org/projects/dev_process/#4_1_Committers which encompasses far more than just write access to the source code repository. What should the policy be on committers. I can see a number of options

1) Restrict the number of committers and only the spec lead (and perhaps deputy) be a Commiter in the Microprofile project and use PRs to merge contributor contributions

2) Let anybody who writes some code for a spec be a committer

3) Restructure Microprofile into a number of subprojects. 1 for each spec using a Restructuring Review https://www.eclipse.org/projects/dev_process/#6_3_8_Restructuring_Review

Note this post is not a judgement on the merits of any of the 4 people whose vote is currently open.

Thanks

Steve

[John D. Ament]

I personally like #3.  It seems prudent to me that allowing each spec to evolve on their own, and treating MP as a more umbrella project sets us up for a better long term picture.  It should more easily allow the specs to grow in ways that don't force them to only be used within MP but also potentially EE4J projects.  It also means you're keeping a simplified structure and independent governance model.

I would love to see more committers commit for a spec.  I don't think it happens because of how we're used to the JCP operating.

John

[Mark Struberg]

Hmm all of those approaches have some pros and cons.

ad 1: this is basically having a benevolent dictator. Did sometimes work, but more often it doesn't in OSS projects

ad 2: if the bar is too low then it will quickly become wild-west

ad 3: is imo OK, but might slow down adoption/feedback for some parts

At the end I think we just need to define a criteria for the bar we want to set. 

And then let the vote do the rest. 

At the ASF we first use a *private* [DISCUSS] thread internally at the PMC. 

And only after that we hold a formal [VOTE] - but also only on the PMCs private@ channel.

That way we can openly discuss about whom to get on board (and when!) without making someone loose his face.

LieGrue,

strub

[Steve Millidge]

The difference with Apache is I believe there are no private discussions threads. Also in Eclipse Terms the whole of Microprofile is one project and there is no PMC as that is only for the top level parent project which in this case is Technology.

[Ken Finnigan]

I can see some benefit and drawbacks in option 3 in particular.

It would certainly make the release naming a lot easier, as we wouldn't have to prefix release numbers with name of the spec, etc. Related to that would be that it also simplifies the IP validation processes as it doesn't need to be done over the entire set of all MicroProfile repositories.

The biggest downside I could see is that it adds an additional hurdle to new specifications coming on board, as it would require a whole new Eclipse Foundation project to be created. Now maybe a way to work around that is for the sandbox to be in the umbrella project and once a spec has matured in the sandbox we look to create the actual project for it to live in.

At any rate, I'm not sure the way it's currently setup would scale well when we start talking about 10/20/30 specifications as part of MicroProfile.

Ken

--
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/6fdf3033-f780-4108-8e7b-50e482c2f08a%40googlegroups.com.

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

[Emily Jiang]

We should encourage more committers on our projects and grow the community.

Maybe we can have 2 type of committers, overall committers and individual project committers. This is more like PMC and committer in Apache world.

Not sure whether the current infrastructure can handle this.

Emily

[Steve Millidge]

Absolutely we want to encourage more committers and grow the community. @Emily the way to do what you suggest is my option 3. According to the EDP "In practical terms, each Project has a single Unix group of its Committers that provides write-access to the Project's resources." So currently we have one project and therefore one group of committers. So if you want what you describe you need to create multiple projects. The link to the EDP shows exactly what I am proposing in Option 3  https://www.eclipse.org/projects/dev_process/development_process_2010.php#4_1_Committers

How about a project structure like;

Technology (PMC) -> Microprofile -> Microprofile Incubator (Specs not yet released a 1.0) this addresses the sandbox issue Ken raises

                                                       -> Config

                                                       -> Fault Tolerance

                                                       -> Metrics ...

Then the Top Level Microprofile commiters are concerned with which incubation projects within Microprofile graduate and when to do Microprofile releases rolling up on the graduated projects latest releases into an overall Microprofile release.

Each spec can have its own committer group who control the destiny of the spec and its release schedule.

Steve

[John D. Ament]

Or....

EE4J (PMC) -> Microprofile -> Microprofile Incubator (Specs not yet released a 1.0) this addresses the sandbox issue Ken raises

                                                       -> Config

                                                       -> Fault Tolerance

                                                       -> Metrics ...

[Emily Jiang]

No. Not EE4J as yet. We should stay on Technology after EE4J settles and our MicroProfile community wants to move there.

+1 on Steve! We can investigate how to implement this after people once the general consensus is 'yes'.

Emily

[Steve Millidge]

I assume it would be easier with sub-projects to switch top level project in the future if/when it's the right time.

Here's an example of just that https://projects.eclipse.org/projects/science/reviews/eclipse-science-project-restructuring-review 

[John D. Ament]

Yes, that link is exactly what I had in mind for how it would work.

[Werner Keil]

+1 on 3.

Having sub-projects would also allow cleaner version numbers than things like "jwt-propagation-1.0" etc.

It also gives some the freedom to move to EE4J while others could wait till it makes sense or stay under a "Microservice Pattern collection" on top of Java EE / EE4J.

Werner

[Kevin Sutter]

Really?  We want more project overhead?  This would require separate Eclipse project overhead for each of the proposed sub-projects.  It's own governance, it's own releases, it's own set of committers, it's own project leads, etc.  I actually see this as slowing down our innovation rather than increasing it.

Let me back up...  What problem are we trying to solve?  I haven't seen any indication that we're letting the foxes into the chicken coop.  Allowing committers to participate on all of our components doesn't seem to be a problem yet.  So, are we trying to solve a problem that doesn't even exist?

The other part of this discussion is the actual sub-project creation.  Eclipse is not a big fan of sub-projects.  They are trying to discourage our usage even in the EE4J discussions.  (Although, in full disclosure, I am in favor of sub-projects for the EE4J project.)  But, EE4J is such a bigger project effort than MicroProfile.

Getting back to Steve's original list of proposals:
#1   -1, bottleneck city
#2   +1, pretty much as we have it today
#3   -1, too much overhead

I think we stick with our current structure until we figure out our relationship with EE4J.  And, we should wait until EE4J shakes out and becomes established before we make a decision for MicroProfile.

Thanks, Kevin

[John Clingan]

I think this is pre-optimizing for a problem that doesn't exist yet, which is antithetical to the lightweight approach we have been striving for. I prefer not to define new processes, and then down the road having to redefine our processes based on (eventual) EE4J alignment.

FWIW, I am very much against #1.  While it is probably technically doable within the Eclipse Foundation committer model, I definitely think it is against the spirit. As for the remainder of the approachers, I still prefer we wait to implement new processes.

[Mark Little]

+1

--

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/7a8b3b24-2906-4603-a098-9b81e6d2aca3%40googlegroups.com.

[Steve Millidge]

This then takes us back to the original reason for this posting.

If you wish us to use option 2 "Let anybody who writes some code for a spec be a committer" then we need an open published policy about when that bar is reached. Currently there is no documented policy which means we should be following the Technology PMC policy https://wiki.eclipse.org/Technology#Committer_Elections. In which case a number of recent nominations would not meet the bar set in that policy and would likely fall under the scenario described in paragraph 1. If we are setting the bar low to encourage many more committers then let's document it.

We need to make it clear to the community what level of demonstrable work is required to become a committer and that level must be consistently maintained whether the proposed committer is an employee of a contributing company or is an independent contributor. 

For Option #3 I think this needs to be discussed and the overhead understood before this conversation is shutdown. Option #3 would more likely reflect the status of Microprofile and the work being done. 

Steve

[Mike Croft]

So far, I think the situation hasn't been #2 at all, it's been #1 and I haven't seen any evidence of bottlenecks. E.g. all the IBMers on Metrics who have no direct write access can still raise PRs and Heiko was added as a committer specifically because he was effectively driving the spec forward and he was the one being most visible in Google Group posts.

 

Getting back to Steve's original list of proposals:
#1   -1, bottleneck city
#2   +1, pretty much as we have it today
#3   -1, too much overhead

As a general point on this thread's topic, I think we are missing some kind of process/checklist about who we accept as committers. We can either be very permissive or more restrictive. The actual "rule" itself doesn't matter so much as the fact that it is clear, simple and well-known.

Consider this scenario - John quite rightly pointed out that Tom who has been nominated as a committer has had just one Google Group post and 3 minor commits to the spec; where the PRs have had no supporting communication. In this case, IBM are vouching for his status and I expect those committers who have voted for him are happy with that (note, I am not trying to say there is any issue at all with Tom himself! Sorry Tom, you're just a good example for this point!). Currently, Tom has passed the requirement of 3 votes and will become a committer. There are other people in a similar situation as Tom who do not have the backing of a vendor and are just individuals. Should we grant them committer status just as easily? How would they get nominated? Would they get automatically nominated after making 3 minor pull requests? In Tom's case, I am confident that he is nominated to contribute to Fault Tolerance and am happy that others can vouch for him. How would we trust that anyone else with such a low level of contribution to the project would not have significantly different views for the direction of MicroProfile and use their status to veto future votes? This is especially a problem when a single veto is all that's needed.

I think this is a discussion we really need to have so that we can be consistent and fair for everyone. Otherwise, we find ourselves in a position where voting "no" becomes very hard to justify objectively.

On Monday, 30 October 2017 19:11:04 UTC, Kevin Sutter wrote:

[Kevin Sutter]

Mike and Steve,

I do agree that we should probably define some criteria for our proposed MicroProfile project committers.  As it stands today, it's just a "gut feel" and then we try to justify the nomination by examining their commits, forum activity, conference activity, blogs, etc.  If the proposal does not meet an existing committer's standard, then they can justify voting 0 or -1.  We should be voting based on the merits of the nominee.

I know you were only using Tom's participation as an example, but I have to question John's claim of only 3 PRs.  According to the IP Log that I generated for MicroProfile 1.2, Tom has 16 commits, not just 3.  He has only had three this year, but he was quite active with the Conference App last year before and during JavaOne.  Just trying to clarify the nomination a bit...
https://projects.eclipse.org/projects/technology.microprofile/releases/microprofile-1.2/iplog/preview

(Also, as an aside and in full disclosure, I abstained from voting for Tom at this juncture.  I think his overall participation could be fuller and more public before getting a +1.)

We can discuss more at our hangout today since it's the first item on our agenda.

Thanks,

Kevin

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/1obj2dlFHNc/unsubscribe.
To unsubscribe from this group and all its topics, 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/20e94ffc-5b6d-439e-b219-5e5315e41ad2%40googlegroups.com.

[Emily Jiang]

+1 on Kevin! 

Since the current structure is not designed for this sort of fine-grained policy as Steve stated, plus we don't have any problems so far, I would like to tick #2 as per Steve's notes . I think we need to grow the community. We also needs to accept different types of participants. Some of them like to talk with code while others are vocal with questions. I think we just need to keep open minded and acceptable. 

By the way, for some reason, I was still not being subscribed to the microprofile-dev mailing list, so I cannot see any discussion there. I cannot attend today's call as it is Halloween. I was requested to do 'Trick and Treat' at the same time. My daughter said Halloween only comes once a year....

Thought to clarify my position as I won't be on the call to voice out.

Thanks

Emily

To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.

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

[Arthur De Magalhaes]

Hey,

In my opinion the first option would work, although the "restriction of committers" can be less strict:

- there needs to be some meaningful contribution - code, or advocacy, or other participation (see next point) - for someone to receive committer status, so that it's representative of the folks helping drive the community forward (in different ways).

- new developers that help push a specification idea past the sandbox stage (by advocating and having discussions on this board) should be granted committer access so that they can help drive the creation of the MP GitHub repo for that spec.  I think the work and commitment involved in driving a spec should fall into the category of "meaningful contribution".  The key for the this point is that spec lead needs committer access as soon as the official repo is created to be able to drive effectively (ie: apply labels to issues, assign issues, assign reviewers, merge PRs)

This is the position I find myself in now:  my original OpenAPI PR took 3 weeks to get merged, so I had to create a fork of the Eclipse GitHub so that myself and others could push changes into a branch without creating a  30+ "PR spaghetti" in the main repo. None of our issues are assigned nor have labels in them.  If I could help merge those PRs in to build up the spec things would go much faster, with much smaller PRs, as well as the issues being more organized (timelines, etc).

Thanks,

Arthur

[Emily Jiang]

Arthur,

>>my original OpenAPI PR took 3 weeks to get merged, so I had to create a fork of the Eclipse GitHub so that myself and others could push changes into a branch without creating a  30+ "PR spaghetti" in the main repo. None of our issues are assigned nor have labels in them.  If I could help merge those PRs in to build up the spec things would go much faster, with much smaller PRs, as well as the issues being more organized (timelines, etc).

Please send a reminder to the google group to chase up for review or merge. It is not acceptable to wait for a long time without being noticed. Please don't wait but shout loudly. Once a contributor has done a few PRs, The committer group should be able to nominate him/her to be committer.

Maybe the current committer group should review regularly on who should be nominated for committers. I think we now have a discussion channel to look at this soonish.

Emily

[Werner Keil]

I doubt it's really that much of an overhead, take Nebula:

https://projects.eclipse.org/projects/technology.nebula

it also got an Incubator:

https://projects.eclipse.org/projects/technology.nebula.incubator

but best ask the mentors or someone at Eclipse EMO about that.

And with "incubator" or "sandbox" there is no need to create a separate sub-project (not individual project) yet until the idea matures and gathers enough momentum and contributors.

Werner