For AI generated spams - I've been working on CPython repo, which is completely public, for more than 2 years. There are AI generated issues/PRs, as well as human spams, but it's never been a huge problem. github as a platform is working on it and for most issues we can just close it (it really does not happen that much).
>From another perspective, every single registration request to JIRA is "spam". It requires the PMC's attention and the PMC has to decide whether it's a "legit" request. If we approve all requests, that's like no-human-in-the-loop. Otherwise, how could a PMC determine which request is legit? It takes time right? According to the data from the other thread, we had 492 "spam" last year - it's unlikely we have this many AI generated issues/PRs if we migrate to github. Tian Gao On Mon, Feb 2, 2026 at 5:55 AM Wenchen Fan <[email protected]> wrote: > Apache Spark is already using Github heavily to accept code changes, so 1, > 2, and 3 do not seem to be an issue to me. AI spam can already happen with > PRs (writing code is cheap today with LLM) and opening Github Issues won't > make a big difference. > > > 4. Degraded Traceability. > > This makes sense. Until we find a better solution with a smooth migration > plan, I think we should still open JIRA tickets for code changes that worth > to trace. For now we only allow minor changes to omit JIRA, maybe we should > extend it, like only create JIRA tickets for changes that worth to be > mentioned in the release notes. We can follow the common practice from > other Apache projects. > > On Mon, Feb 2, 2026 at 9:33 PM Nicholas Chammas < > [email protected]> wrote: > >> >> > On Feb 2, 2026, at 2:02 AM, Dongjoon Hyun <[email protected]> wrote: >> > >> > Adopting GitHub Issues imposes a new burden. Committers and PMC members >> will face increased overhead in moderating AI spam. Unlike the current ASF >> JIRA system, which now requires PMC approval for account creation (a >> human-in-the-loop defense), GitHub accounts are easier to create and abuse. >> Banning GitHub accounts is a tedious and unpleasant task for maintainers. >> >> Banning accounts should not be that tedious. It’s just a couple of >> clicks, no? >> >> And accounts that are creating AI slop are likely doing it on other >> projects, meaning that GitHub will already be getting signals about an >> account’s quality before any Spark admin takes action. Severe offenders are >> likely to be banned globally by GitHub. >> >> Being on GitHub also means that we will have access to more tools that >> are integrated with the GitHub ecosystem to help manage problems like >> these, should we need them. >> >> > 3. Accessibility and Vendor Lock-in. >> > >> > We should not assume all users want or have GitHub accounts. Issue >> reporting is distinct from code contribution. The current ecosystem allows >> anyone with an email to participate via ASF infrastructure. Mandating >> GitHub Issues forces users onto a third-party commercial platform, >> effectively raising the barrier to entry for bug reporting. >> >> This argument doesn’t make sense to me. Earlier you were warning that >> lowering the barrier to entry will lead to more moderation overhead, but >> here you are arguing the opposite, that GitHub raises the barrier to entry. >> >> GitHub is so widely used in our industry that it’s reasonable to assume >> that it offers the lowest barrier to entry of any code collaboration >> platform. Reporting issues is a basic part of that. >> >> I think it would be difficult to find anyone, especially a new >> contributor, who feels that ASF Jira is more accessible than GitHub. >> >> Nick >> >> >> --------------------------------------------------------------------- >> To unsubscribe e-mail: [email protected] >> >>
