[
https://issues.apache.org/jira/browse/SPARK-55017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tian Gao updated SPARK-55017:
-----------------------------
Shepherd: Hyukjin Kwon
> 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
> Priority: Major
>
> *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]
