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
> >
> >
> >
> >
>
