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

[Andrew Rouse <ANROUSE@xxxxxxxxxx>]

I think the process should depend on the type of issue being raised.

If it's a bug report, (e.g. the spec says something inconsistent) we should be able to decide relatively quickly whether the bug is valid or not and if it is then we probably want to fix it for the next release and shouldn't be closing it after a while if we haven't got around to it. As we come up to a release, we should be checking for any open bug reports.

If it's a new feature proposal, then we first need to decide whether we want the new feature added at all. Just because someone has an idea and is willing to work on it doesn't mean it's a good idea. If the idea is good but no-one is willing to do the work to add it to the spec then I agree we could close it after a while with a note that it can be re-opened if someone wants to work on it.

If it's really just a question about what the spec means it may be something we can just answer, or it may be that we can make the spec itself more clear. These should be quick to close if we're just answering a question but may take longer if there's a spec update to do. We should probably treat them similarly to bug reports.

At a minimum, I think it would be helpful to tag issues with what sort of issue it is so that we can filter them easily and ensure we're not missing small issues which should be included in the next release. It's also much easier to understand why an issue was closed when it's already clear that it's considered an enhancement.

Andrew

-----Original Message-----

From: Matej Novotny <manovotn@xxxxxxxxxx>

Reply-To: cdi developer discussions <cdi-dev@xxxxxxxxxxx>

To: cdi developer discussions <cdi-dev@xxxxxxxxxxx>

Subject: [EXTERNAL] Re: [cdi-dev] lightweight process for handling feature requests, bug reports etc.

Date: 24/05/23 11:54:04

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

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

 

ZjQcmQRYFpfptBannerEnd

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

_______________________________________________

cdi-dev mailing list

cdi-dev@xxxxxxxxxxx

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

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU