We will do all that we can to keep the productivity of ourselves, and others, as high as possible -- Uncle Bob
These guidelines are based on Building a strong community Github documentation and intend to promote a better collaboration.
- Issue & Pull Request Template
- Git Commit Messages
- Milestone
- Label
- CHANGELOG
- CONTRIBUTING.md
- Resources
Issue and pull request templates should drive reporters to give all the necessary information to help reviewers.
Import the pull request template and issue template into .github folder in your repository root directory.
Multiple issue templates are prefered over single issue templates in order to specify required information for each type of issue.
Import the following issue templates into .github/ISSUE_TEMPLATE/ folder in your repository root directory:
Issue and pull request templates should contains title (h2) and description using html comment.
Preferred:
## Description
<!-- A clear and concise description of what the bug is. -->
## How to reproduce it
<!-- Steps to reproduce the behavior. -->
...Not Preferred:
**Describe the bug**
A clear and concise description of what the bug is.
**To Reproduce**
Steps to reproduce the behavior:
1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error
...Templates should promote a high contribution quality by referring contributing guidelines.
Preferred:
> Please fill out this template when filing an issue. It is based on [Excelsior Family Github guidelines](https://github.com/ExcelsiorFamily/github-guidelines).
>
> This template intends to describe a bug report. If you are describing a non existing feature, please use the [feature request template](https://github.com/ExcelsiorFamily/github-guidelines/issues/new?template=feature-request.md).
* [ ] I've read, understood, and done my best to follow the [CONTRIBUTING guidelines](/CONTRIBUTING.md).
## Description
<!-- A clear and concise description of what the bug is. -->
## How to reproduce it
<!-- Steps to reproduce the behavior. -->
...Not Preferred:
## Description
<!-- A clear and concise description of what the bug is. -->
## How to reproduce it
<!-- Steps to reproduce the behavior. -->
...Git commit messages should help reviewers to do better reviews.
Short commit messages should help reviewers to quickly understand what has been done. It should be short, clear and written at the present tense and imperative mood.
Preferred:
- Add get user feature.
- Update navigation storyboard.Not Preferred:
- Added get user feature.
- Updates navigation storyboard.Referencing issue in git commit messages should help anyone to track progress on a specific issue. Git commit messages should always reference issues at the end.
Preferred:
- Improve cache management. Related to #42.
- Remove unused ViewController method. Related to #1024.Not Preferred:
- Improve cache management.
- #1024 Remove unused ViewController method.Emojis should help reviewers to quickly and visually identify the nature of the commit. For clear visual identification start the commit message with an applicable emoji:
- 🎨
:art:when improving the format/structure of the code - 🐎
:racehorse:when improving performance - 🚱
:non-potable_water:when plugging memory leaks - 📝
:memo:when writing docs - 🐛
:bug:when fixing a bug - 🔥
:fire:when removing code or files - 💚
:green_heart:when fixing the CI build - ✅
:white_check_mark:when adding tests - 🔒
:lock:when dealing with security - ⬆️
:arrow_up:when upgrading dependencies - ⬇️
:arrow_down:when downgrading dependencies - 👕
:shirt:when removing linter warnings
Milestones should be based on iterative development and produce incremental builds. It enforces Agile methodology and promote continuous integration and deployment. It allows you to follow overall progress and create changelogs based on opened/closed issues.
Milestones should be described as increment based on software version.
Preferred:
Milestones:
- 1.1.0
- 1.2.0
- 1.3.0
- 1.4.0Not Preferred:
Milestones:
- Backlog
- Ice Box
- Release 1.0
- Release 2.0Pro tip: when closing a milestone, a git tag using software version should be created.
Milestones must have short due dates to define small increment and should only be closed when progress is at 100%, meaning that all issues and pull requests related to it are closed. If you do not consider an issue to be necessarily closed to finish your current milestone then it should be moved to another one.
Preferred:
Milestones:
- 1.1.0 - Closed 4 weeks ago
- 1.2.0 - Closed 2 weeks ago
- 1.3.0 - Closed 1 day ago
- 1.4.0 - Due by June 8, 2018Not Preferred:
Milestones:
- Backlog - No due date
- Ice Box - No due date
- Version 1.0 - Due by September 1, 2019
- Version 2.0 - Due by September 1, 2022Pro tip: when closing a milestone, webhooks can be used to automatically create a release flow.
Milestones should drive development for contributors and help them to focus on most priority issues and pull requests. Priorization should be based on comparaison and it's up to maintainers.
Pro tip: labels should help maintainers to compare issues and pull requests easily.
Labels should help contributors and reviewers to evaluate effort for a specific issue or pull request.
GitHub labels should define immutable informations about issues, in order to avoid non-updated scenarios. States should be defined in project section.
Preferred:
- Type: Feature
- Severity: LowNot Preferred:
- WorkInProgress
- CriticalColors should help contributors and reviewers to quickly and visually identify the effort to be done. It is better to use similar color styling accross categories for a consistent and stronger visual identification. Colors should be variants of Red-Orange-Green to provide a sense of priority. Red being the ones that require the most attention. Green being the ones that require little attention.
Preferred:
Severity: LowSeverity: MediumChange: MinorChange: Medium
Not Preferred:
Severity: LowSeverity: MediumChange: MinorChange: Medium
Labels should be regrouped into categories to provide consistent information about every issue. Issues cannot have more than one label from the same category.
Preferred:
- Type: Documentation
- Severity: Medium
- Change: MinorNot Preferred:
- Question
- Feature
- DocumentationPro tip: GitHub orders labels aphabetically, so following this format allows to keep categories dislayed in the same order accross every issues.
Type labels should be used to define the type of task done inside the issue:
(#00cc41)
Type: Feature: The issue is the development of a new feature of your project(#ff0000)
Type: Bug: The issue is an identified bug that needs to be fixed(#ffe700)
Type: Enhancement: The issue is a suggestion of enhancement to your project(#c3b2ef)
Type: Documentation: The issue is the creation or refinement of a document.
Severity labels are mostly used for bug-related issues. It allows to identify the critical aspects of the work implied inside the issue:
(#000000)
Severity: Blocker: The issue is blocking an impending release(#ff4000)
Severity: Critical: The issue causes data loss, crashes or hangs salt processes, makes the system unresponsive, etc(#ff8100)
Severity: High: The issue reports incorrect functionality, bad functionality, a confusing user experience, etcSeverity: Strong: The issue concerns changes to the core areas of the projectSeverity: Medium: The issue reports cosmetic items, formatting, spelling, colors, etcSeverity: Low: The issue concerns a new feature or any addition to the project.
Type of change labels are only used for pull requests. They give information about the effort needed to review a pull request:
Change: Minor: Less than 64 lines changed, or less than 8 core lines changedChange: Medium: Less than 256 lines changed, or less than 64 core lines changedChange: Master: More than 256 lines changed, or more than 64 core lines changedChange: Expert: Needs specialized, in-depth review.
Pro Tip: We strongly recommend to define core areas to help define the estimated effort.
A Changelog allows everyone to see precisely every changes and new features delivered over time in a project. It gives a great view of the chronology of all the increments made to the project.
A Changelog should be kept in a CHANGELOG.md file at the root of your repository. It should begin with a quick sentence to give the file a context.
Preferred:
Changelog
All notable changes to this project will be documented in this file.
[0.19.0] - 2018/04/20Not Preferred:
Changelog
[0.19.0] - 2018/04/20The following principles define guiding principles of what is a good changelog.
- Changelogs are for humans, not machines.
- Each entry should correspond to a new version.
- The same types of changes should be grouped.
- The latest version comes first.
- The release date of each versions is displayed.
- Add PR number and a GitHub tag at the end of each entry.
Milestones should be used to automatically generate a Changelog. Everytime a Milestone is closed, a Changelog should be generated. Every Milestone should be a section in the Changelog. A Changelog section should have the following format :
Format
[Milestone Number] - YYYY/MM/DDPreferred:
[1.6.2] - 2018/06/01Not Preferred:
01/06/2018, Milestone 1.6.2MyAPP 1.2 - 1 Jun. 2018Every entry of a Changelog should be a merged pull request.
To facilitate automated generation of a changelog, each pull request should have a Changelog section with at least one changelog line. Each of these lines should start with cl: followed by the corresponding Changelog keyword and changes description.
Preferred:
cl: Added address autocompletion on destination research.Not Preferred:
cl: Add address autocompletion.- cl: Added address autocompletion on destination research.Added address autocompletion on destination research.Here is the list the keywords to use for a complete changelog:
Addedfor new features.Changedfor changes in existing functionality.Deprecatedfor soon-to-be removed features.Removedfor now removed features.Fixedfor any bug fixes.Securityin case of vulnerabilities.