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

Latest commit

 

History

History
91 lines (62 loc) · 3.51 KB

CONTRIBUTING.md

File metadata and controls

91 lines (62 loc) · 3.51 KB
Raw

Contributing

Project Development

We are actively developing this project by valuing working and test code over extensive documentation. However, we are using an Agile method to manage and track the project's progress.

GitHub Issues and User Stories

GitHub issues are considered as user stories with associated story points, risk and priority.

Each user story must have:

  • the story description: "As a X, I want Y."
  • the story points assigned during poker planning
  • the story's priority
  • the story's technical risk
  • the engineering task breakdown, with the ideal time allocated for each task
  • any changes to the initial engineering solution
  • all documentation, diagrams, etc. related to that story
  • all tests passing and an approved and merged pull request which references the issue
  • the steps required to demo this story
  • product owner signoff

GitHub Labels and Features

GitHub Labels must be attached to issues and are used to describe what specific aspect of the system the user story relates to.

GitHub Milestones and Iterations

Our user stories, represented as GitHub issues, are assigned to iterations, represented as GitHub milestones. Iterations occur every two weeks and comprise a set of user stories.

GitHub Tags and Releases

Releases occur every three iterations, are accompanied with a release document and are tagged within the repository.

Pull Request Process

Pull requests can be created after branching from the master trunk or by forking the repository.

If you create any branch, the branch name must be in this format, or our continuous integration service will fail your build and you will not be able to merge:

<issue-number>/<short-description-of-issue>

An example might be:

87/store-user-session-data

In order for a pull request to be merged, it must have at least 2 approvals by reviewers that can validate your changes. Additionally, all continuous integration services must pass.

Git Commit Style

We will be following a similar approach to the Git commit guidelines.

Every commit in our repository must have a well-formatted message, or our continuous integration service will fail your build and you will not be able to merge:

[#<issue-number>] <very-short-summary-of-changes>

- Detailed bullet
- list of
- important changes

An example might be:

[#12] Added user login feature

    - Created user model
    - Added Oauth library to our dependencies for authyaoentication
    - Created a login page

Coding Style Guide

We lint all source code with our continuous integration services using Google's Style Guide as a reference.

Python

HTML and CSS

Javascript

Unit Tests and Code Coverage

We expect every pull request to have unit tests. In order to ensure that unit tests are always being written, we are using CodeCov as a service which monitors for unit test code coverage. If the total code coverage falls below a certain preset percentage, or if that pull request introduces a large negative diff in our code coverage, our CI build will fail and you will not be able to merge.