Re: [glassfish-dev] Rationalising the GitHub issues

[arjan tijms <arjan.tijms@xxxxxxxxx>]

Hi,

A few years ago (in 2012) we did something similar for the ridiculously large number of open Mojarra issues. If I remember correctly, all issues first got a comment with a warning asking if the issue was still relevant, and if there was no response 3 weeks later another warning, and if still no response it was closed.

We could do something similar for GlassFish.

There were also tons of issues that were in fact done or closed already, but not properly closed, e.g. issues like this: https://github.com/eclipse-ee4j/mojarra/issues/1036

Kind regards,

Arjan

On Wed, Apr 10, 2019 at 8:20 AM Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:

If the person reviewing the issue isn't convinced that the issue is real, or doesn't know how to reproduce it, and the submitter fails to respond or isn't helpful, then I agree that it's appropriate to close the issue.

I think we should start by closing all the issues filed against earlier releases (again, with a comment saying to reopen it if it can be reproduced on 5.x) and see how big the remaining list is.

Steve Millidge (Payara) wrote on 4/9/19 1:46 AM:

I for one don’t have time to review 3340 issues to determine the merits of each or comment on each so how do we tackle this historical backlog in a way to make it manageable?

 

I agree on your comments RE: test case so how about I soften the proposal a little;

 

1) Team triages the issue and decides whether more information or a test case is required. If no test case or information required mark the issue as Enhancement or Confirmed Bug. Otherwise go to step 2.

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

3) If a test case or response for more information is not provided in 2 weeks remind the reporter of the issue of the need for a response

4) If a test case or response for more information is not provided after 4 weeks remind again

5) If a test case or response for more information is not provided after 6 weeks close the issue commenting that the issue has been closed due to inactivity.

 

My experience of open source is that the number of issues can increase rapidly due to the mismatch between the ease with which an issue can be created and the difficulty required to investigate and close the issue by both parties. In my experience many people register GH accounts just to raise an issue on a project for support but never follow up when asked for more information. We need to ensure that the number of issues is manageable at a sustainable level and that issues where the creator is unresponsive or unhelpful are closed in a fair but rapid fashion.

 

Steve

 

 

From: Bill Shannon <bill.shannon@xxxxxxxxxx>
Sent: 08 April 2019 21:11
To: glassfish developer discussions <glassfish-dev@xxxxxxxxxxx>; Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
Subject: Re: [glassfish-dev] Rationalising the GitHub issues

 

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

 

_______________________________________________
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