Draft MicroProfile Specification Process (MPSP) Discussion Thread

[John Clingan]

Here is a MicroProfile Specification Process Draft. This is a much shorter and simpler to manage than the Working Group Charter, but the existing guidelines remain. I'll consolidate comments. Longer discussions will be redirected back to this thread.

Notes:

• David Blevins, John Clingan, Kevin Sutter, and Scott Stark got together today to prep a draft for the Live Hangout Working Group Discussion.
• This proposal is a draft. Let's get a lot of feedback, quickly I hope. We have a 4.0 release in the making :-)
• The Draft is intended to be a compatible specialization of the Eclipse Specification Process, v1.2.

[Amelia Eiras]

Based on what was discussed on today's call, I have adjusted the MPSP document. Literally, this doc will likely be half a page. :)

[Wayne Beaton]

There is no requirement to have a distinct "MicroProfile Specification Process", especially if there is no need to tweak parts of the process. At this point, I'm pretty sure that the current document adds no actual value.

The MicroProfile Working Group can just adopt the Eclipse Foundation Specification Process directly, thereby avoiding the need to maintain yet another process document.

Wayne

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/93403390-23b7-41f9-b9e0-bf151d255338%40googlegroups.com.

--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.

Join us at our virtual event: EclipseCon 2020 - October 20-22

[Amelia Eiras]

Hola Wayne, thanks for the follow up. 

Happy busy Monday MicroProfilers, 

We continue to learn & work on this task, TOGETHER, while discovering how MP might be impacted if it chooses to acquire the EFSP. 

I will be completely honest, if the EFSP requires for this project to provide budget to hire bodies under the EF umbrella  to manage stuff that has been and continues to be successfully and currently handled 100% solely by the MP Community, that is huge NO in my book. I have no interest on that MP future, I have no interest in pay for play either.  

Tomorrow is the 1hr full solely dedicated to the WG discussion, we will continue to have candid conversations on the future of MP.

Should any of you reading this, not yet attending the calls-- JOIN the conversation, showing up is the very first step aside from listening to the call conversations found in the MP youtube channel HERE! 

Cheers with tea, 

On Monday, April 20, 2020 at 3:37:34 PM UTC-7, John Clingan wrote:

[Emily Jiang]

Hi Amelia,

I am a bit confused about your reply. This thread has nothing to do with the budget etc. It merely means that there is no need to have additional MicroProfile Specification Process over and above Eclipse Specification v 1.2, based on Wayne's confirmation.

Thanks

Emily

[Kevin Sutter]

+1, Emily!  We can greatly simplify the whole Working Group process by accepting the EFSP without defining a MP-specific derivative.  Through the reviews of the MPSP, we have determined that there is no benefit with defining a separate derivative.  Thus, we should go forward with the standard EFSP.  There are no budget or fee items associated with the Specification Process.

Thanks, Kevin

[John Clingan]

We talked about adopting the EFSP on the Live Hangout and those in attendance agreed to it. This does not have any bearing on the budget.

[Werner Keil]

From a Jakarta EE point of view this also makes it much easier to accept inbound specs or technologies that apply the EFSP whether it'll be a part of MP, something under IoT or say Asciidoc which to my knowledge also applies an unchanged EFSP.

Otherwise it would not only make things more complicated for the MP participants themselves, but also those considering to use it in a platform like Jakarta EE and create more complexity for every special variation yet another project or WG might think of.

Werner