[policy, no patch] Allow docblock to be removed when modifying constructor params

+1 Yes please! If we're changing the params, we would normally have to be updating the docs to match. In this case, removing the docs is better than "fixing" them.

+1 from me too, if it's in scope to add to the docblock, it's also in scope to remove it altogether given the new coding standard. I co-incidentally ran into this today on 📌 Use MessagesCommand in BigPipe to remove special casing of the messages placeholder Fixed and took the approach here.

+1 from me. It seems sensible. I tried to review 📌 [11.x] Inject entity.repository service instead of using \Drupal::service('entity.repository') in non-tests Needs work which touches a number of constructor docblocks and wondered "Why?"

I think we've been doing this in practice quite a lot already.

I think we have the necessary support, but we probably need proposed text changes though.

Meant needs work

I don't know how to word something, it would have to be specifically about constructor documentation, because any other situation where it's like 'oh here's some extra code to remove/update to a new coding standard' can easily turn into a bad example of scope creep.

The main reason to do constructor promotion and documentation removals at once when changing one parameter is it's exactly the same line of code, or immediately adjacent, and just deletions. And because it avoids the deadening feeling of adding boilerplate you know shouldn't be there just to match existing boilerplate that should already not be there.

I studied the issue scope document last night and this morning. I think the most reasonable thing is to add another row to the "Examples of good and bad issue scope" table.

Let me know what you think of this.

#9 seems good, maybe with a link to the coding standards entry for constructors for context?

Edited #9 to add the docs link.