Skip to content
This repository has been archived by the owner on Feb 24, 2023. It is now read-only.

Latest commit

聽

History

History
118 lines (78 loc) 路 6.39 KB

CONTRIBUTION.md

File metadata and controls

118 lines (78 loc) 路 6.39 KB
Raw

Contribution Guide

Local development

Setting up your environment

Required software:

Recommended software:

Once you have everything installed, clone the :

In HTTPS format:

git clone https://github.com/WebReadyProjects/github-template

In SSH format:

git clone git@github.com/WebReadyProjects/github-template

Go to the newly created directory:

cd github-template

Soumission de modifications/demandes d'extraction

You must first create a fork of the github-template repository to upload your changes to. Information on creating repositories can be found in GitHub documentation.

Choose a basic branch

Type of change Branch
New release main
Bug fixes bugs/name-issue
New features dev/my-feature 
# Switch to the desired branch
git switch main

# Pull down any upstream changes
git pull

# Create a new branch to work on
git switch --create bugs/name-issue

Commit your changes after following our directives, then push the branch to your fork with git push -u fork and open a pull request on the github-template repository following the provided template.

Working with GitHub

The github-template repository is the main location for all development related information.

Incident triage

In order to best organize submitted incidents, the team has developed tools to create and sort tickets in quick ways. The incident boards make extensive use of the tagging system as well as many other APIs. The pipeline for managing incidents can be found here.

Request new features

github-template uses the RFC (request for feedback) process for new feature suggestions. It is intended to provide a consistent and controlled path for new features to enter the framework.

Many changes, including bug fixes and documentation improvements, can be implemented and reviewed via the GitHub pull request workflow.

Some of the changes are substantial, however, and we will ask that they produce consensus among the team.

Get started

In order to provide major functionality to github-template, you need to merge this repository to the rfcs folder and edit to .md. The following is a guide on how to properly create it:

  • Fork the repository github-template.
  • Go to rfcs/.
  • From the root, copy 0000-template.md to active-rfcs/0000-my-feature.md (where my-feature and descript. Do not assign an RFC number yet).
  • In order to edit the .md file it is necessary to be under the rfcs/my-feature branch.
  • Submit a pull request. As a pull request, the RFC will receive design feedback from the community at large and the author must be willing to modify it. New RFC pull requests begin at the pending_approval stage.
  • The team will decide if the RFC is a candidate for inclusion in github-template.
  • An RFC may be modified based on feedback from the team. Significant changes may trigger a new approval period.
  • An RFC may be rejected once public discussion is complete and comments have been made summarizing the rationale for rejection. A member of the team will close the pull request associated with the RFCs, in which case the RFC will enter the rejected stage.
  • An RFC may be accepted at the end of the period. A member of the team will merge the pull request associated with the RFCs, in which case the RFC will enter the active phase. Once an RFC is merged and the corresponding functionality is implemented in the github-template repository, it will become part of the next major or minor release. Once released, the RFC will enter the released stage and be locked.

For more information on RFCs, see the official repository here.

Guidelines

All validation messages must follow conventions for commits using the angular preset.

General rules

  • Validation messages must have a subject line and may have a body text. These must be separated by a blank line.
  • The subject line must not exceed 60 characters.
  • The subject line must be written in the imperative (corrective, uncorrected/corrected, etc.)
  • The body text should only contain explanations of what and why, never how. The latter belongs in the documentation and implementation.

Title Types

Here is a list of validation types used in the optimization tool created by the team :

  • patch: Create a new version of the project.
  • feat: New functionality.
  • bug: Resolve an incident.
  • docs: Implementing the documentation.
  • perf: Performance tuning.
  • style: Work on the design.
  • test: Implementation and production of various tests.
  • refactor: Improve the style of the project code.