Re: [cdi-dev] lightweight process for handling feature requests, bug rep

[Matej Novotny <manovotn@xxxxxxxxxx>]

Hi

I very much agree that this would be beneficial in terms of giving committers confidence in how to proceed with issues and PRs if we have an agreed upon and documented approach.

IMO, if there is an opened and inactive issue for a certain period of time (and I agree with the 3 months window), I'd say we can close it - with stale bot being the default implementor of that behavior.

We could also use the bot to notify author of the issue that it's been inactive for over a month to give them a heads up.

Having opened issues endlessly piling up is of little value overall - active/open issues should reflect what are current suggestions and what's being worked on.

There is always the possibility of re-opening what's closed or searching closed issues to dig up previous suggestions.

All of the above could be combined with labels to ease the filtering of issues (i.e. all that are closed due to inactivity get a "stale" label for instance).

When it comes to PRs, I'm +1 on having a template that helps users describe their issue/suggestion and also reminds them that we're going to need a TCK coverage for whatever the PR changes.

I'd love to formalize the accept/reject process of PRs as well, but TBF I am not sure this can be done "simply" because we need to be able to:

* Sort sort out micro issues fast

  - by this I mean typo fix, wording clarification without functional impact and so on

  - for these you don't really need a two week reaction period as the only result of such period is everyone forgetting the PR exists :)

* For anything non-trivial, give people some time to react/comment/provide feedback before merging

  - even in cases where you get one approval very fast, I think it's polite to have some period of time before you press the button - this period could be formalized

* Last but not least, deal with difficult PRs

  - for instance proposals countering decisions taken earlie or any PRs where part of committers are for and part are against with no middle ground in sight

  - not quite sure what to do in these cases, vote comes to mind but doing that for all cases might be too annoying

And as for where to put these rules, GH wiki page is probably our best bet as it's publicly visible and easily accessible.

Definitely need to give it more thought but I am curious to hear what others think about it.

Matej

On Thu, May 18, 2023 at 5:01 PM Ladislav Thon <lthon@xxxxxxxxxx> wrote:

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/wiki

Thanks,

LT

_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev