Re: [glassfish-dev] Rationalising the GitHub issues

[Bill Shannon <bill.shannon@xxxxxxxxxx>]

I think you're setting the bar too high.

First, closing issues without looking at them and with no comment is a great way to discourage people from filing issues.  I'm fine with closing issues filed against previous releases with a comment encouraging the submitter to reopen the issue if it still occurs on 5.x.

Encouraging a reproducible test case is good, but sometimes a bug is so trivial that creating a reproducible test case is more work than actually fixing the bug.  While we'd like people to submit pull requests with fixes, sometimes a simple description of the bug is enough to tell someone familiar with the code what needs to be fixed.  At the other extreme, sometimes an issue is so complex that there's no reasonable way to create a reproducible test case.  I think we still want to hear about those issues, however.

We need to allow judgment to be applied on both sides.

If a Committer reviews an issue and determines that a reproducible test case is going to be needed in order to fix the bug, then requesting a test case and following your aging policy might be appropriate.  I would be flexible on the form of the test case.  And I wouldn't close a bug that I believe very likely could be a real bug, just because I didn't have a reproducible test case.

Steve Millidge (Payara) wrote on 4/6/19 2:45 PM:

Hi,

I think we need to rationalise the number of GitHub issues in the GlassFish project. Currently there are 3340 issues many of which are very old and some of which are random support requests.

I suggest we have a major deletion of issues. My suggestions are;

1) Close all issues older than 2 years

2) Close all issues that are for versions of GlassFish prior to 5.x

3) Request a reproducible test case for all bug reports that don't follow the current template

Finally I think we need to create an issue aging policy.

The rules that have worked for me on other projects is;

1) Request a compilable, reproducible test case hosted in GitHub as a maven project or detailed steps to reproduce if a test case is not appropriate.

2) If a test case is not provided in 2 weeks remind the reporter of the issue of the need for a test case

3) If a test case is not provided after 4 weeks remind again

4) If a test case is not provided after 6 weeks close the issue.

Thoughts everybody?

Steve

_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/glassfish-dev