I did a quick check and found that there were *492* new ASF Spark JIRA account creation requests in 2025. The extra step of requesting a JIRA account can still be a meaningful barrier—especially for contributors who are already active on GitHub but less familiar with ASF workflows.
+1 to maintaining both ASF JIRA and GitHub Issues. On Thu, Jan 29, 2026 at 11:09 AM Tian Gao via dev <[email protected]> wrote: > First of all, I believe the merge script is another issue that is worth > discussing but not strictly involved in this proposal. I was talking about > potential future benefits for the merge script by migrating our work to > github. On this specific matter, like I said, a github bot would probably > be better than a manual script - we should be able to do whatever we do > with that. The good thing is we can just label the PR (auto-merge) (or a > specific comment like bot merge) and run the bot, instead of setting up a > local environment. > > Back to the real topic. I don't think we should keep two systems stamping > on each other in the long term. But we have a puzzle that we'll never solve > if we bind all PRs to JIRA - how many more contributors we will have if > it's easier for them to contribute code? I don't have a definitive answer > for that and that's what I want to find out. I think the existing > committers will benefit some from a successful migration, but the real > motivation is for people who are not familiar with JIRA or who can't/don't > want to use JIRA. If we can get a significant boost of our community > contribution, I'd say that's worth the trouble. I think many of us are > thinking about this from a committer's perspective (which is natural > obviously), but I was a new contributor 6 months ago and the first thing > that stopped me from contributing was the allowed-user-only JIRA. > > People may argue that almost all recent contributions are from committers > or regular contributors and they are already familiar with JIRA - that's > true, but isn't that also evidence that we should embrace the community a > bit more? > > I think if we support a dual-rail system - it should be an intermediate > phase where we observe if it's worth it for us to migrate to github issues. > If so, it gives us some time to build infra around github issues while > keeping the workflow going. > > Of course, it's possible that this is just some fantasy I have and we > don't get observably more new contributions from the community with github > issues, then we can just use it as a discussion board and feedback channel. > > Tian Gao > > On Thu, Jan 29, 2026 at 5:07 AM Jungtaek Lim <[email protected]> > wrote: > >> The only downside I can think of is future release notes will contain >>> mixed items from Github Issues and JIRAs. >> >> I'm not sure I think this is trivial. IMHO if we want to maintain two >> systems altogether, each system should serve its purpose and not interleave. >> >> For example, allowing Github issues to be an easy entry point for >> questions, making Github issues to serve the major purpose of users@ >> instead of drop-in replacement of JIRA. And for code contributions we still >> require JIRA tickets. This strictly scopes the purpose of both systems. >> >> It doesn't mean I prefer maintaining two systems; I mean let's not leave >> both systems to be active for the same purpose which will bug us in future. >> I don't have a strong opinion to pick one system over another, but I have >> an opinion that we shouldn't end up with compromise and make the infra >> to be a weird state. >> >> Btw I'm not sure Github's squeeze commit in the UI page is a drop-in >> replacement of the merge script e.g. the merge script handles the tricky >> authorship issue via listing up lead-author and co-authors based on the >> author of commits before squeezing. I don't know whether it's supported. >> >> >> On Thu, Jan 29, 2026 at 4:07 PM Wenchen Fan <[email protected]> wrote: >> >>> +1 to maintain both. Why not give contributors a new option with Github >>> Issues? All we need to do is to allow people to create PRs with link to >>> Github Issues, in addition to JIRAs. The only downside I can think of is >>> future release notes will contain mixed items from Github Issues and JIRAs. >>> >>> On Thu, Jan 29, 2026 at 7:22 AM Lisa N. Cao <[email protected]> >>> wrote: >>> >>>> >>>> It would make it easier for the community to see the progress of >>>> features, but there is some work involved to maintain both. >>>> >>>> -- >>>> LNC >>>> >>>> >>>> On Wed, Jan 28, 2026 at 3:10 PM Tian Gao via dev <[email protected]> >>>> wrote: >>>> >>>>> I'm okay with not retiring JIRA, but if we only allow PRs with JIRA >>>>> tickets, we still have the same issue - the new contributors can't work on >>>>> any problems without access to JIRA. >>>>> >>>>> Yes, opening issue tabs will help with community feedback, but I don't >>>>> think we get full benefit from it if we restrict it to be a "discussion >>>>> only" place. The community of spark is not only users, but also occasional >>>>> contributors. >>>>> >>>>> If we worry about the dramatic migration from JIRA, we can open github >>>>> issues, and start building infra around it, while keeping the old system >>>>> working. If we see a trend of committers using github issues more often, >>>>> that's an indicator that people like github integration more than the >>>>> existing JIRA system. >>>>> >>>>> Yes, migrating to github issues means we probably need to throw away a >>>>> bunch of scripts for JIRA, but some of them are not necessary in the first >>>>> place if we use github issues. For example, linking issues to PRs is a >>>>> native supported feature in github. Github supports "squash-only" merge so >>>>> people won't accidentally merge PRs with all the commit history. Github >>>>> also supports "using PR description as commit message". >>>>> >>>>> Even if we do want extra flexibility, github bots have the advantages >>>>> of authentication. For example, if I understand correctly, committers need >>>>> their JIRA token to make the current merge script work - that won't be >>>>> necessary if we use github. Github issues can be closed automatically when >>>>> a linked PR is merged (with close #number) or a github bot can easily do >>>>> that. >>>>> >>>>> Therefore, if we don't want to close JIRA, I'm totally fine with a >>>>> dual-rail system which allows users to submit a PR based on a github >>>>> issue, >>>>> instead of a JIRA ticket. We can do that gradually and polish up all the >>>>> infra required for github issues. Then we can make a decision whether to >>>>> migrate completely. >>>>> >>>>> Tian Gao >>>>> >>>>> On Wed, Jan 28, 2026 at 2:47 PM Dongjoon Hyun <[email protected]> >>>>> wrote: >>>>> >>>>>> -1 because I don't think we should move from the existing one (ASF >>>>>> JIRA) to a new one (GitHub Issues) completely to meet the suggested >>>>>> ideas. >>>>>> It sounds like a little overkill for the goals. They can be used more >>>>>> harmoniously. >>>>>> >>>>>> Specifically, I want to counter-propose a simpler alternative which >>>>>> is used already in some ASF projects: GitHub Issue Tab can be used as an >>>>>> additional preliminary discussion place (receiving issue reports before >>>>>> creating actual JIRA issues). Since this is open to all GitHub users, it >>>>>> already meets the proposed goals. And, there is no reason to abandon ASF >>>>>> JIRA because only worthy ideas will get JIRA IDs after closing duplicated >>>>>> issues or naive Spark questions from GitHub Issue tabs. >>>>>> >>>>>> We can build a better layered issue reporting system by getting all >>>>>> the benefits of the existing ASF JIRA infra and GitHub Issue Tab instead >>>>>> of >>>>>> wasting lots of the community resources due to the drastic migration (or >>>>>> abandoning the established system, script, practices). >>>>>> >>>>>> > I think we should move from JIRA to github issues for >>>>>> > * more feedback from community >>>>>> > * lower barrier to entry for new contributors >>>>>> > * better integration with the whole github eco-system >>>>>> >>>>>> Dongjoon. >>>>>> >>>>>> >>>>>> On 2026/01/27 14:57:00 Bjørn Jørgensen wrote: >>>>>> > Github use mentioned instead of related to >>>>>> > >>>>>> > Like this >>>>>> > [image: image.png] >>>>>> > https://github.com/apache/arrow/issues/48961 >>>>>> > >>>>>> > >>>>>> > tir. 27. jan. 2026 kl. 14:58 skrev Nicholas Chammas < >>>>>> > [email protected]>: >>>>>> > >>>>>> > > One thing GitHub Issues doesn’t have a native equivalent to are >>>>>> issue >>>>>> > > links. GitHub will extract mentions of other tickets and >>>>>> highlight them in >>>>>> > > the side bar, but on Jira you can just link a ticket to another >>>>>> one >>>>>> > > directly. >>>>>> > > >>>>>> > > Example: https://issues.apache.org/jira/browse/SPARK-28024 >>>>>> > > >>>>>> > > [image: Screenshot 2026-01-27 at 8.55.28 AM.png] >>>>>> > > >>>>>> > > Not saying this is a blocker. Just calling this out so we can try >>>>>> to >>>>>> > > preserve this information after the migration. >>>>>> > > >>>>>> > > Nick >>>>>> > > >>>>>> > > >>>>>> > > On Jan 26, 2026, at 8:00 PM, DB Tsai <[email protected]> wrote: >>>>>> > > >>>>>> > > +1, the bar for using JIRA is too high—contributors need a >>>>>> PMC/committer >>>>>> > > to create an account. Using GitHub issues would make it much >>>>>> easier for >>>>>> > > people to participate. >>>>>> > > DB Tsai | https://www.dbtsai.com/ | PGP 42E5B25A8F7A82C1 >>>>>> > > >>>>>> > > On Jan 26, 2026, at 2:30 PM, Hyukjin Kwon <[email protected]> >>>>>> wrote: >>>>>> > > >>>>>> > > TBH, if we can manage to migrate all related repos in Apache >>>>>> Spark, I feel >>>>>> > > like it might be a great idea. >>>>>> > > lately I started to actively work on Apache Arrow, and realised >>>>>> that they >>>>>> > > also successfully migrate to GitHub Issues from JIRA for all ther >>>>>> repos. >>>>>> > > >>>>>> > > On Tue, 27 Jan 2026 at 05:49, Tian Gao via dev < >>>>>> [email protected]> >>>>>> > > wrote: >>>>>> > > >>>>>> > >> Hi all, I'd like to start a discussion on a draft SPIP: >>>>>> > >> >>>>>> https://docs.google.com/document/d/1WMaA49hKyu7gtU189fPq4k8TeI-Q73Q6bqSeWAgR3y8/edit?usp=sharing >>>>>> > >> >>>>>> > >> tl; dr >>>>>> > >> >>>>>> > >> I think we should move from JIRA to github issues for >>>>>> > >> * more feedback from community >>>>>> > >> * lower barrier to entry for new contributors >>>>>> > >> * better integration with the whole github eco-system >>>>>> > >> >>>>>> > >> Many apache projects have moved from JIRA to github issues >>>>>> successfully, >>>>>> > >> including Arrow, Airflow, Beam, Maven, Lucene ... Actually most >>>>>> of apache >>>>>> > >> projects are using github issues now, with a few exceptions >>>>>> including spark. >>>>>> > >> >>>>>> > >> I'd like to hear more about this proposal from the community. >>>>>> > >> >>>>>> > >> Thanks! >>>>>> > >> >>>>>> > >> Tian Gao >>>>>> > >> >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > >>>>>> > -- >>>>>> > Bjørn Jørgensen >>>>>> > Vestre Aspehaug 4, 6010 Ålesund >>>>>> > Norge >>>>>> > >>>>>> > +47 480 94 297 >>>>>> > >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe e-mail: [email protected] >>>>>> >>>>>>
