Sorry, csn you consider rambling less, responding to threads a lot less, and formulating your thoughts more concisely? You risk people skipping over your lengthy responses and your effort being wasted.
Gj On Sat, 4 Dec 2021 at 16:39, Eric Bresie <[email protected]> wrote: > More ramblings... > > I lean towards #2 but am also not opposed to #1 as it does provide a nice > alternative. > > I’ve tried to show my thoughts on #2 in past responses (i.e. use targeted > filters to show areas of work/improvement [i.e. items still open, items per > domain, etc.], the dashboards [showing graphical view of issue state], auto > link [linking JIRA to PRs], change control, tribes/subgroups/domain > experts, etc.) > > I still think there needs to be a "#5 Establish, document, and use a > process to manage the issues" that should be addressed. > > Right now it seems like there is no organized “change control” management > and is more a “bazaar” (1) type environment (i.e. which can be beneficial > but can also be a “chaotic” environment with lots of people involved each > doing their own thing in their own ways). The best integrated issue, CM, > and discussion tool in the world is only as good as the “process” to manage > it. Otherwise, it’s like “wrangling cats” (2) ;-) > > Drilling down some... > > If going with #1, what happens to all the existing tickets? Do they > > 1. Migrate over all the items to GitHub (i.e. and may now have old JIRA > and new Github issue ids)? Assume doing this may result in a lot of > duplicate or already completed tickets. > 2. Migrate subsets of items (which is a big task of determining which > ones do or do not get migrated - maybe can have everyone "vote" in each > JIRA ticket to focus the tickets of interest and the ones with most > votes > gets addressed) > 3. Migrate tickets over as they are worked? If someone sees one in JIRA > then migrate over to Github issue and start working on it) > 4. Make JIRA read only? (although then have the risk of "old open > tickets in JIRA" perceived as "still open"; see bugzilla tickets) > 5. Start over (ignoring all the tickets - many of which may have been > migrated from Bugzilla to JIRA > 6. What happens to the "history" of the issues? In other words, if > there was a issue identified in bugzilla which may or may not have been > fixed and migrated to jira which may or may not have been fixed in that > timeframe, and then a regression of the issue arises, assume would have > to > link to one or more of the places and history likely the most recent > ticket) > > What is the goal and/or the problems attempted to be resolved here and why > does the problem exist? If the problem is > > 1. “The tools do not integrated well” (i.e. PRs not always linked to > tickets or discussions) then > 1. Improving existing integration (auto link) may help to allow > "click to issue" or "click to PR" > 2. Stop using one tool and adding new tools (GitHub issues and/or > Discussion) may help but this does adds more variable to the mix and > may > not necessarily address other aspects of the problems > 2. “Discussions occurring in multiple, disjointed places”. > 1. Discussions occur either in one or more places like the > 1. JIRA tickets, > 2. Mailing list (user or dev), > 3. Slack discussions (Netbeans, foojay), > 4. Telegraph discussion, > 5. PRs themselves. > 6. IRC (not sure if this is still really active but maybe) > 7. Documentation/Wiki pages (more an issue of documentation rather > than issue but there could be a small bit of discussions here) > 2. Adding GitHub discussion adds just another place where discussions > may happen (granted others may and could go away but still there will > be lots of places to discuss still). > 3. Everyone has their personal favorite (i.e. vi, emac, NB, etc.) or > preferred way of communicating (i.e. mailing list, PR, git, > chat, etc.) so agreeing > to where discussions should happen may help and or when to move from > one > "channel of communication" to another (i.e. initial discuss brought > up in > mailing list, issue raised [JIRA or Github Issue], discussion occurs > on > issue, PR developed and further discussion against PR [not > necessarily the > issue but the code changes], etc.) > 4. There may be some overlaps here (i.e. git and/or JIRA emails , > updates to given stack channel, JIRA tickets updates sent to emails, > discussions on mailing list + JIRA ticket + PR discussions, > etc.) that may > also need to be considered > 3. “Having tons of JIRA tickets not being fixed” > 1. Assume this is mainly because > 1. No one is working on them > 2. Don’t have the time or the interest to work, > 3. Issues have been fixed but not closed out yet > 4. Issues are no longer issues (i.e. fixed as part of some other > work and not linked up and closed) > 5. Issues are against legacy issues (i.e. against an old version > of netbeans like 8.2 or earlier) > 6. Understanding the "process" (i.e. where [where to discuss], > what to do, how to do it, and who does it [i.e. who is > responsible for > closing a given ticket, release manager, author, person that > raised the > issue, etc.) is too complicated > 2. Migration to yet another tool while it may help integrate the > discussion and interaction some, may still not truly solve this > problem. Think this requires a little more process and governance > > I know “processes” may be a dirty word for some and may mean extra work > that no one really likes to do to others, but a documented process (i.e. > #5) may help in a lot of places here > > 1. When established may make bringing in new people and helping them to > understand may be easier, rather than just keep saying on the mailing > list > things like “raise an issue”, “find someone interested to work the > issue”, > “take on the work”, ”do the work on the issue”, ”provide a PR”, etc. > 2. Focus the work (i.e. the tribes or domain experts can focus on the > relevant tickets, seeing where issues are and find possible design > improvements to resolve, etc.) > 3. By having a defined close out process this may help in "pruning" > and/or "cleaning up" to help reduce the tickets. > 4. Some of this process may also have to consider other process like (1) > Apache processes, (2) Netbeans process, and (3) Stakeholder processes > (i.e. > Oracle [i.e. donation of code] or anyone actively driving/funding work) > > Should add to this, this doesn’t even consider concerns about aspect (i.e. > licensing, IP, agreements, and infrastructure concerns) but that's another > discussion as well > > Eric > > References > > 1. https://en.m.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar > 2. https://youtu.be/07EQ_7lDASs > > > ------------------------------ > *From:* Geertjan Wielenga <[email protected]> > *Sent:* Saturday, December 4, 2021 7:11:38 AM > *To:* [email protected] <[email protected]> > *Subject:* Re: Apache JIRA vs GitHub issues / discussions > > #1 for me too, it’s the no nonsense common sense approach and personally I > feel this project is unsustainable over the longterm if we encourage people > to think they’ve contributed anything at all when filing a JIRA issue > poorly and never return to answer questions about steps to reproduce. > > The GitHub discussion approach entails that filing an issue is just the > starting point of engagement as well as ownership. > > Dumping the thousands of issues with people complaining and not > contributing is the right way to go — those that truly care will pick up > their discussion on GitHub. > > We should formally announce that we’re no longer accepting issues, just > discussions, in which the reporter owns what they report on, from the start > to the end (i.e., testing) of the process. > > Gj > > On Sat, 4 Dec 2021 at 04:12, Vano Beridze <[email protected]> wrote: > > > #1 is the way to go > > > > On Fri, Dec 3, 2021, 6:13 PM Nicola Ken Barozzi <[email protected]> > > wrote: > > > > > Having started recently with the community, I would go with #1. > > > > > > The more the system is integrated and evident in how it works > > > together, the easier it is for others to contribute. > > > > > > > > > On Fri, Dec 3, 2021 at 12:19 PM Neil C Smith <[email protected]> > > > wrote: > > > > > > > > On Thu, 23 Sept 2021 at 15:42, Neil C Smith <[email protected]> > > > wrote: > > > > > I've long felt that our use of JIRA and poor integration with the > PR > > > > > process, etc. is more of a hindrance than a help, particularly > during > > > > > releases. > > > > > > > > Thanks everyone who has input here. Now 12.6 is out (just about) and > > > > branching for 13 is knocking on the door in mid-January, it would be > > > > good to wrap this discussion up into a plan that we can put in place > > > > by then. > > > > > > > > I think we have four options - > > > > > > > > 1. Move to GitHub issues, porting Airflow's model, configuration and > > > > automation, adapting where needed - > > > > > > > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632 > > > > > > > > 2. Stick with JIRA, but seek to address the sync issues between the > > > > two systems, including PRs, milestones, assignees, etc. As well as > > > > issue templates, removing access to fields like priorities, etc. from > > > > users? Add automation? Potentially make sure all PRs have a valid > > > > ticket? > > > > > > > > 3. Stick with JIRA as configured now. > > > > > > > > 4. Ignore JIRA issues entirely as part of the release process. > > > > > > > > > > > > I've made no secret I'm in favour of #1. And I'm happy to put some > > > > time into making that happen. Maybe others too? > > > > > > > > If #2, then some one/group needs to make that happen, and outline > how, > > > > liaise with infra@ if needed, etc. Who's up for it? Is it actually > > > > doable? Happy to help here too, but it's going to be a lot more > > > > limited. > > > > > > > > Neither #3 or #4 feel tenable to me, although we're getting closer to > > > > #4 each release. If you're in favour of #3, thanks for offering to > > > > take on the next release though! ;-) > > > > > > > > Is there a #5? > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > -- > > > Nicola Ken Barozzi [email protected] > > > - verba volant, scripta manent - > > > discussions get forgotten, just code remains > > > > > > --------------------------------------------------------------------- > > > 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 > > > > > > > > > > > > > > >
