Tian Gao created SPARK-55017:
--------------------------------
Summary: SPIP: Migrate from JIRA to Github issues
Key: SPARK-55017
URL: https://issues.apache.org/jira/browse/SPARK-55017
Project: Spark
Issue Type: Umbrella
Components: Project Infra
Affects Versions: 4.2.0
Reporter: Tian Gao
*Q1.* What are you trying to do? Articulate your objectives using absolutely no
jargon.
I propose to migrate from our current JIRA system to Github issues. All the
existing tickets will be transferred to github issues and the current JIRA will
be read-only and archived.
*Q2.* What problem is this proposal NOT designed to solve?
The usage of other github features, for example, allowing using github UI to
merge instead of using a merge script.
*Q3.* How is it done today, and what are the limits of current practice?
We are currently using JIRA, and we have some issues.
# The bar is too high for new contributors to involve in spark's development
because
** They can't register an account without a PMC's explicit confirmation
** They are not familiar with how JIRA works
** They don't even know JIRA exists, they are only familiar with github issues
# Discussions on tickets are limited because people don't switch between
websites (and of course, new comers can't comment)
# We are missing feedbacks from the community because it's not easy for them
to report issues.
*Q4.* What is new in your approach and why do you think it will be successful?
I propose that we use native github issues, which is the single mostly used
ticket system in the software world. We are using github to host our repos, to
do PRs (mostly) and to run CIs already - adding issues to the list should be
very intuitive.
Also, a lot of Apache projects are moving to github issues. Arrow for example.
[https://github.com/apache/arrow/issues/14542] . Lucene, Beam and many other
projects are also on the list. I have not seen a project that went the other
direction. Github issues are also in active development and is becoming better.
*Q5.* Who cares? If you are successful, what difference will it make?
I think most importantly, people who don't own a JIRA account cares. This might
not be too critical for our regular committers, but it will benefit the users
and new contributors a lot. The first time I tried to contribute to spark, I
was scared away because of the JIRA ticket system.
If we take a look at our existing tickets, they are mostly placeholders for
tasks that committers plan to do - but for most active open source projects, it
should be feedbacks (bug reports, feature requests, etc.) from the community.
This is because of the artificial bar we have for the community.
*Q6.* What are the risks?
Migration is not risk-free, I'll list all the issue I can think of.
* Migration itself takes time and effort. There could be some disruption
during the migration
* We can't "duplicate" a JIRA system. Github issues is different. For example
** it does not have native "types" for each issue - it uses tags to categorize
issues.
** it has sub-issue system, but might not be as polished as JIRA
** it lacks many fields JIRA has, like fixed-version or component, they all
need to be done with tags.
** it does not have "OrderBy" feature
* Even though we will migrate all JIRA tickets to github, we will miss some
information that is not easily migrated.
* We need to rewrite some bots for github issues
*Q7.* How long will it take?
I think it will take about 1-2 months.
# Create an issue template, then open issues tab. (< 1w)
# Start working on equivalent bots to link github PRs to github issues. During
this time, committers still work on JIRA. (~1w)
# Allow work on github issues, while keeping JIRA available - this phase is to
test the github bots and see if we have any issues with the new system. (2w -
can be extended if we don't feel ready)
# Convert JIRA to read-only mode, migrate all Jira tickets to github (there
are scripts for this, used by arrow/beam, should not be too hard). (1-2w).
# Observe how people work on the new system. If we have major issues, we can
revert back to JIRA. (We consider this project done at this phase)
# Remove the JIRA bot when everything is stable.
*Q8.* What are the mid-term and final “exams” to check for success?
mid-term success is that people can work with github issues regularly. We have
set up all the necessary tools for github issues. If we heard few to none
complaints from committers, that's good.
final success is that we fully migrate to github issues and JIRA is not being
used. More importantly, I expect us to see much more feedback from the
community. I think we should see a significantly increase in number of issues
from the community (other than committers) - that would be the real final goal
for this proposal.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
