Guide to creating and managing Q-CTRL repositories

Source code created at Q-CTRL is managed using Git repositories. Q-CTRL uses GitHub to host these repositories.

Types of repositories

The type of repository created defines the default configurations that are set as well as some of the naming conventions. There are two types of repositories:

  1. Development repositories
  2. Research repositories

Development repositories

Development repositories are the default type. They are defined as repositories that contain any source code that will be directly used to contribute to Q-CTRL’s product. This can refer (but is not limited) to:

  • Applications
  • Configurations
  • Documentation
  • Infrastructure
  • Software

Development repositories have strict requirements regarding access control as well as configurations to ensure a higher standard of code quality.

Research repositories

Research repositories are defined as repositories that are used for research purposes (including spikes). In order to encourage quick development for proof of concepts, the configurations on research repositories are less strict. As research repositories are held to a lower standard, they cannot be directly used to contribute to Q-CTRL’s products and should not be long-lived. A research repository MUST be correctly configured before it can become a development repository. It is also prohibited from using any CI/CD tooling.

Naming repositories

Refer to repository naming conventions.

Repository descriptions

Repository descriptions MUST take the form <emoji> <project name> (see project naming conventions).


Q-CTRL Python Open Controls🎛 Q-CTRL Python Open Controls
Q-CTRL Template🧩 Q-CTRL Template

Ownership of repositories

All repositories MUST have at least one owner. An owner MUST be a team and not an individual person. Teams are defined by Q-CTRL’s organization structure.

A repository MAY have more than one owner and ownership of the repository can refer to:

  • All code in the repository.
  • A folder.
  • A file.

For example, for a GraphQL project, the Back-end Engineering team may own the API code, the Front-end Engineering team may own the GraphQL schemas defined in a folder, and the DevOps Engineering team may own certain CI files.

Repository visibility

All repositories MUST be private unless there is a reason to make them public. Some reasons that a repository would be made public include:

  • The repository contains an open source project.
  • The repository needs to be publicly viewable by people outside of the Q-CTRL organization.
  • The repository is a fork of another public repository.

Creating, modifying, and archiving repositories

Repositories are controlled using the Q-CTRL Repositories Manager. This is in accordance with Q-CTRL’s Operations security policy and is integral to Q-CTRL’s ISO/IEC 27001 compliance.

IMPORTANT: Any repositories created outside of the Q-CTRL Repositories Manager will be automatically and permanently deleted. This action is not reversible.

Creating and modifying repositories

See creating or modifying a repository.

Archiving repositories

See archiving a repository.


All repositories MUST use the standard configurations. If the repository is a development repository, then it MUST use the development configurations.

Standard configurations

Automatically delete merging branchThis is to avoid stale branches. Restore the branch if more contributions are needed.
Issues disabled for private repositoriesUse Jira to create issues. Issues are to be used for public facing issues only.
Master branch protectionThe master branch is protected and no commits can be pushed to it without a pull request.
Squash merges onlyAll other merge types are disabled. See contributing.
Wiki is disabledUse README files or contribute to Q-CTRL Elements and Q-CTRL Docs for documenting depending on the use case.

Development configurations

Dismiss stale reviewsDismissing stale reviews will require an owner to approve a pull request if any changes have been done since their last review. This is in place to avoid the situation where a pull request is approved, then a change is introduced that would have not been approved but was merged anyway.
Require pull requests to be approved by an ownerAn owner must approve a pull request before it can be merged.