Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "MicroProfile/FeatureInit"

(Minor updates to provide links where necessary)
(One intermediate revision by one other user not shown)
Line 1: Line 1:
= Introducing New Ideas to Eclipse MicroProfile =
+
= Introducing New Ideas to MicroProfile =
 +
If you have some new ideas, please discuss them on [https://groups.google.com/g/microprofile microprofile.io mailing list] for some feedback. After the socialization, follow Eclipse Foundation Specification Process [https://www.eclipse.org/projects/efsp/#efsp-process Eclipse Foundation Specification Process (EFSP)]. The full steps are documented below.
  
 
== Step 0: (optional) Start immediately via `microprofile-sandbox` repository ==
 
== Step 0: (optional) Start immediately via `microprofile-sandbox` repository ==
Line 18: Line 19:
 
<b>Lazy Consensus:</b> Considered accepted with no negative votes.
 
<b>Lazy Consensus:</b> Considered accepted with no negative votes.
  
== Step 1: Request a Repository ==
+
== Step 1 Create a Plan Review ==
  
Send message to [https://groups.google.com/forum/#!forum/microprofile Google Group Forum] with brief paragraph or two on the idea/proposal and asking for feedback within 72 hrs.
+
In the Plan Review, please document the following areas: Background, Scope, Why here, License, People, etc. Send the plan review to microprofile-wg for a ballot. After the ballot concluded successfully, move to the next step.
  
If you (proposer) are already active in the MicroProfile community, lazy consensus applies.
+
== Step 2: Request a Repository ==
  
If you (proposer) are not yet active in the MicroProfile community, consensus is required.  Those not yet active are highly encouraged to leverage the [https://github.com/eclipse/microprofile-sandbox sandbox] as a great way to show the essence of ideas.
+
Raise a Eclipse Foundation bugzilla ticket to get the new repository created. Once the new repository is created, existing content from `microprofile-sandbox` (if applicable) can be migrated to new repository and removed from `microprofile-sandbox`.
  
Acceptance results in an appropriate admin [https://wiki.eclipse.org/MicroProfile/EclipseCreateNewRepository requesting a new git repository] for the proposed feature so that work can begin on spec/api/tck.
+
== Step 3: Collaboration ==
  
Once the new repository is created, existing content from `microprofile-sandbox` can be migrated to new repository and removed from `microprofile-sandbox`.
+
The specification team can meet up via meetings or offline conversations to work on the specification. It needs to be open and inclusive.  
  
== Step 2: Collaboration ==
+
== Step 4: Release of a proposed feature ==
  
A proposed feature goes through community iteration of development, discussion leveraging lazy consensus.  Any form of release requires community consensus.
+
Once a proposed feature has been developed to cover reasonable and consistent functionality that can be released, the team behind it follow [https://wiki.eclipse.org/MicroProfile/SpecRelease/Release this] process for the specification release.
 
+
== Step 3: Release of a proposed feature ==
+
 
+
Once a proposed feature has been developed to cover reasonable and consistent functionality that can be released, the team behind it may initiate the [[/SpecRelease | Release Process]]. First, it is encouraged to setup a [https://ci.eclipse.org/microprofile/ Jenkins] job to release a nightly snapshot and announce it on the mailing list. Then, optional milestone versions, and finally a release candidate may be released and ask wider community for a review. One of the release candidates is then turned into a final version. The work may then continue on the next version.
+
 
+
== 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. [https://projects.eclipse.org/projects/technology.microprofile/governance 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.
+

Revision as of 14:34, 7 September 2021

Introducing New Ideas to MicroProfile

If you have some new ideas, please discuss them on microprofile.io mailing list for some feedback. After the socialization, follow Eclipse Foundation Specification Process Eclipse Foundation Specification Process (EFSP). The full steps are documented below.

Step 0: (optional) 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.

Lazy Consensus: Considered accepted with no negative votes.

Step 1 Create a Plan Review

In the Plan Review, please document the following areas: Background, Scope, Why here, License, People, etc. Send the plan review to microprofile-wg for a ballot. After the ballot concluded successfully, move to the next step.

Step 2: Request a Repository

Raise a Eclipse Foundation bugzilla ticket to get the new repository created. Once the new repository is created, existing content from `microprofile-sandbox` (if applicable) can be migrated to new repository and removed from `microprofile-sandbox`.

Step 3: Collaboration

The specification team can meet up via meetings or offline conversations to work on the specification. It needs to be open and inclusive.

Step 4: Release of a proposed feature

Once a proposed feature has been developed to cover reasonable and consistent functionality that can be released, the team behind it follow this process for the specification release.

Back to the top