We can’t conclude that JIRA is better than GitHub Issues solely because the Spark main repo is more active than spark-connect-rust, that’s not an apples-to-apples comparison.
Now I kind of prefer the previous proposal from Dongjoon: open up Github Issues Tab as an additional preliminary discussion place. We can see how it goes and discuss this later, > Another benefit is that it's optional, there's many simple Iceberg prs that are submitted without needing an issue (I think most), which reduces the overhead of the current JIRA requirement where it's not needed. This is interesting. Given that most Spark JIRA tickets have no discussion, I'm wondering what's the point to enforce that every PR (except for minor ones) needs to link to a JIRA ticket. How do other Apache projects deal with PRs? @Szehon Ho <[email protected]> How does Iceberg compose release notes if most PRs do not link to issues/JIRAs? On Sat, Jan 31, 2026 at 12:57 AM Dongjoon Hyun <[email protected]> wrote: > I would like to point out that the Apache Spark community has already been > experimentally using GitHub Issues on a per-repository basis. For example, > consider the GitHub Issues tab of the spark-connect-rust repository: > > https://github.com/apache/spark-connect-rust/issues > > At the time of writing, it contains only one issue, created about six > months ago (2025-08-22), even though there is no ASF JIRA requirement for > that repository. By contrast, the main Apache Spark repository—where JIRA > is required—consistently receives a large volume of contributions and issue > activity. This strongly suggests that there is no systemic barrier > preventing participation. > > In practice, the Apache Spark community has long allowed contributors to > engage through multiple channels—mailing lists, JIRA, Google Docs (SPIPs), > and pull requests—without imposing artificial restrictions. > > From this perspective, Tian’s position appears somewhat biased toward > abruptly deprecating the existing JIRA system. It is also important to note > that, previously, ASF JIRA didn't required PMC approval for account > creation. ASF has deliberately added an AS-IS human-in-the-loop process for > JIRA accounts, precisely to protect ASF projects from AI slop (low-quality > automated issue creation and comments). > > Dongjoon. > > On 2026/01/30 14:27:09 Szehon Ho wrote: > > Re: use of JIRA issue and how useful github issues will be. > > > > In my experience, because I see few committers discussing anything > > technical on Spark JIRA for years as you mentioned (and other Hadoop > > project JIRAs too), I feel like nobody will reply if I do, so I will > make a > > Github PR directly and ping for feedback there. So in addition to the UX > > problem Tian mentioned, it's worsened by cause and effect. So it's > become > > a procedure, and we still don't have a good place to discuss without > > jumping to code. > > > > In my experience in another project like Iceberg, I see healthy > discussions > > on Github issues as well as PRs. Github Issue are obviously useful for > > users to file bugs/requests and devs to discuss. But it's also useful > for > > designs (Iceberg Improvement Proposal), where it can hold discussion, see > > for example one of mine: https://github.com/apache/iceberg/issues/10260. > > Then once concrete prs are filed linked to the issue, the discussion > > naturally moves to there. As Tian mentioned, its a better UI, and also a > > more natural UX as its all in the same system. I think filling that gap > (a > > better UX for higher level design discussion, vs Google doc/devlist) > could > > be useful for Spark, where devs/users can discuss ideas before actually > > writing a pr. Another benefit is that it's optional, there's many simple > > Iceberg prs that are submitted without needing an issue (I think most), > > which reduces the overhead of the current JIRA requirement where it's not > > needed. > > > > Attach the Iceberg issue template as well to illustrate the UX, it may be > > useful in Spark to have a template as well for bug, SPIP, security issue, > > for example, if we use github issues. > > > > [image: Screenshot 2026-01-30 at 6.11.58 AM.png] > > > > Thanks > > Szehon > > > > On Thu, Jan 29, 2026 at 9:22 PM Jungtaek Lim < > [email protected]> > > wrote: > > > > > Or, if someone volunteers to create and maintain a bot which duplicates > > > the Github issue to JIRA ticket specifically for a label, we will see > the > > > changes of people's preference over time. If we clearly see that > people's > > > preference is on Github issues, discussion and vote will be super > > > straightforward. If it doesn't happen, kill the bot and enforce ASF > JIRA > > > for code contribution again. This is good for me as well, as an > > > "attempt" of evaluating the tool change (which is not a very trivial > > > decision). > > > > > > On Fri, Jan 30, 2026 at 2:12 PM Jungtaek Lim < > [email protected]> > > > wrote: > > > > > >> Why can't we do this in two phases instead of trying to build Rome in > a > > >> day? > > >> > > >> We start to use Github issues as an entry point for questions and > > >> reports. We see how many people would request account creations, and > they > > >> end up filing JIRA tickets (indicating they are contributing "code"). > Run > > >> this model for 3 months or even 6 months and see whether committers+ > start > > >> to feel more familiar with Github issues (assuming they look at > reports - > > >> if they don't look at reports in Github issues, we then figure out it > is > > >> NOT a tool issue), and do the discussion again. So many contributors+ > here > > >> are used to JIRA for multiple years; it sounds too ambitious to > change the > > >> workflow in one day. > > >> > > >> > > >> On Fri, Jan 30, 2026 at 12:12 PM Tian Gao <[email protected]> > > >> wrote: > > >> > > >>> Appreciate the data. That stat also matches my personal experience. > > >>> However, I consider that as a result of using JIRA, not a reason to > stick > > >>> to it. I think we don't have much discussions because we are using > JIRA > > >>> exclusively. > > >>> > > >>> I think github issues just have better user experience than JIRA, > even > > >>> not considering the registration barrier. > > >>> > > >>> Let me be more specific. > > >>> > > >>> When you enter the issue page of JIRA, it would be like this: > > >>> > > >>> [image: image.png] > > >>> > > >>> Notice that by default, we have ~7 visible tickets, ordered by > priority, > > >>> taking about 25% of the screen width. For each ticket, without > clicking on > > >>> it, I have about 7~8 words before it's truncated. I have a single > icon > > >>> indicating whether this is a task/bug/feature. > > >>> > > >>> On the right side, I have the details of this specific ticket, where > I > > >>> need to scroll down to get to the comment section. The comment > section > > >>> (after hitting the add comment button) has an old rich-text editor > which > > >>> does not support markdown. Syntax highlighting is supported, but > hidden > > >>> under some button. > > >>> > > >>> This is github issues page (of arrow) > > >>> > > >>> [image: image.png] > > >>> > > >>> Also about 7 issues by default, but much larger font, ordered by > created > > >>> time. Title is much more visible. There will be multiple labels > indicating > > >>> what the issue is about. You can also tell if the issue is assigned, > how > > >>> much discussion is in the issue and if there are PRs already. > > >>> > > >>> In the issue discussion comment section, it supports markdown very > well, > > >>> all the comments are clearer and better displayed. We all have > worked with > > >>> both JIRA and github PRs, I believe everyone can feel the different > user > > >>> experiences between the two. > > >>> > > >>> > > >>> As a user who's browsing issues, it's much easier to find an > interesting > > >>> issue to discuss/work on. It's easier to click a label to see related > > >>> issues (I find it quite difficult to find the component related > tickets in > > >>> JIRA). I think the UI is just more intuitive and familiar with > programmers. > > >>> > > >>> > > >>> "We don't have a lot of discussion on JIRA" should not be the reason > > >>> that we don't need to migrate. On the contrary, I think that's the > reason > > >>> why we should. > > >>> > > >>> Tian Gao > > >>> > > >>> On Thu, Jan 29, 2026 at 6:42 PM Wenchen Fan <[email protected]> > wrote: > > >>> > > >>>> 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] > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> > > > > --------------------------------------------------------------------- > To unsubscribe e-mail: [email protected] > >
