Hi,
I was thinking the other day if we should perhaps have a lightweight process for handling feature requests, bug reports and generally anything that is filed in
https://github.com/jakartaee/cdi/ (NOT in the TCK, that has its own process).
My main reason is that the CDI project in the JBoss.org JIRA, which was used before migrating to GitHub, had nothing like that, so over time, it became a dumping ground of issues that no one actually ever planned to work on.
I'd like to propose a simple, easy to understand and follow process. It could later be described as a state machine, but I'll keep it in words for now to avoid being too specific too soon.
If an issue is opened, ideally someone says "yea, this is a good idea, I wanna work on it". If no one wants to work on an issue, the sad state of reality is that it's never gonna be implemented -- which should be reflected in the issue tracker. If there's an issue that no committer or contributor expresses an interest in, it should be closed after some period of time (say, 3 months?), perhaps even using a bot.
If someone actually wants to work on an issue, they should state so in a comment (committers could assign to themselves), solicit ideas in the issue discussion, on the mailing list, on the CDI call, and eventually submit a PR. It is expected that the PR will go through several back and forths. We should probably formalize a situation when the PR author is satisfied and there are no objections, in which case a "last call for comments" is issued and if there are no objections, the PR is merged after some period of time.
We could/should define more clearly what happens with a PR that goes nowhere (should be closed and the issue would move back to the original state), if there are objections that are not being resolved (move the discussion to a more wide forum, maybe even a vote) and perhaps a few other situations -- but I believe that if someone goes as far as submitting a PR, there's a decent chance the PR will eventually be accepted.
The PR should also be accompanied by an explanation of how this affects the TCK and implementations. In fact, we probably should have a template for all PRs, and this would be one of the questions to answer in that template.
This could also be tied to milestones and release planning, but I'd rather not do that, or not too closely. Unless someone wants to target a specific CDI release with their PR, they should be free to work on it on their own schedule.
This email is already a bit longer than I hoped for, so I'll leave it here. Comments, ideas, proposals and counter-proposals are very much welcome. If we agree something like this is a good idea, we should probably put the process description here:
https://github.com/jakartaee/cdi/wikiThanks,
LT
