Thanks Sean for taking care of the JIRA account requests! I feel guilty that I almost never look at these requests...
I did some data analysis: in Spark 4.1.0 we resolved *1865* tickets, *1077(57.75%)* of them have no description, *1515(81.23%)* of them only has a bot comment saying PR for it has been merged. For the rest, LLM detected that some comments are not meaningful discussion, such as "PR for this ticket ...", "This is backported to ...", "working on it", etc. Only *128 tickets (6.86%)* have actual discussion. It seems to me that JIRA is mostly a procedure overhead. It also matches my personal experience: most discussions happen in the dev list and PRs. Even if we enable Github Issues, will people discuss within it? How do other open source projects manage their PRs? On Fri, Jan 30, 2026 at 10:14 AM Szehon Ho <[email protected]> wrote: > +1 (non binding) for github issue. It'd be great to reduce the small but > continuous duplicate work to fill out information in the JIRA and github > issue/pr for every contribution. For new users, it also does seem a pain > to request the JIRA account , and for PMC to approve each one. > > Thanks > Szehon > > On Thu, Jan 29, 2026 at 11:52 AM Tian Gao via dev <[email protected]> > wrote: > >> > It'd be super confusing to people that are not using these day to day >> to see both. Where should they be reporting bugs? Where should they search? >> If there are duplications, there's not even a structured way to link them. >> >> I would imagine that if github issues are available, normal users would >> just use that to report bugs. It does not quite make sense for them to go >> to JIRA to report stuff if they can just do it on github. Searching is an >> issue if we do not sync both sources. That's an advantage for a >> full migration (or no migration at all). Still, I think we should >> eventually move to github (if we start from scratch, will we use github >> issues or JIRA?). >> >> Also interesting thoughts about linking - github supports bidirectional >> links once you mention a PR/issue in another. JIRA kind of supports this to >> github PRs, but requires a bot. The nice thing about the github links is >> that it also supports preview and popup in their UI (well it's native). >> >> My belief is to migrate to github issues and give up JIRA, but I >> understand that people have concerns about benefit vs cost, so I think an >> intermediate phase to have both could be helpful to the eventual goal. >> >> Tian Gao >> >> On Thu, Jan 29, 2026 at 11:40 AM Gengliang Wang <[email protected]> wrote: >> >>> I checked the 2025 data: out of 492 ASF JIRA account requests for Spark, >>> only *34* were rejected. Most requests were reviewed and approved—often >>> on the same day—by Sean Owen ([email protected]). >>> >>> I don’t have data on how many approved accounts eventually filed a JIRA. >>> >>> On Thu, Jan 29, 2026 at 11:28 AM Tian Gao <[email protected]> >>> wrote: >>> >>>> Do we have a stat about how many of them are approved and how many >>>> approved accounts made at least 1 JIRA? >>>> >>>> We know the current flow is: >>>> >>>> Desire to contribute -> Find out need to use JIRA -> Go to JIRA -> >>>> Realize they need an account -> Request for account -> Wait for approval -> >>>> Submit JIRA ticket -> Do a PR... >>>> >>>> For each step in this flow, we are losing contributors. As we already >>>> host our repo on github, we can safely assume most of the desired >>>> contributors are familiar with github workflow, then the workflow could be >>>> >>>> Desire to contribute -> submit an issue -> do a PR. >>>> >>>> From my experience in open source projects, contributor's desire to >>>> contribute fades fast when they hit blockers, especially procedural issues. >>>> >>>> Tian Gao >>>> >>>> On Thu, Jan 29, 2026 at 11:14 AM Gengliang Wang <[email protected]> >>>> wrote: >>>> >>>>> 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] >>>>>>>>>>> >>>>>>>>>>>
