EPIC: Consolidate our GitHub "Workflow" into *Single* Reference

## Situation / Intro

At present we have ***six*** GitHub repositories that contain "_bits_" of our "Workflow":

+ [https://github.com/dwyl/**contributing**](https://github.com/dwyl/contributing) - General guidance on contributing to a GitHub project
+ [https://github.com/dwyl/**definition-of-done**](https://github.com/dwyl/definition-of-done) - definition of "done"
+ [https://github.com/dwyl/**process-handbook**](https://github.com/dwyl/process-handbook) - internal "processes" for dwyl projects at the time of writing it's only got _one_ image and is very [_text heavy_](https://github.com/dwyl/process-handbook/tree/53d2b71adb9ee3cac8c1f5ee3dd2d87dbfbfc26d) ...
+ [https://github.com/dwyl/**github-reference**](https://github.com/dwyl/github-reference) - GitHub for non-technical people ...
+ [https://github.com/dwyl/**product-owner-guide**](https://github.com/dwyl/product-owner-guide) - targeted at the Product Owner of the project
+ [https://github.com/dwyl/**labels**](https://github.com/dwyl/labels) - explains the purpose of and use-case for each of the labels.

Additionally we have [https://github.com/dwyl/**dwylbot**](https://github.com/dwyl/dwylbot) which _attempts_ to "guide" people
to follow our "workflow" by posting helpful hint-messages in the issue(s) & pull requests.

_Unfortunately_, these repos are not _congruent_.

Furthermore they do not consider the use of [**GitHub Project Boards**](https://help.github.com/articles/about-project-boards/) for _visualising_ the progress of user stories through the "pipeline".
Allowing people to "***drag-and-drop***" issues from "Todo" to "In Progress" is _much_ better UX than **_manually_ applying** a `Label` and **_manually_ assigning** the issue to themself ... the act of dragging the issue to "In Progress" column should trigger "WorkflowBot" to perform both of these "admin" actions (add label & assign to user).

## _Desirable_

It would be _preferable_ to have a **_single_ repository** that defines our _complete_ GitHub Workflow.

**Note**: I'm not _suggesting_ that the `product-owner-guide` is not _useful_ (_in fact I think that it's **really** good!_) just that it's not _tightly_ associated with the GH Workflow e.g:

> I _suggest_ we re-name the [https://github.com/dwyl/**contributing**](https://github.com/dwyl/contributing) to "***github-standard-workflow***" (_because including the word "**standard**" means that **nobody** can "argue" with it ... https://github.com/standard/standard ..._) 🙄
And then _merge_ all the other _individual_ repositories into the newly renamed one as `.md` files within it.
We could even craft it into a "GitBook" the way "ThouhtBot" did with: [https://thoughtbot.com/playbook](https://user-images.githubusercontent.com/194400/36225088-7ba06512-11c1-11e8-8002-d65e6aeb2dfb.png)

## Todo

+ [ ] Collect _feedback_ from existing "_users_" of the dwyl GitHub Workflow (team members & clients)
+ [ ] Revise our _existing_ GitHub Workflow in response to feedback.
+ [ ] _Use_ **GitHub Project Boards** (_trello-like drag-and-drop_) so that _everyone_ on the project can see at a _glance_ what stories/tasks (issues) are being worked on and by _who_. (_there's a **reason** why Trello is so popular and tools like "ZenHub" and "Waffle.io" exist ... people **want** a visual "Board"_)
+ [ ] Determine which other columns we would like to Add to the standard GitHub Project Board (_the `default` columns are `Todo`, `In Progress` and `Done`_) > can we open a _separate_ issue for this?
+ [ ] "WorkflowBot" should automatically create the full array of Project Board columns when the app is added to the project using the API: https://developer.github.com/v3/projects/columns

### Sections to Include in the Revised Guide

The contents table should include:

+ [ ] Contributors - link to a _revised_ `CONTRIBUTING.md` that is _simplified_ for Open Source.
+ [ ] Separate guide
and _detailed_ for "client work".
+ [ ] Stakeholders - anyone who has a vested interest in the success of the project but who may not be involved in _delivering_ the work.
+ [ ] Product Owner Guide - we can link to the (_revised_) `product-owner-guide`

## _Pain Point_

Given that we don't have a _single_ place we can point people to,
I spent a _chunk_ of time _attempting_ to summarise the "Workflow"
for one of our clients in a "single page" diagram:

---

## Workflow Diagram

_**Click image** to view **large version**!_
_**Edit** this Google Doc: https://goo.gl/2UNVbw (using [draw.io](https://www.draw.io))_

This workflow is optimised for our [**biggest constraint**](https://en.wikipedia.org/wiki/Theory_of_constraints): **_UI Developer_ Time**.

> **Please Note**: I am not for a _moment_ suggesting this diagram is "perfect"! in fact I think it's "_meh_".
But it's just to illustrate that I had to create _several_ new columns in addition to the `default` ones that come with GitHub Project Boards and then _explain_ (_visually_) what each one is for.

## Questions:

+ [ ] Should we use GitHub Project Boards for our Open Source _modules_? or should we `limit` the use of the boards to the actual _Projects_? How much "_structure_" do Open Source modules need in their workflow? (_how much is "too much" which results in putting people **off* contributing...?_)
+ [ ] Should "WorkflowBot" be applicable to _all_ types of GitHub Repos or just "Apps" worked on by teams of (_paid_) developers.

@Cleop / @iteles this is what I mentioned this morning in our _verbal_ discussion.
I've attempted to capture as much as possible in this issue to ensure that we cover _everything_ in the "Epic".