Set up AI issue + merge request templates at an "AI" group level and add all ai_ projects to it

Tentatively bumping to "major" because if we get in front of this, we somewhat contain the UX blast radius moreso than once the copy/pasta of these rules has proliferated throughout 100+ modules.

I did not know how to parse that (sorry, still learning :D), so I did some digging into it with Claude, and it sounds like:

How the existing CI pattern works

Right now, every project has its own .gitlab-ci.yml file in its repo. That file is the source of truth for that project. But the first line of most projects' .gitlab-ci.yml is essentially:

yamlinclude:
  - project: 'project/gitlab_templates'
    file: '/includes/include.drupalci.main.yml'

That include pulls in the shared, centrally-governed config from the gitlab_templates project. Then a project can add its own lines below to tweak or override what it inherited. So you get: shared defaults + local control + no forced inheritance. If a project doesn't want the global stuff, it just doesn't write the include line, so there's an "opt-out" — nothing is imposed instance-wide.

The bad news

GitLab's include: mechanism is a feature of the CI/CD pipeline engine specifically. Description templates (issue/MR templates) don't have an equivalent include directive. They're just Markdown files that GitLab discovers by their location — .gitlab/issue_templates/*.md and .gitlab/merge_request_templates/*.md in the project's repo. There's no native "include the templates from that other project and extend them" syntax for description templates. So the literal answer to dww's "can it work exactly like .gitlab-ci.yml?" is no, not natively. (sad panda)

GitLab does have other mechanisms, but neither matches exactly:

1. Instance template repository (this issue) — exists, works, but it's the "no opt-out" instance-wide setting drumm flagged, and on a self-managed instance the relevant inheritance features sit behind Premium/Ultimate tiers. (Do we have that?)
2. Group-level templates — also exists, also Premium, and Drupal.org's project structure isn't organized into the GitLab groups this would need. But, we could add an "ai" group for the all the AI projects, for example, and have them all use the same templates, avoiding the massively sprawling UX issue.
3. Port the The CI include: model to task descriptions and probably submit it upstream because this seems like something anyone would want to use.

^ I have not validated that this is true, but Claude wasn't able to find an existing upstream issue in a quick scan.

Back to @drumm in #3 as I parse what dww just said. :D

We should probably have at least a little consensus from project maintainers that the templates are generally good for most Drupal.org projects before deciding to suggest them for all projects. I believe there is not an opt-out for any given project.

As you point out, Drupal.org already ships a default issue template, and also forces a defined set of issue types as well, regardless of project. So this would more or less be carrying over our existing model, just instead of the "sledgehammer" approach of using the exact same set of headings to bug reports, feature requests, and meta issues alike... we get templates that are versioned, per-type, and customizable per-project.

My recommendation would be that we do the following (in this order):

1. Ship what's in the AI project as a global default ~now-ish, so we can stop the template fragmentation that's actively happening right now, and also to show to newly migrated folks that GitLab gives us a chance to do things better than before. (Win!) Consider this starting point part of the GitLab migration.
2. Open an issue in the Coding Standards project (maybe?), as this already has some governance around it for discussing, deciding, and notifying about new contribution norms.
3. In that discussion, review the templates that are now already in GitLab as a starting point and make whatever recommended changes. Crucially, this consensus building now becomes an "edit job ("Let's remove 'Workarounds' from feature requests, that feels weird") not an "invent the standard from scratch" job. That's important because a) smart people already did a bunch of thinking on this topic, and they've put it into practice with dozens of contributors, and it makes sense to not throw out their work, b) now the reviewers / deciders of what the default templates should be can see+feel the forms themselves directly vs. trying to understand from more abstract Markdown how they would work once rendered.

That seems to satisfy the requirements to have community discussion/consensus around critical contributor workflow things (agreed) without allowing the fragmentation that currently is happening to compound with every new project that's migrated over.

I'll note that GitLab issues is currently on Early Adopters, this is a group that probably should be fragmenting, trying new things and finding their own way without a solid consolidating force, learn from each other sure, however don't guide them to a prebuilt unless they ask for it directly.

In general, I totally agree with this sentiment. In this particular case, however, it's a bloody nightmare 🤣 because the ~150 projects in the AI ecosystem have already decided they want to standardize on these templates.

Which means ~150 projects are getting (or soon to be getting) merge requests like this one https://git.drupalcode.org/project/ai_best_practices/-/merge_requests/39... that copy/pasta the main template files into each individual project.

That's in turn going to create ~150 individual copies of those templates that have no connection to their upstream sources, and therefore do not know to change when upstream changes, I guess unless ~150 individual projects implement CI rules like what dww is talking about (assuming they work, given the write permission restriction you've flagged).

OR! ;)

We could get out in front of that by making a decision early "These templates are good enough for now," put an end to people spending time and effort making ~150 copies, and instead point those efforts on aligning with other Drupal technical leaders who are NOT in the AI initiative on what future standards make sense for everyone.

And hey, look. We could also work around (ha! :)) this "fractal fragmentation" problem by assigning all ai* projects to an "AI Projects" Group and set group-level description templates for those projects and those projects only. But, like... why? :) Why create a confusing contribution experience on a new platform out of the gate? (The support requests write themselves: "How come my project doesn't have the Feature Request and Bug Report drop-downs? GITLAB SUX" ;)) Why not instead intervene early, when there are relatively few folks poking around, and raise the bar and provide consistency on GitLab's developer experience for ALL Drupal contributors at once?

I know in GitLab you can override an upstream template, however can you remove one? I know several modules (and Core) for example do not believe in support requests and were looking forward to GitLab removing these options.

Great question. Looks like no. :(

https://gitlab.com/gitlab-org/gitlab/-/work_items/452296

What happens when the templates are modified by community editing to the point they no longer work for the AI ecosystem? Aren't you in the same position of needing to duplicate to all the projects?

FAIR POINT, friend. :)

Ok then, rescoping this to hopefully be something less controversial.