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

MicroProfile/FeatureInit

< MicroProfile
Revision as of 15:54, 19 June 2017 by Kwsutter.gmail.com (Talk | contribs) (Minor updates to provide links where necessary)

Introducing New Ideas to Eclipse MicroProfile

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: Request a Repository

Send message to Google Group Forum with brief paragraph or two on the idea/proposal and asking for feedback within 72 hrs.

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.

Acceptance results in an appropriate admin requesting a new git repository for the proposed feature so that work can begin on spec/api/tck.

Once the new repository is created, existing content from `microprofile-sandbox` can be migrated to new repository and removed from `microprofile-sandbox`.

Step 2: Collaboration

A proposed feature goes through community iteration of development, discussion leveraging lazy consensus. Any form of release requires community consensus.

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 Release Process. First, it is encouraged to setup a 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. 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.

Copyright © Eclipse Foundation, Inc. All Rights Reserved.