Decide on, and implement permissions for issue forks

As #3071473: Add a create fork / workspace button to issues → is worked on, we need to figure out who should have push access to the forked repositories and branches.

The easy answer - use GitLab group access to give everyone with a Drupal.org Git account all the access all the time.

Potential concerns with very permissive access:

• Accidental pushes happen, Git doesn’t always have the best UI. An additional gate can block unintentional pushes, and provide a speed bump to explain issue fork policies and etiquette.
• Someone may try mass-contributing to issues - rebasing, cleaning Git history, fixing coding standards, etc. Useful if done well, disruptive if not.

Possible approaches

Click to gain access to all branches

Click a button on the issue page to get access to push to all branches in an issue fork.

The project’s maintainers and/or commenters in the issue may get access automatically, as if they had clicked the button already.

Per-user branches

Everyone has access to push to branches prefixed with their git.drupalcode.org username.

More things to consider

• #3071674: Decide on force push rules for issue forks, implement if necessary →
• Should anything different happen when the issue is closed?
• Are there other options to look at?