This manual describes the style and minimal requirements of maintaining and supporting the CadoLabs's github repositories.
- Github Repository Design
- Forks
- External services (CI and others)
- Code style and Workflow design
- Full Example
Minimal description of the repository. Should describe the main objective of the project. Clear and correct formulation is needed because it affects the SEO part.
An introductory description into the project with the necessary information required to quickly understand the main objective of the project. Should contain:
- logo (optional);
- minimal project statistics in the form of badge blocks that will provide an information about:
- current project version;
- current build status;
- current test coverage;
- text of description.
The main section with project documentation in an arbitary form (can be moved to the wiki section of the github repository). Basic form:
- Part 1. Requirements
- Minimal project requrements such as platform, operating system, native dependencies and etc.
- Part 2. Installation
- Detailed instructions for installing the project and some specific notes.
- Part 3. Usage
- The main documentation section. Arbitary form. Can be placed in the wiki section of the repository (or some of them with symlinks).
Links to arcticles that refers to the current project (articles of other companies, our articles, Medium links, reddit topics and etc). For the highly popular projects this section is optional.
Provide a link to our Contributing Rules (or put this file into the repo itself).
Provide a link to our Code of Conduct (or put this file into the repo itself).
Main sections:
- License: short description, license type, link to the license file;
- (required) license file
- About us: briefly shows the company ideals and the list of the project maintainers and top contributors.
Basic form:
- (required) company badge
- (required) company logo with sponsorship label;
- (optional) short description that describes companie's values;
- (required) short list of top maintainers and contributors.
- Example
Fork should have a changed readme: a small CHANGES section should be placed in the top of the readme file. This section briefly describes the changes made to the project: purpose, reasons and functionality.
Each repository should correspond to the modern standards and requirements of the development processes which followed by the company in a given moment. Our requirements are: full test coverage, full compliance with code style standarts and a successful build of othe project. These requirements can be achieved via:
- GitHub Actions (build and test)
- CoverAlls (test coverage)
The style of development is highly individual for each project. Workflow design should be chosen depending on the popularity and size of the project.
Use Gitflow for the big and popular project and typical PR-approach for the small project.
- Our Code of Conduct;
- Our Contributing Rules;
Follow Semver 2.0.0 standard.
It is necessary to have CHANGELOG.md file where you can always find out and see what changes have been made to each version of the project.
Follow KeepChangelog 1.0.0 standard.
(In active development)
