New, Updated Process for Initiating a Specification Proposal

[Kevin Sutter]

After much discussion and work by Ken (and others), we have a re-vamped process for initiating a proposal for a new component specification!

https://wiki.eclipse.org/MicroProfile/FeatureInit

We have linked this page off our of MicroProfile Wiki:  https://wiki.eclipse.org/MicroProfile, under Process Guidelines.

We have also provided an updated Readme in the microprofile-evolution-process github repo as a redirect to this new process:  https://github.com/eclipse/microprofile-evolution-process

Hopefully, this will help with getting on-board with MicroProfile a tad bit easier.  Enjoy!

--  Kevin

[Emily Jiang]

Thank you Kevin for announcing the new process! I think we should re-vamp the process from time to time. If the current process does not work, we should re-vamp again. Let's see how much traffic will get to the sandbox. Maybe we should pin this thread on the top.

Emily

[Mike Croft]

Thanks for this!

It looks to me like this all covers features that we might develop as a community ourselves, but I would like to propose that we incorporate JSON-B 1.0 in either MP 1.2 or MP 2.0 (or both?) - how would I go about that, since the spec already exists and is finalised?

Reading through the page, I think what I'm probably driving at here is just a small clarification of Step 4:

Step 4: Make a feature a part of a MicroProfile release

When a final version of a feature is released, it can be part of any future MicroProfile version. MicroProfile releases are driven by deadlines and any feature is considered to be part of a MicroProfile release automatically if it's final before the deadline.

It would probably be worth specifying that "feature" in that paragraph refers to features developed by the MicroProfile community. While I think JSON-B is great, I don't think it qualifies for automatic inclusion!

For "outside" specs, would it be a good idea to have a process whereby we simply: 

(a) Create Google Group discussion to acquire consensus in the same way as we would for Step 1

(b) Once positive consensus is reached, create a GitHub issue against the MicroProfile repository with a milestone of the next version to be released

Does that make sense? The GitHub issue I'm suggesting here is really just a reminder that we've agreed to put spec X into MicroProfile-bom version Y (or agreed to upgrade spec N in version M) and a clear, easy way to see what the conclusion was.

[Alasdair Nottingham]

To include JSON-B I believe we would need to upgrade JSONP-1.0 to JSONP-1.1. In prior discussions we had discussed leaving that to a microProfile-2.0 so there is clear separation between micro profile with Java EE 7 specs and micro profile with Java EE 8.

Alasdair

--
You received this message because you are subscribed to the Google Groups "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/4ebfc6dc-ce06-4416-870c-24b6189af635%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kevin Sutter]

+1 Alasdair

The inclusion of json-b 1.0 and any other java ee 8 related technologies would be considered as part of MicroProfile 2.x release.  We need a clear distinction on what versions of Java EE technologies that we might be dependent on.  Once we get the MP 1.1 well in-hand, then my plan was to start the discussions for MP 1.2 and MP 2.0.  But, if you (Mike) wish to kick off those discussions before I get around to it, you are more than welcome to.  Thanks.

--  Kevin

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

[John D. Ament]

Hmmm....

This statement looks wrong:

The `microprofile-sandbox` has an intentional zero bar to entry to capture ideas when time permits, from anyone, even if not yet active in the MicroProfile community.

Specifically, in order to write to the sandbox you need to be a committer on Eclipse Microprofile.

For Step 1, I think we need to add a comment that you need approval from a "Tech Lead" on the Eclipse Bugzilla ticket you create.  In addition, we should call out that the expected license is Apache v2.

Other than that, I think the simplified process will be easier for people to move forward on.

John

[Mike Croft]

@Kevin - I fully agree! Let's get 1.1 out the door before we begin the next steps. My point was mostly to make sure that this process covered the other case where we weren't developing anything new, and it looks like that's the case!

[Arthur De Magalhaes]

Hi all,

I am now at the proposal stage where a new eclipse repo was created (https://github.com/eclipse/microprofile-open-api), so I am wondering if I should be making PRs that someone will approve/merge, or should I request write access to it somewhere?  

Thanks,

Arthur

[Ondrej Mihályi]

Hi Arthur,

Write access to the repositories is allowed only to committers to the Eclipse project and there's no way around it. 

You should create PRs, which should be reviewed by at least one committer and then merged.

You would also need to sign the Eclipse CLA so that your code is accepted by Eclipse before your PR can be merged.

We have a habit also among committers that we create PRs and another commiter then merges them to have some kind of a review, unless the change is trivial.

To become a committer, someone from the committers has to nominate you first and them all committers vote.

But you don't need that, at least in the initial phase. You just need at least one other committer to review and merge.

If you show enough commitment I'm pretty sure someone will nominate you sooner or later.

--Ondro

[Arthur De Magalhaes]

Sounds great, thanks Ondro!