COMPASS GitHub Guidelines

Our organization has guidelines to help keep our projects and repos orderly, which fall into three main categories:

Some guidelines involve contacting an admin, such as requesting access to a team.

Currently, the COMPASS-PSAAP organization owners are:

Starting projects

The features built into the COMPASS organization can make maintaining new projects easy. To get started on the right foot, follow these steps:

Identify who will work on the project and ask an admin to make a team with those personnel for your project. In some cases there may be an existing team that matches your project's personnel, which you can then assign to your repo(s).
Create your repo. The majority of repos should be created directly in the COMPASS-PSAAP organization by an admin, but there are cases where a project encompasses multiple repos and a separate organization should be made for them. In these cases it is still a good idea to use the compass-template repo as a template as it provides clean issue and pull request formats to keep the project organized and provides a defined code formatting style.
Add restrictions to the main branch. This will usually be done by admins, but if you end up doing it yourself, this article tells you how to do it.
The two rules to add are 1) Block merging directly into main without a PR, and 2) requiring at least one approving review before a PR can be merged.
This ensures all incoming code is seen by someone else so major errors are more likely to be caught. It is also recommended to apply the same protection to the develop branch, if there is one.

If you're joining an existing project, find out what team is working on it and ask to be added to the team rather than the repo itself.

Every time you start a new fix or feature, create a new branch for your work. Each branch should correspond to a single fix or feature.
Try to follow a naming scheme when making branches:
- New features start with "feat-"
- Bug fixes start with "fix-"
- Everything after the prefix should be short but helpful
Commits should represent small steps toward task completion, not completion of the entire fix/feature.

Please fill out the PR template in its entirety. If something doesn't apply, mark it as N/A (Not Applicable).
Make sure to ask an admin to add reviewers to your PR - if you don't your PR can't be approved.
Once your PR is approved, use a Squash Merge to merge your code into the main branch. If you feel a rebase merge is more appropriate, please talk to a reviewer.
Delete your fix/feature branch after it is merged into the main branch. It can be restored later if necessary, but deleting it keeps the branch list clean.

Branches that have not been touched in over a year should be deleted.
Project action items should be turned into issues in your repo and assigned to the appropriate personnel.
If you present results or publish a paper, please make a version tag or release on the repo that corresponds to the repo's status at the time of the presentation or publication.
Make a separate repo for results to keep the main repo clean. This repo should include a git submodule of the exact version hash of the repo that was used to obtain the results, and must include the version hash in the repo's documentation if a submodule is not included.