Policy and checklist for creating a new repo on GitHub.
0. Does it need to be a separate repo?
Often, you can simply use a subdirectory of an existing repo. Even Haskell packages that will be published to Hackage can be kept in subdirectories of another project.
Multiple repos are more work to maintain (e.g. CI), and it’s more stuff to keep track of.
Ensure that you have a good reason to create a separate repo.
1. Decide which GitHub organization owns the repo
In general, DON’T use your private GitHub account to own repos/forks which are dependencies of IOHK repos. Unless this fork is temporary, prefer input-output-hk. If you leave, we don’t want our project repos to disappear.
However, to state the obvious, DON’T add repos which are likely to harm to harm the reputation of IOHK or mislead the public. Ask first, if in doubt.
2. Decide whether the repo should be private
Usually a repo should be public, unless there is some real reason to restrict access.
DON’T create private repos under input-output-hk, unless you are certain that it should remain private for a while. It’s rather difficult to change a private repo to public, or even to delete the private repo that you just created.
3. Could an existing repo just be moved?
If doing renames, merges, etc, consider using “Transfer ownership”, “Rename”, or “Change repository visibility” in the GitHub repo settings. This is safe, because the old locations will redirect. You may need IT to help with this change.
4. Checklist for adding a new repo
-
Ensure appropriate access to the repo in Settings → Manage access.
DO use GitHub Input Output organization teams to manage access levels.
DON’T invite individual developers (except your own user), unless for exceptional circumstances. Consider using the Adrestia Guests team.
Invite teams according to this scheme:
- Adrestia - Triage (the umbrella group)
- Adrestia Admins - Admin
- Adrestia Maintainers - Maintainers (most developers are in this group).
- Adrestia Guests - Write
- devops - Admin (for setting up CI things)
- release - Write (for editing release notes and making releases)
-
Name of
master
branch - it really doesn’t matter, but consistency is nice. -
Switch off features such as Issues/Wiki/Project/Pages unless you actually need them.
-
Add Autolink references for jira:
-
Remember to customize the “About” text and URL if applicable.
-
CI: if using Buildkite, set up a pipeline and webhook.
-
CI: if using Hydra open a PR to add a jobset.
-
CI: if your CI requires secrets such as auth tokens, ensure that all secrets are also stored in our shared LastPass folder (see [Passwords]).
-
If this repo is splitting off an existing repo, see Extracting New Libraries From Existing Repositories.