PR #926 situation, need guidance

[SashankBhamidi]

@niccokunzmann @stevepiercy

Need your input on PR #926.

I created Issue #925 asking for tests on Conference parameter edge cases. Added a comment explicitly saying "Wait for PR #921 to merge first" because the tests would need to be written against the fixed code.

PR #926 was opened 4 hours later, 6 hours before #921 merged. They didn't wait.

The problem: their tests expect the wrong behavior.

Their code doesn't have the normalize() function from PR #921. It's still the old code that passes lists through unchanged. So their tests expect:

uri.params["FEATURE"] == ["AUDIO", "VIDEO"]  # expects list

But after #921 merged, it returns:

uri.params["FEATURE"] == "AUDIO,VIDEO"  # comma-separated string

Their tests pass because they're testing against pre-#921 code. If we merge this, it reverts the normalization fix.

They also test invalid types like feature=0 and feature=False that can't pass the type hints (feature: list[str] | str | None).

The PR body reads like it was AI-generated with lots of expansion on my original issue. The code has the same feel.

Here's what bothers me: this feels like autopiloting. Issue created, fed to an LLM, PR generated within hours. They posted "Ready for review!" 14 seconds after the first CI test passed. No time to actually review test results, no testing against actual main branch, no verification the tests make sense. Just fast output.

I use AI tools myself (Copilot for commit messages, code suggestions, boilerblate). That's fine. But this looks like someone skipped the thinking part entirely. Didn't read the instructions, didn't test the code, didn't understand what #921 changed.

We might need a policy on this. Not banning AI, but making it clear that instructions in issues must be followed, code must be tested against current main, and you need to understand what you're submitting, not just generate it.

What should I do here? Close it with explanation? The instructions weren't followed and the tests are fundamentally wrong. I'm new to reviews so looking for guidance on the right approach.

[stevepiercy]

Thanks for bringing this up. I noticed that PR had an AI smell.

Plone has struggled with AI abuse for years. Google Summer of Code (GSoC), Hacktoberfest, and other "pad your CV at the expense of open source software volunteers" events exploits the goodwill of FOSS community members without giving back. We have professors telling their students to submit pull requests for homework, and they don't even use the software! In Volto, we even had one person from Asia submit a PR using AI that copied another contributor's unmerged PR verbatim, and it was a Swedish translation file. The original contributor was furious, and the plagiarist pleaded it was AI that did it and that he wasn't responsible for wielding the tool. The flood of slop and garbage from first-timers into Volto resulted in an update to its contributing policy, and Plone will soon publish an AI policy. I drafted this AI policy for Plone, but I'm afraid it will be watered down.

As I result, I'm always skeptical of first-timers, and especially when it has an AI smell to it.

[SashankBhamidi]

Got it. Volto suspending first-time PRs until 2026 says everything.

Waiting on Nicco.

[niccokunzmann]

If you want to have a non-watered down Ai-policy for this icalendar, welcome :) Might be nice to experiment. In any case - icalendar has been written mostly without AI, so being strict is not a loss. We are not struggling to race to the front here but to have a nice time developing something useful for people ❤️

[niccokunzmann]

I would say:

Hacktoberfest is nice for people to learn.
AI is bad at taking the feedback into account as humans would.
I like to be in contact with people.
First-time contributors to the project bring

• more tolerance to edge cases in the wild
• a lower bar to use and understand the project
• a check on those who develop to be open on the human level of open-source to what actually matters

We are free to experiment with this.

Suggestion for a process:

• collect red flags
  • a count as a threshold
  • let's collect the flags in the AI policy
• ban the person
• flag them as spam
• leave a comment about where they can complain (we do not have a procedure yet, so we make one up that satisfies us making a mistake and undoing it)

[SashankBhamidi]

Thanks for creating #933. For PR #926 specifically, the red flags are:

• Ignored the "Wait for PR 921 merge" instruction in the issue
• Opened 6 hours before PR 921 even merged
• Tests expect the wrong behavior (lists instead of comma-separated strings) because the code doesn't have the normalize() function from PR 921
• PR body reads like AI expansion of my original issue
• "Ready for review!" posted 14 seconds after CI started passing
• Branch is based on old code, so tests pass against buggy behavior

If this merges, it reverts PR 921's fix.

[SashankBhamidi]

@niccokunzmann What should I do with #926 right now? Close it with an explanation, or comment on what needs fixing and leave it open? I'm still figuring out the right approach for this, you've trusted me to review PRs when I'm new to OSS entirely.

[stevepiercy]

Let's establish a policy first, then follow it. There's no rush to merge PRs, especially ones that are problematic.

[SashankBhamidi]

Let's establish a policy first, then follow it. There's no rush to merge PRs, especially ones that are problematic.

He closed the PR

[stevepiercy]

Without casting aspersions at a specific group or technology, I'd propose the following update to https://icalendar--930.org.readthedocs.build/en/930/contribute/index.html to give first-timers some guidance and set a policy.

First-time contributors

Contributions to icalendar from people new to icalendar are welcome.

For people participating in programs to encourage first-time contributions, including Hacktoberfest, Good First Issue, and Up For Grabs, you must comply with its terms and conditions to receive its recognition or rewards.
Accordingly, you may request of the maintainers in your pull request that you would like recognition for your contribution.

You may responsibly use artificial intelligence (AI) as a tool to draft a pull request.
That means you must comply with Pull request requirments.

The maintainers may close pull requests without providing feedback that they deem to be spam, AI slop, abuse, or that do not comply with pull request requirements.
The maintainers may also take further action, including suspend, ban, or report GitHub users.