| Re: [che-dev] Issue tracking, triage, and sprint planning: is there a better option? |
+1 for -1 on changing the bug tracker :)
I can see the appeal for moving to JIRA and I fully agree it both is more
capable and has better UX than github issues but I share Florent's sentiment.
Having the code and issue tracker in one system is IMHO great for community
involvement (not having to register in yet another tool, even if is just
through github sso) and for automatic crosslinking (we are split across many
github projects now and having the crosslinking between the issues in eclipse/
che and PRs open across several repos is very valuable for my personal daily
work).
That said, I know of projects like Debezium that do have issue tracking in
JIRA and code/PRs on github and at the same time have an active community.
Maybe it would be good to ask them how they manage the integration and the
pros and cons they trade?
On Wednesday, February 17, 2021 8:38:24 AM CET Florent Benoit wrote:
> I like to have the tracker where the code/pull requests are and where most
> developers already have an account to submit new issues / cross-linking
> issues, etc. (not yet another account)
>
> So I'm -1 to use another tracker than github issue tracker for this even if
> there are some missing features in the tracker.
>
> On Wed, Feb 17, 2021 at 4:59 AM Nick Boldt <nboldt@xxxxxxxxxx> wrote:
> > A topic raised recently in a retrospective brought to light the fact that
> > there are some features missing in GH Issues, which are implemented in
> > other issue trackers.
> >
> > Some of these features involve...
> >
> > * improving notifications of new issues by component (eg., Che server or
> > Che dashboard) or by team/area label
> > * improving triage by assigning new issues to team leads instead of via
> > round-robin by non-SMEs
> > * improving metadata (milestones, new¬eworthy, severity, priority) set
> > on issues, to make it easier to do project/product releases
> > * reducing manual steps involved in triage, prioritization, sprint
> > planning, and handling of unplanned urgent issues
> > * querying for issues closed across multiple milestones, labels, and/or
> > team assignees
> > * identifying resolved issues (fix is merged) vs. verified issues (fix
> > exists in a built binary and has been tested to work)
> >
> > Here's a quick comparison of how some of the above concerns might be met
> > by using a more feature-rich tracker:
> >
> >
> > https://docs.google.com/document/d/1FJCqjzuQKLm-b00tmCJtvXHbOIzsqzZdlOZBz1
> > VGayc/edit#
> >
> > Maybe it's time to consider using a different tool? If the Eclipse
> > Foundation can move from bugzilla and gerrit to gitlab, maybe we could
> > consider continuing to use Github for pull requests and code, but try JIRA
> > for its project management features? We already centralized all issues
> > into
> > a single tracker -- could we take it to the next level?
> >
> > What do other community members think of this idea? Any technical reasons
> > why this couldn't work?
> >
> > [image: image.png]
> > ;)
> > --
> >
> > Nick Boldt
> >
> > Principal Software Engineer, RHCSA
> >
> > Productization Lead :: CodeReady Workspaces
> >
> > IM: @nickboldt / @nboldt / http://nick.divbyzero.com
> > <https://red.ht/sig>
> > TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
> > @ @redhatnews <https://twitter.com/redhatnews> Red Hat
> > <https://www.facebook.com/RedHatInc>
> > <https://www.facebook.com/RedHatInc>
> >
> >
> > “The Only Thing That Is Constant Is Change” - Heraclitus
> > _______________________________________________
> > che-dev mailing list
> > che-dev@xxxxxxxxxxx
> > To unsubscribe from this list, visit
> > https://www.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev