Require an issue for each PR and provide issue template(s)

[zbynek]

Note

This is a follow-up to the discussion at https://groups.google.com/g/google-web-toolkit-contributors/c/RfcB0hP3dgc

The growing number of AI-assisted PRs raises the amount of time required for reviews.

To mitigate this, all PRs should come with an issue that clearly describes what problem is being solved.

The PR template should say that

If there is no related issue, please create one first. Without an issue and time for discussion, it is unlikely that your pull request will be accepted.

There should be clear requirements for an issue to be considered, maybe best expressed by multiple issue templates

• bug: provide steps to reproduce + expected and actual behavior
• security hardening: provide steps that exploit a vulnerability, not just "internal method X might do Y which is considered unsafe"
• feature request: explain why a feature is needed
• chores (refactoring, fixing warnings, fixing typos): explain why it's important

[jnehlmeier]

The question is if we really gain something if AI then creates an issue as well while opening the PR.

Given that these PRs are usually security focused we might want to look at private security reports and a security policy via https://github.com/gwtproject/gwt/security pointing to private security reports. Maybe we also want to turn on Github's CodeQL scanning and see what it brings to light.

With private security reporting they have to report a security issue first before it can be worked on in a private repo. Sure it won't stop anybody from just creating a public PR as they do now but we could then simply close them right away.

Other than that, yes we should provide issue templates again. We once had a template but then Github changed the format and nobody updated it. If we adopt the security tools of Github mentioned above then we could omit security issue template intentionally.

[niloc132]

I think we gain

• friction of a day or two (the "...and time for discussion"), to slow down automated suggestions until we're sure they even make sense
• actual outright statement of what is wrong, either stated initially, or required to be discussed before a PR can be considered
• implicit permission to close a PR that doesn't follow the process (since they "read" the policy).

Creating a security policy and opening private security reports is probably also a good idea - I don't personally have anything against AI assisted bugs found nor fixes, but while the quantity of contributions has increased markedly, the quality of those contributions has also dropped.