#Needs product manager review

I think this issue might be a wontfix:

• Having a new required field on every single Drupal site, especially one that does not affect the production user experience, seems like it is fixing an edgecase at the expense of the evaluator and site owner experience for all sites.
• Adding additional form elements always inevitably causes a usability regression, so we should make sure the usability benefit of adding the element outweighs that regression.
• It is also relevant for the product manager role because it affects the evaluator experience of Drupal. Adding an additional thing that must be configured (at site install maybe even?) is a non-trivial increase in the amount of configuration necessary to get up and running.

At a minimum, I think the field should be optional rather than required, and have a sensible default value if the user doesn't provide one. Furthermore, though, this could be addressed with a contrib module and might not even be appropriate for core.

If folks do still feel this belongs in core, then at a minimum, the field should be made optional. Then, that could be submitted for usability review (tagged "Needs usability review") once that change is made. Furthermore, even if the usability team gives the addition a +1 (benefit outweighing negative UX impact), this would still require product manager signoff because it affects the evaluator experience of Drupal.

Also, there is not actually a merge request here ATM, so we would need that too before proceed.

My personal recommendation is actually to mark this wontfix and support it via contrib, but it's outside the scope of my role as a release manager to make a final decision on that myself.

Saving credits for policy discussion and research.

Of note regarding:

Provisional committers will be GitLab Developers with an explicit access permission to push (or if the Core team wants a more lax security policy they can skip this and just make them regular maintainers)

This might depend on the committer's role, also (a lot of our other permissions do for provisional committers), but based on the summary I think the former option is the closest match to the current r ole expectations for provisional committers → .

The PDF is a great help; thank you for that. We will need documentation updates based on this when we implement this practice.

I'm completely on board with the proposal here, but since it is a policy issue essentially about the implementation of core governance, we should probably follow the committer decision-making process to give all committers a chance to review the policy. So, I'm tagging with all the relevant role tags, and posting this to the committer's policy decision process.

Thanks everyone!