[policy, no patch] Add a "developer tooling" topic to Drupal core

I think this would make total sense. Deprecations are now a super integral part of the core process and upgrades are still a lot of work to support from the tooling side. I don't know if we must have a subsystem to put in a gate, but that would probably be the most sensible approach to it indeed.

I agree with this except that I don't think deprecations is exactly the right scope. It feels more like developer tooling (which could then also cover gitlab integration which is currently shoved under phpunit and coincidentally bbrala also works on).

I think this is more of a topic maintainer role. Like "Core upgrades and automations" or something.

I should have elaborated in my previous comment -- the topic maintainer roles correspond to the Drupal core gates. (Usability, accessibility, documentation, testing, etc.)

Since we want to add something like an "Upgrade path and automation gate" (better names may exist), it makes sense to create a topic maintainer group for that.

Retitling the issue and updating the IS accordingly.

Maybe we could call it simply the "Upgrade topic maintainers" and "Upgrade gate"? The upgrade path itself is a release management focus area, but the improvements to the D9 and D10 upgrade paths would not have been possible without the support of people informally acting as maintainers of these essential tools and processes to date.

@Gábor Hojtsy is another person who does a lot of work related to the major upgrade path; maybe he should also be in this group?

Upgrade topic maintainers

For me this is tricky because it sounds like it should include database update system et al, which I wouldn't wish on any living human being but is also a very different area.

Also phpstan while it's useful for upgrading module is also used for a lot of other things.

Matt, Björn and myself do a bunch of work in this area, but the technical (API) parts are not my forte, its theirs :) Sounds good IMHO to add as a topic. Hopefully we can find a good name :)

Just a thought: Maybe rather than trying to come up with the name first, a very specific list of responsibilities should be decided? Maybe that has already been done, and the issue summary hinted at some of these, but the summary doesn't contain a specific/agreed list. That might make it easier to figure out what the name should be. "Deprecation maintainer" could quite easily be misread as something like "deprecated maintainer", I don't think we want to deprecate maintainers 😀

I think the responsibilities all evolve around code upgrade tooling and what core changes need to comform to, to make it feasible to build those tools. So "Tooling for code upgrades topic"? I think the naming could be adjusted later, it would be great to establish this in our governance though to embed those working on the tools in the process.

@Gábor Hojtsy Do you mean an outline like in here?
https://www.drupal.org/about/core/policies/core-change-policies/core-gat...

Can this start with a tag for issues that introduce deprecations and a process to create an issue in Rector or Drupal PHPStan for follow up?

From my understanding after discussing briefly there are a few concerns:
1. Make sure change records have a BC snippet for module maintainers
2. Ensure that deprecations are properly triggered
3. Catch runtime deprecations for further review
4. Ensure that phpstan-drupal and or drupal-rector can fix / catch deprecations

What about while these details are hashed out we start with a non-blocking tag for `Needs Developer Tooling` or something similar.
Then once we start tagging issues we can evaluate scope and see what needs to be documented vs addressed before merging.

I'm not trying to volunteer anyone, I am trying to parse out above, feel free to correct anything I state below.
And to prevent repeating I'll define the Developer Tooling Team (DTT) as the following people for now.
Gábor Hojtsy
mglaman
bbrala

Would a responsibilities list look something like this for a first pass?

TASK: Tagging issues for review by DTT

• Community
• Needs Review Issue Queue
• Committers

TASK: Triaging tagged issues

• Developer Tooling Team

TASK: Creating followup issues in phpstan-drupal and or drupal-rector

• Community
• Developer Tooling Team

Maintaining phpstan-drupal and or drupal-rector

• Community
• Developer Tooling Team

I think the idea is that the tag for now would only block closing as long as phpstan-drupal and or drupal-rector follow up issues do not exist, but would not block closing beyond that.
So in the beginning this gate only blocks as much as a change record or less so it is minimally disruptive while gathering info.

As an example I've tagged #933004: Test that all form elements have a #title for accessibility

That also obviously allows: https://www.drupal.org/project/issues/search?issue_tags=Needs%20Develope...

Then a first step would be to create an issue like this: https://github.com/mglaman/phpstan-drupal/issues/748
Maybe a template can be put in the project for the details that Matt would like to see.

For now I would also say only the members of the DTT should remove the tag until we establish guidelines.

We should combine PHPCS with Rector.

For example, when running the Rector rule to convert annotations to attributes, the resulting PHP attribute is all on one line and the classes aren't imported. That's because Rector can't do class imports (it can only modify the node it found AFAIK) -- I don't know whether we could improve its output to do linebreaks.

But the resulting code can be improved by then running it throuh PHPCS & PHPCBF. In the case of converting annotations to attributes, the Drupal.Classes.FullyQualifiedNamespace.UseStatementMissing sniff will fix the classes at least.

So Rector rules should come with a list of the specific PHPCS sniffs that are needed to correctly reformat the fixed code, and our tooling should run Rector AND PHPCBF with those sniffs.

@joachim, thanks for your insight, I think that would be certainly helpful, and I think bbrala has been experimenting with core rewrites.

I think it's slightly off topic for this thread though as this thread is more about providing support to the team behind rector and phpstan so they can provide insight and be notified of changes that require rector / phpstan updates before they land.

The current process requires a lot of effort on their part to remain informed and they are always chasing. Ideally we can be more proactive to help with such important tools for keeping contrib up to date.

Possibly relevant related issue.

Me, catch, gabor and mglaman just talked about this in Barcelona.

We considered the different possible names eventually basing is on what would our main goals be.

The goal of the topic would evolve around developer tooling with the name Developer Tooling. This will manage phpstan and possibly also rector. And in a followup create a gate on making sure that we (will) handle deprecations and other possible updates on that. This could also compose of some work being done in the gitlab side of things for core which is something I've been involved with anyways.

The consensus we had is that Developement Tooling is the best way to go since that would contain all the right things without suggesting subsystems like database upgrades and such.

I think comment #13 is pretty good summary on what the initial workflow would look like.

Gabor, catch, mglaman and me think this is the right way forward.

Retitled for that scope then. Should we open an MR in an another issue or conver this to a core issue?

+1 to developer tooling from me.

The Ideas project is being deprecated. This issue is moved to the Drupal project.

Since @gábor hojtsy, has been involved in this I am striking out the task for product manager approval,

The next steps are a followup core issue for add people to the role and another one to define the core gate. An issue in the governance queue is needed as well. The other topic maintainers do not have a role description but the work in #13 would be good to add.

This issue is in sort of an ambiguous state. In between creating all the followup issues @quietone mentions (which wouldn't be an RTBC state) and community consensus, we need as Core Leadership team decision into whether to evolve the governance with this additional topic area. I created a poll in the Core Leads' decisions channel to this end and asked for responses by June 29 (timeboxing to two weeks as per our practice).

I've just been made aware of this proposal as it's an area I'm interested in. I think the IS needs an update to reflect #19. I've commented in the past about a lack of component for Drupal issues to do with gitlab configuration, phpstan, phpcs, and other code quality tools so I'm in support of this proposal. Happy to put my hand up to help with this in some capacity.

All the core leadership team members either endorsed this policy proposal or had no opinion on it. So the next step is to create a governance followup issue. (Edit: and the two other followup issues for core, which would be postponed on the governance issue.) NW for that I guess?

Opened #3536493: Add a developer tooling topic to Drupal core but that is not where the meat of the description would go based on the structure of the governance there, it would go into the gates definitions, which are d.o docs.

There is agreement here on the idea and the followup issues have been made except for the ones to add people to the role. Those can be added later and should not hold up this policy decision.

I committed the governance addition.

I think we probably want to add documentation to the core gates (at least a stub section that can be filled in later)?

There is no disagreement here, and the child issue exists to add this to the core gates, so closing this as fixed.