| Re: [microprofile-wg] [External] : Proposal to standardise the process for creating new proposals |
After the conversation on 10th August MicroProfile Technical discussion, we have agreed that the following step is optional.[Optional] Start immediately via `microprofile-sandbox` repository
MicroProfile will adopt the EFSP process.Therefore, in order to create a new specification, the first review is Creation Review.If you have any questions, please comment on this thread.ThanksEmilyOn Tue, Jul 6, 2021 at 5:45 PM Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx> wrote:How planning review process is tracked? Do we have a repository similar to Jakarta ‘specifications’ repository? I see that planning review with all required information (including goals) should be submitted and tracked there. In this case we don’t need sandbox because goals and other information is a part of planning review submission.
-- Dmitry
P.S.
Today is a public holiday in Prague. Unfortunately, I won’t be able to join today’s MP meeting.
From: Emily Jiang <emijiang6@xxxxxxxxxxxxxx>
Sent: Tuesday, July 6, 2021 11:40 AM
To: Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx>
Cc: Microprofile WG discussions <microprofile-wg@xxxxxxxxxxx>
Subject: Re: [External] : [microprofile-wg] Proposal to standardise the process for creating new proposals
Thank you Dmitry for the feedback! By the way, the sandbox does not require APIs to be present. It can just contain the readme to flush out the goals and use cases the proposal is to address. I think using sandbox drafts out the proposal so that others can participate early might be something beneficial and transparent. After some socialisation on the sandbox proposal, the proposal can be used to create plan review, which might have a better chance to go through the ballot. We can discuss this further in today's meeting.
Thanks,
Emily
On Mon, Jul 5, 2021 at 4:02 PM Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx> wrote:
Thanks for composing a proposal, Emily. I have a few comments.
Sandbox approach works well in case some work has been done already and some version of APIs already defined. It can be a starting point for a new spec, but it may be not. APIs are defined as part of the work process based on the spec goals and not goals. Jumping over the goals step usually results in faster spec development, but it may have a drawback of quality. I think that the sandbox step must not be required. It’s fine if proposers can show something, but it’s also fine if they just present strong goals and justification why the spec is needed without providing any API.
I am also strongly recommending adding spec goals and justification as requirements for the plan review. It will be easier to understand why this spec is needed.
Thanks,
Dmitry
From: microprofile-wg <microprofile-wg-bounces@xxxxxxxxxxx> On Behalf Of Emily Jiang via microprofile-wg
Sent: Wednesday, June 30, 2021 12:31 PM
To: Microprofile WG discussions <microprofile-wg@xxxxxxxxxxx>
Cc: Emily Jiang <emijiang6@xxxxxxxxxxxxxx>
Subject: [External] : [microprofile-wg] Proposal to standardise the process for creating new proposals
Further to yesterday's MP technical call, there was a consensus to standardize the way of creating new specifications. In this year's MicroProfile Technical Goals, the community expressed the desire to work on new proposals of adopting new technologies such as OpenTelemetry, gRPC, etc. How to proceed with this?
The current MP process is documented in this wiki. There was some feedback regarding:
If you (proposer) are already active in the MicroProfile community, lazy consensus applies.
If you (proposer) are not yet active in the MicroProfile community, consensus is required. Those not yet active are highly encouraged to leverage the sandbox as a great way to show the essence of ideas.
It seems like adding an extra barrier to new proposers. Besides, what happens if no consensus is reached. This seems one -1 will stop a proposal going forward, which contradicts with our voting policy of supermajority.
With these concerns, we discussed in the meeting with some initial suggestions:
Step 1: Start immediately via `microprofile-sandbox` repository
- Fork the repository
- Create a distinct sub-directory
- Code
- Submit as many PRs as you need to explore the ideas behind the proposal
No approvals or prior notification required.
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.
When ready, proceed to the next step.
Any form of contribution on any topic is allowed in the `microprofile-sandbox`. Moving from the `microprofile-sandbox` is at will or upon request of the MicroProfile community.
Step 2: Create Project Creation Plan
Follow what Jakarta project creation plan template (see Jakarta config plan creation)
- Background
- Scope
- Why here
- License
- People
Create an issue under microprofile-wg with the label of Plan Creation Review and then send it to this WG to start a ballot. If it passes the ballot with a super majority, a new project will be created under microprofile.
Please share your thoughts. With some discussion, we can then move towards a ballot to make it final.
--
Thanks
Emily
--Thanks
Emily--_______________________________________________Thanks
Emily
microprofile-wg mailing list
microprofile-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/microprofile-wg
