It might also be interesting to automatically open a PR that adds all the current settings to .github/config.yml if the file doesn't already exist.

@bkeepers I completed this. Please review my PR
Thanks in advance.

Is this still relevant? If so, please comment with any updates or addition details.

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

Yes

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

Yes it is still relevant

@knrt10 your build is not passing, but why was it closed?

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

@knrt10 or @bkeepers

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

Bot, got away, its blocked by no one from the project replying.

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

still relevant

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

Still relevant @travi could you disable the bot here?

An implementation for this would significantly improve the security stance when using this app.

Copied from my comment on the open PR:

Currently, an org admin configuring a new repo needs to do two tasks in order:

1. Install the app in the repo
2. Push/merge a commit with .github/settings.yml with the required branch protection rules

If they do those in the wrong order, then it's very easy for them to be under the mistaken impression that the repo has been configured safely. This leaves the repo significantly vulnerable until either the settings are updated or an admin notices the missing rules.

That condition is especially likely when creating repos from a template, as the template is likely to have the settings file already.