I recently went through the exercise of contributing my first PR to spark.
While I think that the JIRA definitely contains a rich history and project context, I will add that the workflow was a bit novel compared to the classical “open an Issue and discuss” contribution workflow. I do think there may be some risk of bifurcation of project history from one platform to another, but I would also add that it would lower the barrier of entry for first time contributors. —Antonio Sent from my iPhone. > On May 20, 2026, at 2:43 PM, Tian Gao via dev <[email protected]> wrote: > > > Hi, > > From our discussion 3 months ago > https://lists.apache.org/thread/kv11qlr8j05cwqjoyddybclwcn0nv2n7 , we've > decided to open github issues as an experimental option and evaluate the > results after 3 months. Now it's time! > > In the last 3 months, we opened github issues solely for bug reports and > improvement requests. We got 63 issues in total. Most of them are valid, we > probably had 1 or 2 spams. Even without any template (it was never merged), > almost every issue was created with a detailed description. Very few issues > came from committers. > > I (Claude Code) did a quick search in JIRA. In the same time frame, I asked > it to list JIRA tickets that: > 1. is either bug or improvement > 2. has a description longer than 50 words > 3. assignee is not reporter > 4. either there is no linked PR, or the first PR was created more than 12 > hours after the ticket was created > > This filter attempts to exclude "community reports", ruling out JIRA tickets > created just for submitting a PR. > > The number is approximately 47. I think it's safe to say that we received at > least the same amount of feedback from the community on GitHub as on JIRA. > Another interesting number is 1394 - that's the number of JIRA tickets > created during this timeframe. What it represents is probably beyond this > thread's discussion, but that's an interesting diff. > > Now back to our next step. According to my proposal, we had to choose from > one of the following options: > > 1. Explicitly declaring that we need more time for this experiment. 3 or 6 > extra months. > 2. Close the github issues because the maintenance effort is larger than the > benefit. > 3. Decide that using github issues as discussion only is the best way for > spark and keep doing it. > 4. Support github issues as an equivalent to JIRA tickets so PRs can link to > them too. > 5. Fully migrate from JIRA to github issues. > > Personally I think github issues have proven useful, but different opinions > are definitely appreciated. There's almost no maintenance cost for github > issues so I don't think we need to choose 2. I'd love to hear from the > community about their preferred option. To make it more objective, I won't > choose one here. > > Tian
