From 17ca4afc993a57bc727581bd15ce34cc787ede06 Mon Sep 17 00:00:00 2001 From: Piotr Mitros Date: Mon, 11 Jun 2012 11:56:20 -0400 Subject: [PATCH] Process standards; should this be the same document? --- doc/code_standards.txt | 28 +++++++++++++++++++++------- 1 file changed, 21 insertions(+), 7 deletions(-) diff --git a/doc/code_standards.txt b/doc/code_standards.txt index 8344db6ac5..84180d3d7e 100644 --- a/doc/code_standards.txt +++ b/doc/code_standards.txt @@ -1,9 +1,11 @@ -Coding Standards - Scope This document describes code quality standards for the i4x -system. Code falls into four categories: +system. + +1. Coding Standards + +Code falls into four categories: * Deployed. Running on a live server. * Production. Intended for deployment. @@ -11,7 +13,7 @@ system. Code falls into four categories: minimal implementations to support further development. * Prototype. Experimental new features. -Deployed +1.1 Deployed The standards for deployed code are identical to production. In general, we tend to do either: @@ -21,7 +23,7 @@ before deploying. 2) Use code on a staging or internal server for a week before deploying. -Production +1.2 Production All production code must be peer-reviewed. The code must meet the following standards: @@ -38,7 +40,7 @@ following standards: All code paths must be manually or automatically verified. -Scaffolding +1.3 Scaffolding All scaffolding code should be peer-reviewed. The code must meet the following standards: @@ -56,8 +58,20 @@ following standards: 7) Purpose. The scaffolding must provide a clean reason for existence (e.g. define a specific interface, etc.) -Prototype +1.4 Prototype Prototype code should live in a separate branch. It should strive to follow PEP8, be readable, testable, and future-proof, but we have no hard standards. + +2. Process Standards + +* Code should be integrated in small pull requests. Large commits + should be broken down into small commits for integration. +* Every piece of production and deployed code must be reviewed prior + to integration. +* Anyone on the edX team competent to review a piece of code may + review it (this may change as the team grows). +* Each contributor is responsible for finding a person to review their + code. If it is not clear to the contributor who is appropriate, each + project has an owner