For the "Others", they have components defined but there appear to be soooooo many components, that it's only showing the "big hitters" with a larger number for the given component category. I wonder if maybe reducing the number to a smaller one or have a "top level" component would help (i.e.Java, Gradle, Javascript, etc.) with a manager for that top level category and then also break it down further if needed (i.e. Javascript - Editor, Javascript - Libraries, etc.).
Maybe model after the Netcat tribes like (See https://netbeans.apache.org/participate/netcat.html). Maybe that is a new direction for Netcat groups to monitor specific "tribe" based areas to help in triage as well. PrefixTribe [rcp] API Support [cnd] C/C++ [db] Databases [debugger] Debugger [editor] Editor [groovy] Groovy [form] GUI Builder [j2ee] Java EE [fx] Java FX [maven] Maven [php] PHP [profiler] Profiler [unit] Unit Testing [versioning] Version Control [web] Web Client Eric Bresie [email protected] On Thu, Nov 11, 2021 at 10:34 AM Eric Bresie <[email protected]> wrote: > > Eric Bresie > [email protected] > > > On Thu, Nov 11, 2021 at 9:56 AM Neil C Smith <[email protected]> > wrote: > >> On Thu, 11 Nov 2021 at 15:44, Michael Bien <[email protected]> wrote: >> > I do like the github issue tracker since it appears to be simpler while >> > still doing its job. To keep an issue tracker useful, it does need >> > maintenance though. E.g many projects automatically close issues if they >> > are inactive for a certain amount of time. Having 32k open issues on >> > jira like NB has, is no longer observable. >> > >> > Many "critical" issues i commented on asking if its still a problem were >> > in fact already fixed. This has to be automated, nobody should have to >> > do that manually. If the original poster cares about the issue and its >> > closed by mistake, believe me, it will be reopened. >> > >> > >> > i am for github issues, but someone would actually have to write the >> > templates, and then also try to automate things, otherwise it will be >> > jira 2.0 in a year or two. >> >> Absolutely! I'm basically saying let's follow what Airflow are doing, >> and tweak where needed, rather than do this from scratch. They're an >> ASF project that seemed to have the problems we have, and seem to have >> addressed it in a way that we could use as a model - forms, >> automation, etc. included. >> >> I'm for doing this for the same reason I was for ditching LTS - it's a >> promise to our users we're not keeping. It feels worse than useless >> right now - 32k open issues is just a black hole for users to vent >> their frustrations into. We really need fewer, better quality issue >> reports. So, why not see if we can learn from other ASF projects who >> have been through this? It can't be worse! :-) >> >> > Regarding quality reports, see my earlier emails about filters, > dashboards, reports, etc. > > Having filters showing assorted results like open issues. > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20NetBeans%20AND%20status%20not%20in%20(Closed)%20 > > I think the JIRA Dashboards provide some of the quality issue reports > being looked for to provide some guidance.. > > I unable to to Share my personalized Netbeans dashboad so not sure this > will be visible or not but with a dashboard like > https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333642 > > > From that you can drill down to the given linked element (i.e. components, > status, etc.) where applicable > > [image: image.png] > > And most importantly, triage for the open issues. > > (1) Break the list up into smaller subsets of issues (i.e. by components - > see dashboard example) > (2) Although a majority of these open tickets are not set or set to > "Other" so maybe the first step would be to assign a given ticket to a > component to start with). > (3) Alternative labels (i.e. label as "duplicate", "ready to close", > "reject", "close with no fix", etc) or field could be used to help as well > in the triage process > (4) then have "experts for the given components" could monitor these > and/or provide focus on the components to help the validity of the tickets > (determine if relevant still, OBE, is duplicate, or is fixed and should be > closed) > > It's important to be cautious about closing items after a given time, just > because an issue hasn't been worked on forever, doesn't mean there is not > still an issue and just no one has committed to work on it. > > Eric Bresie > >
