A long one coming I know but hear me out please I know everyone involved here has their day jobs and does this mainly as an advocate for the product, as a hobby, or supporting their own interest so I think it's important to focus on how to make this easier for those involved.
Changing from JIRA to Github would only risk further confusing things as happens when transitioning from bugzilla (https://bz.apache.org/netbeans/) to jira. Discussions can happen in JIRA tickets just as easily as in GitHub and PRs. Having the PR owner drive the "discussion" is the same as a ticket owner driving the ticket discussion. PR discussions seem to me to be focused on the changes made in the PR, not necessarily the higher level discussions for possible solutions of the ticket. The reason there are so many tickets is no one or no group has taken ownership of it (i.e. no change control). I still think some form of "change management team" or "JIRA Triage" team could help here. Is it possible to have a Slack channel for CCB activities or a mailing list? Or even wilder ideas, since less emphasis has been given to LTR and Netcat activities, maybe the Netcat list should be repurposed for some of this change control activity. If a given test case is relevant to a given component and functionality, it can be linked up with that and then when run if it is verified to not be an issue then close it. Seems to mean like there isn't a clear process of how JIRA usage is expected to be used. If there is one, where is it (confluence, Wiki, etc.)? JIRA / Change Process seems like : (1) New ticket is raised by someone (2) (Hopefully) Details on how to reproduce and verify it's closed are clearly defined (3) Ticket is analyzed (i.e. impacted components, priority (4) Someone is assigned, volunteers, or takes ownership of the ticket (5) Someone comes up with a possible fix (6) Someone associated PR to fix (7) Testers (including [1] capability subject matter expert, and [2] the author of the ticket) test the fix and confirm/reject the change (8) If accepted then the ticket is ready to transition to "integration gate" [i.e. can be labels or tagged for a milestones for an upcoming release [maybe "candidate" of some type). (9) Release team can review candidates based on applicable labeled or milestone an evaluate for merging (10) Merged into a release candidate build (11) Beta/Release Candidate/Final Build released for community review (12) Team accepts based on vote (13) Release is released (14) All tickets associated with a given release are "Closed" (15) If an issue is later found to not have been fixed then either "Reopen" the ticket or "Raise a new ticket with more specifics" (goto (1)) There is lots of power in JIRA if it's used. For example * Note: I would share these JIRA searches but I don't have the ability to "Share" filters so will provide a URL based link instead. (1) Find tickets created in the last 7 days project = NetBeans AND created >= -7d <https://issues.apache.org/jira/issues/?jql=project%20%3D%20NetBeans%20AND%20created%20%3E%3D%20-7d> * Would propose with tickets like these they could be "triaged" weekly and set applicable minimum things (i.e. impacted components,priority, potential target releases, complexity, etc.) (2) Tickets which are not closed yet project = NetBeans AND status not in (Closed) <https://issues.apache.org/jira/issues/?jql=project%20%3D%20NetBeans%20AND%20status%20not%20in%20(Closed)> * Can help identify tickets not in "Closed" even those that have been "resolved". * Items resolved and in a build if verified should be "Closeable" (3) Tickets not assigned to anyone project = NetBeans AND assignee is EMPTY <https://issues.apache.org/jira/issues/?jql=project%20%3D%20NetBeans%20AND%20assignee%20is%20EMPTY> * Helps identify who is not actively working on given tickets (4) Tickets not tagged to any components project = NetBeans AND component is EMPTY <https://issues.apache.org/jira/issues/?jql=project%20%3D%20NetBeans%20AND%20component%20is%20EMPTY> * Grouping things by components may help potential similar or related issues * Can group tickets to a given component which can localize issues and allow component exports to be more aware of changes and provide oversite or input on changes for the given component (5) Tickets tagged to a specific component (as an example) project = NETBEANS AND component = "projects - Gradle" <https://issues.apache.org/jira/issues/?jql=project%20%3D%20NETBEANS%20AND%20component%20%3D%20%22projects%20-%20Gradle%22> * See above (6) Tickets created in a specific timeframe (example, those created for 2020) project = NetBeans AND created >= "2020-01-01" AND created <= "2020-12-31" <https://issues.apache.org/jira/issues/?jql=project%20%3D%20NetBeans%20AND%20created%20%3E%3D%20%222020-01-01%22%20AND%20created%20%3C%3D%20%222020-12-31%22> * Can identify tickets creating in a given time frame which can help in identifying when (maybe due to a specific release) or how long tickets have been around (7) Tickets since a specific data sorted by "last" updated data (oldest to newest); this shows what hasn't been worked or updated in a while project = NetBeans AND created >= 2018-01-01 ORDER BY updated ASC <https://issues.apache.org/jira/issues/?jql=project%20%3D%20NetBeans%20AND%20created%20%3E%3D%202018-01-01%20ORDER%20BY%20updated%20ASC> * Can show what tickets have not been actively updated or worked on any way recently. (8) Open tickets with most votes project = NetBeans AND votes > 0 and status not in (Closed) ORDER BY votes DESC <https://issues.apache.org/jira/issues/?jql=project%20%3D%20NetBeans%20AND%20votes%20%3E%200%20and%20status%20not%20in%20(Closed)%20ORDER%20BY%20votes%20DESC> * Can help prioritize tickets based on community input (votes) as to what is most important and needing to be changes or included (9) Open tickets ordered by oldest to newest project = NetBeans AND created >= 2000-01-01 AND status not in (Closed) ORDER BY created ASC <https://issues.apache.org/jira/issues/?jql=project%20%3D%20NetBeans%20AND%20created%20%3E%3D%202000-01-01%20AND%20status%20not%20in%20(Closed)%20ORDER%20BY%20created%20ASC> * Can identify the oldest tickets which have not been closed (see 7). * May identify old tickets which may be OBE by newer tickets (10) Open tickets tagged with Pull Requests project = NetBeans AND labels in ( pull-request-available, pull-requests-available, pull_request_available, pull) and status not in (Closed) <https://issues.apache.org/jira/issues/?jql=project%20%3D%20NetBeans%20AND%20labels%20in%20(%20pull-request-available%2C%20pull-requests-available%2C%20pull_request_available%2C%20pull)%20%20and%20status%20not%20in%20(Closed)> * Can help identify open (not closed) tickets which may have pull requests of some type available with a fix which may be ready to be included in a build if not already included. * Some of these "Resolved" ones may be tagged for a specific Fix Version which may imply they should be closed, unless there is some follow concerns or has not be verified (11) Open tickets with specific text included in the ticket project = NetBeans AND status not in (Closed) and text ~ jdk15 <https://issues.apache.org/jira/issues/?jql=project%20%3D%20NetBeans%20AND%20status%20not%20in%20(Closed)%20and%20text%20~%20jdk15> * Can help to identify similar tickets which may further be grouped together (i.e. group all specific JDK related version tickets if specified in the ticket) to allow focusing on specific needed changes (i.e. need to account for changes made as part of given JDK version [i.e. depricated or removed of specific functionality needing replacement/alternative implementation) (12) Open high priority (blockers, critical, or high) project = NetBeans AND status not in (Closed) and priority in (Blocker,Critical,High) ORDER BY priority DESC <https://issues.apache.org/jira/issues/?jql=project%20%3D%20NetBeans%20AND%20status%20not%20in%20(Closed)%20and%20priority%20in%20(Blocker%2CCritical%2CHigh)%20ORDER%20BY%20priority%20DESC> * identify priority, high important items to help prioritize the work. (13) Open high priority (blockers, critical, or high) with potential pull requests available (or if resolved already applied) project = NetBeans AND status not in (Closed) and priority in (Blocker,Critical,High) and labels in (pull, pull-request-available, pull-requests-available, pull_request_available) ORDER BY priority DESC <https://issues.apache.org/jira/issues/?jql=project%20%3D%20NetBeans%20AND%20status%20not%20in%20(Closed)%20and%20priority%20in%20(Blocker%2CCritical%2CHigh)%20and%20labels%20in%20(pull%2C%20pull-request-available%2C%20pull-requests-available%2C%20pull_request_available)%20ORDER%20BY%20priority%20DESC> * identify priority, high important items with PRs available which may identify possible candidates for merging into a coming build. (14) Items which have been resolved but not yet closed project = NetBeans AND status in (Resolved) <https://issues.apache.org/jira/issues/?jql=project%20%3D%20NetBeans%20AND%20status%20in%20(Resolved)> * Items which have been tagged as resolved but remain open and not yet closed. * This may identify items ready to be closed by applicable person (either the reporter of the item, a subject matter expert, a "CCB Chair", or some other with the power to do so With these defined searches these can further be used in JIRA reports. For example (1) Of the open tickets what is the component distributions [image: image.png] (2) The Netbean ticket current status (Note: this highlight "Resolved" but not "Closed" tickets) [image: image.png] (3) Created vs Resolved tickets [image: image.png] There other improvements that could be made like (1) With JIRA, it's possible to "label" tickets with specific labels. If there is a relevant field more appropriate (i.e. Components) that is preferred but in lieu of that, labels can be very helpful. As an example there was a "Newbie" (can't remember the actual tag but using this as example) type label for tickets (i.e. easy ones to fix for new Netbeans developers). With these labels and the Advanced JIRA search, it was possible to find these, save these as named (and shared) searches which can drive work for new development. (2) The "Vote" options could be used to prioritize future work (although that depends on people committing votes to the tickets) (3) With filtered tickets, it's also possible to do "Bulk" actions (i.e. find all open tickets with pull requests and add a label for given release, find all tickets with specific text within and set components to applicable components,etc.) (4) WIth filter tickets, can iterate through each ticket and review them (say review tickets for the last week to limit scope, update individually, and iterate to the next as needed one by one) (5) I know at one point discuss ways to have some "required fields" (I believe this was driven by development of a "template text" but think additional fields might add value here. I think having a field for "verification" and/or "steps to reproduce" rather than having it embedded in another field (like description) might help in allowing us to determine if something is truly ready to close. I know this is long winded and many will probably not have made it this far but I truly am trying to help in this area. Eric Bresie [email protected] On Sat, Sep 25, 2021 at 11:19 AM Neil C Smith <[email protected]> wrote: > On Sat, 25 Sept 2021 at 08:12, Jaroslav Tulach > <[email protected]> wrote: > > An Apache project like NetBeans doesn't need more incoming bugs, it > needs more > > incoming fixes! > > +1. But we do have something of a bug management issue, particularly > during releases. > > > Enough of sad bitter like-to-be truthful irony. Me and my OracleLabs > > colleagues need to track issues and fixes on many fronts. In the > internal JIRA, > > in the NetBeans JIRA and connect it all with pull requests. > > It would be a little less complicated. If we took the approach that > Airflow have, that scenario would not have an issue at all on the > NetBeans side - pull requests are the primary change record. That > actually seems more in line with the more useful old bugzilla links? > > There's another good follow up from Jarek on how they transitioned and > how they're managing things. I've read a number of good and detailed > posts from Jarek on a variety of infrastructure issues recently. And > looking at how other ASF projects address similar concerns is always > good, even if we end up deciding it's not for us. > > > https://lists.apache.org/thread.html/ra580969453a8491d71b9926d1147de1521dd76f74847a42779186160%40%3Cusers.infra.apache.org%3E > > Shame this is on a list with private archive. I hope selective > quoting is not much of an issue, though - this paragraph seems quite > apt amongst others - > > """ > A lot of issues we had in jira were already > out-dated or of poor quality, so that automatically cleaned up the state of > our issues. I personally think that if it is not obvious that an issue is > really important and if the author of the issue is not interested in adding > extra information if asked or if they are not following up with them - > they are better if they are "forgotten". They add no value to the project, > they only add "noise". This is why I love GitHub discussions so much. We > can convert the issue to GitHub Discussion if we look at it and it is > likely the issue is caused by user error, deployment issue etc. This does > not "close" the issue (which is quite mean) - but it moves the > "responsibility" for the discussion to continue on the author - it's a very > clear sign that the discussion might be left in the state of "discussing > it" and there is no intention or expectation that it will be fixed. And we > can always create an issue from the discussion if we get to the conclusion > this is a real issue. This already happened in the past. > """ > > > Btw. thinking about switching to GitHub Issues shows that Microsoft, > after > > taking over the GitHub, is doing really good job and is re-gaining the > trust > > of open source communities. > > I know, be Oracle next! :-) > > Best wishes, > > Neil > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
