[
https://issues.apache.org/jira/browse/SPARK-55017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tian Gao updated SPARK-55017:
-----------------------------
Description:
*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, allows 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 feedback 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 are 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 care. 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 feedback (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 issues 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 are 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 the 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 significant increase in the number of issues
from the community (other than committers) - that would be the real final goal
for this proposal.
was:
*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.
> 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, allows 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 feedback 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 are
> 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 care. 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 feedback (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 issues 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 are 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 the 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 significant increase in the 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]
