A difference between what Dongjoon proposed and my proposal is - during this "test phase", is it allowed to submit PRs that are linked to github issues, instead of JIRA? If it's a yes, then I'm totally fine if we want to extend this to 3-6 months. If it's a no, I still believe it's a significant improvement, but we may miss some data about if people feel more comfortable using github vs JIRA.
If we only allow github issues to be a discussion forum, then I don't think it deserves an SPIP - let's just open it. If we want to have both work at the same time (at least start building infra around github issues), we need to sort out some details - majorly the procedural differences. What information in JIRA tickets do we really need so we have to require an equivalent component in github issues. Can we still do release notes properly. Maybe enforce (highly encourage) committers to use JIRA during that phase so we still have all the major pieces the same? I believe PMC members have the right to veto any SPIP, so I want to find a common ground here to make some progress. Tian Gao On Fri, Jan 30, 2026 at 1:35 PM Jungtaek Lim <[email protected]> wrote: > > Speaking as an occasional contributor, I would expect this to be more > effort than it’s worth. A phased migration is appealing because it feels > safer and more gradual, but I think everyone will be better off in the long > run with a speedy and clear cutover from Jira to GitHub. > > My main proposal is to construct a way to prove the proposal by ourselves > instead of just arguing around which one is better from experience with > other projects', individual's preference of UI/UX, etc. Everyone talks from > their experience and no one can be on behalf of artificial potential > contributors and other existing contributors (including committers and PMC > members). I'm not sure we don't have good evidence about changing it as a > whole - if all of us had the same preference, this discussion thread should > have just simply been filled with a wave of +1. That didn't happen. The > first phase would give data, at least for how many issues will be filed > from non-code-contributors, which we collect the accounts and consider > these accounts to have been something we should have handled ASF account > creation, or even aggressively, consider these issues to be non-existed if > we didn't migrate. > > Also if you look at SPIP doc, the plan is already phased. It's just that 2 > weeks is incredibly short for many PMC members, which has a high chance for > them to work nothing about Apache Spark during the time, and they have a > binding vote to make a decision. IMHO it should be much longer than that, a > quarter or a half year. > > On Sat, Jan 31, 2026 at 3:27 AM Nicholas Chammas < > [email protected]> wrote: > >> >> > On Jan 30, 2026, at 9:27 AM, Szehon Ho <[email protected]> wrote: >> > >> > 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. >> >> This has often been my experience as well. The eyes are mainly on GitHub >> and not Jira. >> >> > On Jan 30, 2026, at 12:12 AM, Jungtaek Lim < >> [email protected]> wrote: >> > >> > Why can't we do this in two phases instead of trying to build Rome in a >> day? >> >> Speaking as an occasional contributor, I would expect this to be more >> effort than it’s worth. A phased migration is appealing because it feels >> safer and more gradual, but I think everyone will be better off in the long >> run with a speedy and clear cutover from Jira to GitHub. The longer the >> transitional phase lasts, the more confusing it will be to new and >> occasional contributors who are not following the dev process’s evolution >> closely. >> >> Nick >> >> >> --------------------------------------------------------------------- >> To unsubscribe e-mail: [email protected] >> >>
