Add a proper README.md

[jdrew1303]

The blow is the main part of the layout. Some of the processes need to be changed to reflect the actual process. We dont have tests at the moment. There needs to be a section on docker. Possibly one on configuring HypriotOS. We're also not using yarn 😛 The structure however is solid.

blurb about project

| | |

Overview | Features | Installation | Updating | Setup | Structure | Credits | License

┻┳|
┳┻| _
┻┳| •.•) 💬 "Tip: blah blah blah give core help with this :)"
┳┻|⊂ﾉ
┻┳|

Development

Dependencies

• Yarn Package Manager
• Node.js > 6.0

# clone our repo
git clone 

# change directory to our repo
cd ./repo_name

# install the repo with npm
yarn install

# start the server
yarn start

:arrow_up:

Kanban Process

We currently use a flavour of Kanban to monitor our progress. The normal lifecycle for an issue is:

1. Story Prep Here we flesh out the internals of the issue. We add a case number and link it back to the original story/bug. We also add it to its milestone (we use these like epics to group related issues).
2. Ready for Work When an issue reaches here it is ready to be worked on by developers. Developers are free to pull from this work pool. The preference is to take the topmost item (order denotes priority). Some issues may be blocked for various reasons. These receive one of a few blocked labels.
3. In Progress The issues here are being activly worked on by developers.
4. Ready for Review Issues in this state are considered complete by the developer (meets the requirements outlined in the issue, is documented and has associated tests, does not break any existing tests), they have created a pull request and it is ready to be reviewed by other members of the team for correctness.
5. In Review It is being reviewed by one or more people. Where issues are found with the current unit of work then the issue is deemed to be stalled while a developer fixes any change requests. One these are completed it is ready to be merged.
6. Week x Once an issue is deemed fit for merging then it goes into this column. The x in this case is the current week number. This allows us to do very basic velocity tracking by treating it as a mini sprint (without the commitment to work overtones usually associated).

Aside from this core workflow, there are other columns added to allow for handling bugs and information about upcoming framework releases:

• Community Watchlist is issues that we want to track in frameworks and libraries that we use. Some of these will be features that we would like to incorporate. Others are bugs that are affecting our application but are scoped to be fixed and may not require patching by us.
• Icebox is for issues that are put on hold for now and have been deferred until an unknown date.
• Bugs is for managing issues raised by QA. They may or may not be active bugs/defects.

:arrow_up:

Test

:arrow_up:

Team

	❓
James Drew	❓

:arrow_up: