Hi,
for complete clarity, can we sum up which features of Jira we actually
do use and how would those be mapped onto the functionality provided by
GH issues? Questions from the top of my head:
- do we use nested issues/sub-issues? If yes, how would we map those
on GH issues?
- do we use other Jira relations (depends on, blocks, is blocked by,
is duplicated by, ...) and if yes, do we want to preserve those?
- which fields of Jira (component, type, priority, affected and fixed
version, ...) do we use and how do we map those on GH?
- are we going to preserve reporter and assignee (if any)? Do we have
mapping from Jira ID to GH ID?
I'm generally +1 to the transition, as fewer systems is always better,
but we should be sure of the real impact.
Jan
On 12/8/21 01:38, Jarek Potiuk wrote:
Do I understand correctly that this transition (if it will happen) includes the
transfer of all Beam Jira archive to GitHub issues with a proper
statuses/comments/refs/etc? If not, what are the options?
Suggestion from the experience of Airflow again - you can look it up
in our notes.
We've tried it initially to copy the issues manually or in bulk, but
eventually we decided to tap into the wisdom and cooperation of our
community.
We migrated some (not many) important things only and asked our users
to move the important issues if they think they are still
relevant/important to them. We closed the JIRA for entry and left the
issues in JIRA in read-only state so that we could always refer to
them if needed.
So rather than proactively copy the issues, we asked the users to make
the decision which issues are important to them and proactively move
it and we left an option of reactive moving if someone came back to
the issue later.
That turned out to be a smart decision considering the effort it would
require to smartly move the issues vs. the results achieved. And
helped us to clean some "stale/useless/not important" issues.
We've had 1719 open JIRA issues when we migrated. Over the course of
~1.5 years (since about April 2020) we've had ~140 issues that refer
to any of the JIRA issues
https://github.com/apache/airflow/issues?q=is%3Aissue+is%3Aclosed+%22https%3A%2F%2Fissues.apache.org%2Fjira%22+.
Currently we have > 4500 GH issues (3700 closed, 800 opened).
This means that roughly speaking only < 10% of original open JIRA
issues were actually somewhat valuable (roughly speaking of course)
and they were < 5% of today's numbers. Of course some of the new GH
issues duplicated those JIRA ones. But not many I think, especially
that those issues in JIRA referred mostly to older Airflow versions.
One more comment for the migration - I STRONGLY recommend using well
designed templates for GH issues from day one. That significantly
improves the quality of issues - and using Discussions as the place
where you move unclear/not reproducible issues (and for example
guiding users to use discussions if they have no clearly reproducible
case). This significantly reduces the "bad issue overload" (see also
more detailed comments in
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632).
I personally think a well designed issue entry process for new issues
is more important than migrating old issues in bulk. Especially if you
will ask users to help - as they will have to make a structured entry
with potentially more detailed information/reproducibility) or they
will decide themselves that opening a github discussion is better than
opening an issue if they do not have a reproducible case. Or they will
give up if too much information is needed (but this means that their
issue is essentially not that important IMHO).
But this is just friendly advice from the experience of those who did
it quite some time ago :)
J.
On Wed, Dec 8, 2021 at 1:08 AM Brian Hulette <[email protected]> wrote:
At this point I just wanted to see if the community is interested in such a
change or if there are any hard blockers. If we do go down this path I think we
should port jiras over to GH Issues. You're right this isn't trivial, there's
no ready-made solution we can use, we'd need to decide on a mapping for
everything and write a tool to do the migration. It sounds like there may be
other work in this area we can build on (e.g. Airflow may have made a tool we
can work from?).
I honestly don't have much experience with GH Issues so I can't provide
concrete examples of better usability (maybe Jarek can?). From my perspective:
- I hear a lot of grumbling about jira, and a lot of praise for GitHub Issues.
- Most new users/contributors already have a GitHub account, and very few
already have an ASF account. It sounds silly, but I'm sure this is a barrier
for engaging with the community. Filing an issue, or commenting on one to
provide additional context, or asking a clarifying question about a starter
task should be very quick and easy - I bet a lot of these interactions are
blocked at the jira registration page.
Brian
On Tue, Dec 7, 2021 at 9:04 AM Alexey Romanenko <[email protected]>
wrote:
Do I understand correctly that this transition (if it will happen) includes the
transfer of all Beam Jira archive to GitHub issues with a proper
statuses/comments/refs/etc? If not, what are the options?
Since this transfer looks quite complicated at the first glance, what are the
real key advantages (some concrete examples are very appreciated) to initiate
this process and what are the show-stoppers for us with a current Jira workflow?
—
Alexey
On 6 Dec 2021, at 19:48, Udi Meiri <[email protected]> wrote:
+1 on migrating to GH issues.
We will need to update our release process. Hopefully it'll make it simpler.
On Sat, Dec 4, 2021 at 2:35 AM Jarek Potiuk <[email protected]> wrote:
Just to add a comment on those requirements Kenneth, looking into the
near future.
Soon GitHub issues will open for GA a whole new way of interacting
with the issues (without removing the current way) which will greatly
improve iI think all aspects of what You mentioned). The issues (and
associated projects) will gain new capabilities:
* structured metadata that you will be able to define (much better
than unstructured labels)
* table-like visualisations which will allow for fast, bulk,
keyboard-driven management
* better automation of workflows
* complete APIs to manage the issues (good for GitHub Actions
integration for example)
Re: assigning by non-committers is one of the things that won't work
currently. Only comitters can assign the issues, and only if a user
commented on the issue. But it nicely works - when a user comments "I
want to work on that issue", a committer assigns the user. And It
could be easily automated as well.
You can see what it will is about here: https://github.com/features/issues
They are currently at the "Public Beta" and heading towards General
Availability, but it is not available to "open" projects yet. However
I have a promise from the GitHub Product manager (my friend heads the
team implementing it) that ASF will be the first on the list when the
public projects will be enabled, because it looks like it will make
our triaging and organisation much better.
J.
On Sat, Dec 4, 2021 at 1:46 AM Kenneth Knowles <[email protected]> wrote:
This sounds really good to me. Much more familiar to newcomers. I think we end
up doing a lot more ad hoc stuff with labels, yes? Probably worth having a
specific plan. Things I care about:
- priorities with documented meaning
- targeting issues to future releases
- basic visualizations (mainly total vs open issues over time)
- tags / components
- editing/assigning by non-committers
- workflow supporting "needs triage" (default) -> open -> resolved
I think a lot of the above is done via ad hoc labels but I'm not sure if there
are other fancy ways to do it.
Anyhow we should switch even if there is a feature gap for the sake of
community.
Kenn
On Fri, Dec 3, 2021 at 3:06 PM David Huntsperger <[email protected]>
wrote:
Yes, please. I can help clean up the website issues as part of a migration.
On Fri, Dec 3, 2021 at 1:46 PM Robert Burke <[email protected]> wrote:
Similar thing happened for Go migrating to use GH issues for everything from
Language Feature proposals to bugs. Much easier than the very gerrit driven
process it was before, and User Discussions are far more discoverable by users:
they usually already have a GH account, and don't need to create a new separate
one.
GitHub does seem to permit user directed templates for issues so we can
simplify issue triage by users: Eg for Go there are a number of requests one
can make: https://github.com/golang/go/issues/new/choose
On Fri, Dec 3, 2021, 12:17 PM Andy Ye <[email protected]> wrote:
Chiming in from the perspective of a new Beam contributor. +1 on Github issues.
I feel like it would be easier to learn about and contribute to existing
issues/bugs if it were tracked in the same place as that of the source code,
rather than bouncing back and forth between the two different sites.
On Fri, Dec 3, 2021 at 1:18 PM Jarek Potiuk <[email protected]> wrote:
Comment from a friendly outsider.
TL; DR; Yes. Do migrate. Highly recommended.
There were already similar discussions happening recently (community
and infra mailing lists) and as a result I captured Airflow's
experiences and recommendations in the BUILD wiki. You might find some
hints and suggestions to follow as well as our experiences at Airflow:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632
J,
On Fri, Dec 3, 2021 at 7:46 PM Brian Hulette <[email protected]> wrote:
Hi all,
I wanted to start a discussion to gauge interest on moving our issue tracking
from the ASF Jira to GitHub Issues.
Pros:
+ GH Issues is more discoverable and approachable for new users and
contributors.
+ For contributors at Google: we have tooling to integrate GH Issues with
internal issue tracking, which would help us be more accountable (Full
disclosure: this is the reason I started thinking about this).
Cons:
- GH Issues can't be linked to jiras for other ASF projects (I don't think we
do this often in jira anyway).
- We would likely need to do a one-time migration of jiras to GH Issues, and
update any processes or automation built on jira (e.g. release notes).
- Anything else?
I've always thought that using ASF Jira was a hard requirement for Apache
projects, but that is not the case. Other Apache projects are using GitHub
Issues today, for example the Arrow DataFusion sub-project uses GitHub issues
now [1,2] and Airflow migrated from jira [3] to GitHub issues [4].
[1] https://lists.apache.org/thread/w3dr1vlt9115r3x9m7bprmo4zpnog483
[2] https://github.com/apache/arrow-datafusion/issues
[3] https://issues.apache.org/jira/projects/AIRFLOW/issues
[4] https://github.com/apache/airflow/issues
