First review

Ideas.md

@@ -0,0 +1 @@
+# The Ideas

README.md

@@ -1,9 +1,8 @@
 # Incubaid Agile Development Process
 
-Incubaid is a Belgian incubator trying to deliver exciting infrastructure products in the market.
-We work with a group of startups to deliver the most unique products (see www.incubaid.com).
+[Incubaid](http://www.incubaid.com) is a Belgian startup incubator with a proven track record of bringing innovative and exciting cloud infrastructure products to market.
 
-The goal of this ebook is to describe a set of conventions how a development process can work based on agile methodologies. 
+The goal of this ebook is to describe a set of conventions on how a development process can work based on agile methodologies. 
 
 These ideas are opinionated but do result out of years trying to create good products and still maintain flexibility.
 
@@ -15,15 +14,15 @@ Please use the issue tracker to ask questions, post feedback, ask for improvemen
 
 * https://github.com/Incubaid/dev_process/issues
 
-## agile
+## Agile
 
-- we believe in agile development processes like Scrum & Kanban
-- we believe the best process use ideas from both
+- We are strong advocates of [Agile software development](https://en.wikipedia.org/wiki/Agile_software_development) processes like [Scrum](https://en.wikipedia.org/wiki/Scrum_(software_development)) and [Kanban](https://en.wikipedia.org/wiki/Kanban_(development)
+- We believe the best process uses ideas from both
 
-## book
+## Book
 
-- [online version](https://gig.gitbooks.io/agile/content/) (html)
-- [pdf version](https://www.gitbook.com/download/pdf/book/gig/agile)
+- [Online version](https://gig.gitbooks.io/agile/content/) (html)
+- [PDFpdf version](https://www.gitbook.com/download/pdf/book/gig/agile)
 
 ## TOC
 

SUMMARY.md

@@ -4,12 +4,12 @@
    * [Terminology](terminology.md)
    * [Kanban](kanbanoption.md)
 * [The Ideas](Ideas.md)
-   * [Github Intro](github_integration.md)
-   * [Github Organizations](github_accounts.md)
-   * [Github Repos](repos.md)
-   * [Github Milestones](github_milestones.md)
-   * [Bugs & Feature request funnel](funnel.md)
-   * [Stories are the start of all](stories.md)
+   * [GitHub Intro](github_integration.md)
+   * [GitHub Organizations](github_accounts.md)
+   * [GitHub Repos](repos.md)
+   * [GitHub Milestones](github_milestones.md)
+   * [Bugs & Feature Request Funnel](funnel.md)
+   * [Stories are the Start of All](stories.md)
    * [Tickets/Tasks](tickets_tasks.md)
    * [Labels](labels.md)
    * [Visualize](visualize.md)
@@ -20,7 +20,7 @@
    * [Telegram](telegram.md)
    * [0-Bugs](0-bugs.md)
 * [Agile Principles](agileprinciples.md)
-   * [80% rule](agileprinciples/Pareto.md)
+   * [80% Rule](agileprinciples/Pareto.md)
    * [Change Is Not Bad](agileprinciples/ChangeIsNotBad.md)
    * [How To Eat An Elephant](agileprinciples/HowToEatAnElephant.md)
    * [Fast But Not So Furious](agileprinciples/FastButNotFurious.md)
@@ -30,7 +30,6 @@
    * [End User Involvement](agileprinciples/UserInvolved.md)
    * [Testing Is Not For Dummies](agileprinciples/Testing.md)
    * [No Place For Snipers](agileprinciples/Collaboration.md)
-* [more Info](moreinfo.md)
+* [More Info](moreinfo.md)
    * [Tools](tools.md)
-* [FAQ](faq.md)
-
+* [FAQ](faq.md)

funnel.md

@@ -1,32 +1,33 @@
-## bugs & feature requests funnel
+## Bugs & Feature Requests Funnel
 
 IN: BUGS - FEATURES ->
 
 ![](http://www.rocketwatcher.com/wp-content/uploads/2011/01/Funnel-mod.jpg)
 
 OUT: STORIES
 
-### principles
+### Principles
 
-- The idea is that in a code repo you log all the bugs & feature requests
-- anyone can report bugs or feature requests
-- the [productowner](roles.md) will sort through the issues & give them priorities (use labels)
-- the bugs or FR's are grouped and planned to be executed (attached to milestones)
-- there can be lots of milestones in a code repo, these milestones are used to link X nr of bugs/FR's to a story in the milestone repo, see milestone section to understand purpose.
+- The idea is that in a code repo you log all the bugs and feature requests
+- Anyone can report bugs or feature requests
+- The [product owner](roles.md) will sort through the issues and give them priorities (using labels)
+- The bugs or feature request are grouped and planned to be executed (attached to milestones)
+- There can be lots of milestones in a code repo, these milestones are used to link X number of bugs/FR's to a story in the milestone repo, see milestone section to understand purpose
 
 
 ### DO NOT
 
-- plan work directly on FR's or BUGs, this result in very bad planning
-  - there is a shortcut to create tasks automatically though, see below 
+- Plan work directly on feature request or bugs, this results in very bad planning
+  - There is a shortcut to create tasks automatically though, see below 
+
 
 ### WHY
 
-- This forces product owners to think about organizing work & priorities
+- This forces product owners to think about organizing work and priorities
 
-### how to automate task creation
 
-- if you put $storycardname: at beginning of title of issue then this bug/fr will become a task underneath the story
-- this only works if $storycardname is unique (which has to be for active stories)
-- this is done by the incubaid development process tools
+### How to automate task creation
 
+- If you put $storycardname: at a prefix to the title of the issue then this bug/FR will automatically become a task underneath the story
+- This only works if $storycardname is unique (which has to be for active stories)
+- This is done by the Incubaid development process tools

github_accounts.md

@@ -4,15 +4,15 @@
 
 We define 2 types of organizations
 
-### Product github organization (prodorg)
+### Product GitHub organization (prodorg)
 
-- Repo's's inside which to develop a product
+- Groups repositories related to the development of a product
 - Typically code repositories or the home repository 
 
 
-### Project github organization (projorg)
-- repo's inside which to manage projects or customers or sales
-- github is an amazing tool to store all kinds of processes
-- as you can see in the section about repo's we use this for a lot of purposes.
+### Project GitHub organization (projorg)
+- Groups repositoris related to the management of projects, customers or sales
+- GitHub is an amazing tool to store all kinds of processes, next to just code
+- As you can see in the section about repo's we use this for a lot of purposes
 - THERE IS NO CODE IN PROJORG
 

github_integration.md

@@ -1,28 +1,27 @@
-## github integration
+## GitHub Integration
 
-- git/github is a most amazing tool to track changes and can be used in many more ways than people deem possible.
-- We suggest using github for
-  - specs
-  - documentation
-  - planning work (stories in home repo, see [stories](stories.md))
-  - tracking of bugs
-  - tracking of feature requests
-  - of course all coding work using pull requests as tool to track changes
-  - tickets from customers (*)
-- why
-  - its important that all change is being tracked and people get visibility on everything which happened and is going to happen
+Git/GitHub is a most amazing tool to track changes and can be used in many more ways than people deem possible.
 
+We suggest using GitHub for:
+  - Specs
+  - Documentation
+  - Planning work (stories in home repo, see [stories](stories.md))
+  - Tracking of bugs
+  - Tracking of feature requests
+  - And of course all coding work using pull requests as a tool to track changes
+  - Tickets from customers (*)
+- Why
+  - Its important that all change is being tracked and people get visibility on everything which happened and is going to happen
 
-### requirements
 
-- if security is important to you make sure everyone uses 2-factor authentication
-- if possible use clean login names on github, many people use funny names which is nice but makes it hard for people to remember
-  - our suggested login names are  $first7lettersLastName+$firsLetterFirstname e.g. Kristof De Spiegeleer becomes *despiegk*
+### Requirements
 
+- If security is important to you make sure everyone uses 2-factor authentication
+- If possible use clean login names on GitHub, many people use funny names which is nice but makes it hard for people to remember
+  - Our suggested login names are  $first7lettersLastName+$firsLetterFirstname e.g. Kristof De Spiegeleer becomes *despiegk*
 
 
-
-### terminology git related
+### Terminology Git related
 
 #### Branch
 
@@ -113,4 +112,4 @@ We support some 'magic' comment that you can use in issue and help to manage sto
 `!! prio $prio` Set the prioriry of an issue. $prio is checked on first 4 letters, e.g. critical, or crit matches same  
 `!! p $prio` alias above
 
-`!! move gig-projects/home` move issue to this project, try to keep milestones, labels. if it's a story, move all the tasks related.
+`!! move gig-projects/home` move issue to this project, try to keep milestones, labels. if it's a story, move all the tasks related.

github_milestones.md

@@ -1,41 +1,42 @@
-## Github Milestones (DRAFT)
+## GitHub Milestones (DRAFT)
 
-We are still struggling how to best use milestones, all feedback very welcome.
+We are still struggling on how to best use milestones, all feedback is very welcome.
 
-#### In Github Product Organization (prodorg)
 
-- release nr or name of a product e.g. JS8.1  (from jumpscale 8.1)
-  - used to organize work around a product release !!! 
-- can be used in home & code repo's
-- if different components make up a product & version is per product then this milestone name needs to be the same over the relevant repo's !!!
-- this milestone is used to group FR & BUGS
-- stories can link back to a specific milestone & issues in a repo
-  - its handy to use a query to show e.g. all bugs of e.g. jumpscale8 repo and then link this 1 query to a story card in the projorg
+#### In Product organizations (prodorg)
+
+- Release number or name of a product, e.g. JS8.1  (JumpScale 8.1)
+  - Used to organize work around a product release !!! 
+- Can be used in home & code repo's
+- If different components make up a product & version is per product then this milestone name needs to be the same over the relevant repo's !!!
+- Milestone is used to group feature requests and bugs
+- Stories can link back to a specific milestone & issues in a repo
+  - Its handy to use a query to show e.g. all bugs or e.g. JumpScale8 repo and then link this 1 query to a story card in the projorg
 
 There are maximum 3 milestones per prodorg repo
 
-- version nr 1 (nearest to today)
-- version nr 2 (next release)
-- roadmap (always use this name !!!)
+- Version number 1 (nearest to today)
+- Version number 2 (next release)
+- Roadmap (always use this name!)
 
 - **bugs are NEVER but on roadmap**, following this page they are in version 1 or 2 after now.
 
 - FR can be put on roadmap when not in one of 2 next releases, but no specific timing yet
 
 DO NOT
-- use timing milestones e.g. may16
+- Use timing milestones, e.g. may16
 
-#### In Github Proj Organization (projorg)
 
-- a milestone is a time on which a company (organization) wants to deliver something 
-- this can be e.g.
-  - date to deliver a project to a customer (for a proj_... repo)
-  - just a date to put a stick in the ground e.g. gen1_release which is pinned to a certain date
-  - a certain month e.g. June
-- a story can only belong to one milestone
-- tasks belong to a story and as such also to a milestone
 
-DO NOT
-- use version milestones e.g. js8.1
+#### In Project organizations (projorg)
 
+- Milestone is a time on which a company (organization) wants to deliver something 
+- This can be e.g.
+  - Date to deliver a project to a customer (for a proj_... repo)
+  - Just a date to put a stick in the ground, e.g. gen1_release which is pinned to a certain date
+  - a certain month e.g. June
+- Each story can only belong to one milestone
+- Tasks belong to a story and as such also to a milestone
 
+DO NOT
+- Use version milestones, e.g. js8.1

kanbanoption.md

@@ -1,5 +1,5 @@
 
-## kanban as a nice add-on to Scrum
+## Kanban as a Nice Add-on to Scrum
 
 Kanban primarily follows four core principles (info from [link](https://www.scrumalliance.org/community/articles/2014/july/scrum-vs-kanban))
 
@@ -15,7 +15,7 @@ Kanban primarily follows four core principles (info from [link](https://www.scru
 - Continuously improve
 	- Once the Kanban system is in place, it becomes the cornerstone for a culture of continuous improvement. Teams measure their effectiveness by tracking flow, quality, throughput, lead times, and more. Experiments and analysis can change the system to improve the team's effectiveness.
 
-### we need features from both
+### We need features from both
 
 
 | Advantages of Scrum        | Advantages of Kanban           |
@@ -28,11 +28,11 @@ Kanban primarily follows four core principles (info from [link](https://www.scru
 | Allows client to change priorities and requirements quickly | Reduction of wasted work/wasted time |
 
 
-### why can Kanban help as addon
+### Why can Kanban help as add-on
 
-Kanban: A Good Fit for Teams that View Work as Firefighting
+Kanban: A Good Fit for Teams that View Work as Firefighting.
 
-Toyota production plants and Scrum teams exist to build product. The literature speaks of successful application of kanban in the service industry, analogous to firefighting or hospital emergency rooms. It's tricky to schedule your next fire unless you live in the world of Fahrenheit 451. 
+Toyota production plants and Scrum teams exist to build product. The literature speaks of successful application of Kanban in the service industry, analogous to firefighting or hospital emergency rooms. It's tricky to schedule your next fire unless you live in the world of Fahrenheit 451. 
 
 Many development teams run in firefighting mode, often with "swooping" from the Product Owner during a Sprint. And getting into a discipline is hard: it's easy to want to be able to react immediately to customer change instead of integrating a request into the business plan, and it feels good to release whenever you see fit. ([link](https://www.scruminc.com/alternative-to-kanban-one-piece/))
 

labels.md

@@ -1,52 +1,55 @@
-## labels
+## Labels
 
-### type
+### Type
 
-- to define type of issue
-- 1 needs to be used (and only 1) !!!
+- To define type of issue
+- 1 needs to be used (and only 1)!
 
-| name | description | used in | 
+| Name | Description | Used in | 
 | --- | --- | --- | --- |
 | story |  | home, org, project | 
 | task |  |  home, org, project |
 | ticket | type | org, project |
-| bug | issue reported by anyone | code,ays,doc,www,cockpit |
-| feature | improvement asked for by anyone | code, project,ays,doc,www,cockpit, org |
-| question | anyone wants to ask something | home, code, project,ays,doc,www,cockpit, org | 
-| monitor | monitoring system found an issue | project,cockpit,www |
-| lead | lead for sales, can convert in business | project,org |
-| test | a test task | org,cockpit |
+| bug | issue reported by anyone | code, ays, doc, www, cockpit |
+| feature | improvement asked for by anyone | code, project, ays, doc, www, cockpit, org |
+| question | anyone wants to ask something | home, code, project, ays, doc, www, cockpit, org | 
+| monitor | monitoring system found an issue | project, cockpit, www |
+| lead | lead for sales, can convert in business | project, org |
+| test | a test task | org, cockpit |
 
-### priority
 
-- define priority in which issue needs to resolved
-- 1 needs to be used (and only 1) !!!
+### Priority
 
-| name | description | used in |
+- Define priority in which issue needs to resolved
+- 1 needs to be used, and only 1!
+
+| Name | Description | Used in |
 | --- | --- | --- |
 | critical |  | all |
 | urgent |  | all |
 | normal |  | all |
 | minor |  | all |
 
-### process 
 
-- define 2 optional process related labels
+### Process 
+
+- Define 2 optional process related labels
 
-| name | description | used in |
+| Name | Description | Used in |
 | --- | --- | --- |
 | duplicate |  | all |
 | wontfix |  | all |
 
-### state
 
-- define state of issue in the kanban flow
-- 1 needs to be used (and only 1) !!!
-- REMARK
-  - these states need to be useful over all projects e.g. over customer projects, code projects, stories, ...
-  - good filters should be used in waffle to represent a kanban well 
+### State
+
+- Define state of issue in the Kanban flow
+- 1 needs to be used, and only 1!
+- Remark
+  - These states need to be useful over all projects, e.g. over customer projects, code projects, stories, ...
+  - Good filters should be used in waffle to represent a Kanban well 
 
-| name | description | used in | 
+| Name | Description | Used in | 
 | --- | --- | --- | 
 | new | new or issue in backlog (is no label, is the default)| all |
 | inprogress | people are working on it | all |