-
Notifications
You must be signed in to change notification settings - Fork 78
Home
Below is a collection of resources and information that explain how CDI is developed, what decision process is in play and how you can contribute.
The current draft of specification can be seen here on GH; in case you want to see some already released version, you can look at Jakarta website or CDI GitHub pages site.
In case you are looking for CDI TCKs, those are located in a separate GH repository and available in the Eclipse ee4j.cdi downloads.
There are several ways to provide feedback.
Firstly, we use GH issues as a universal issue tracker. This is a good fit for specific suggestions, code changes and discussions regarding those.
Secondly, there is [email protected] mailing list with archives.
Mailing list is a fine place to get people's opinions and start discussions with broader audience.
If you want to stay on top, we suggest you follow both resources, neither of which should be high traffic.
The group of committers has agreed that decision making process is vote based with following rules:
- Voting is done via a thread on mailing list the subject of which
should start with
[VOTE]or similar prefix making it clear that action is required - Voting process cannot be concluded sooner than 7 days since it started
- Vote result is a simple majority meaning more than 50% of voters have to
+1 - Committers can vote either
+1or-1- Negative votes should also contain an explanation or an alternative suggestion
- Non-committers are encouraged to vote as well, but their votes are non-binding
- Lazy consensus is applied meaning people not actively voting are automatically counted as
+1
An example of the process:
- Assuming there are 7 committers in total and that the vote started on 9th Apr 2021:
- This vote will run at least until 16th Apr 2021
- Assuming 3 committers vote
+1 - Assuming 2 committers vote
-1 - Assuming 2 committers cast no vote
The conclusion of the vote would be a SUCCESS with 5 votes for and 2 votes against.
Each addition/change should be tracked via GH issue that captures the nature and purpose of the change. Contributing itself is as simple as sending a pull request that than has to be approved by at least one person with committer status before merging.
Ideally, each change to the specification should have a relevant CDI TCK test created for it (if testable). This should be tracked and submitted into the CDI TCK GH repository.
If you are interested in CDI Lite, more info are here