meta: Issues and label system

Issues in go-ipfs are mess, with almost 500 issues and problems with pipelineing we think that we can improve our and general workflow by organising issues and labels. This would make our and contributors work easier by highlighting areas of work that are in priority and allowing for faster navigation in issues and PRs.

Proposals from my side:
1. Prefixing issues with subsystem name (namesys, cli, test, sharness, etc.) or type (like this issue). Issue title is static for the most part, as is the subsystem or type of an issue.
2. Changes in label system. This is big part of this issue. As we have to go through all issues either way (to clean things up) we decided that changing labelling system and labelling all issues best we can.

Currently we are looking at two styles of labels, [docker](https://github.com/docker/docker/labels) and [ethcore/parity](https://github.com/ethcore/parity/labels).

Parity system is not clear at first glance that is why I will try to explain it a bit:

Labels in that system are divided into groups and differ by first letter. Majority of labels are under `A` (related to PRs) and `F` (related to actionable features) and would contain labels like: `A0-needsrewiew`, `A1-inprogress`, `A2-signoffneeded`, `A3-justtoobig` `A4-looksgood`, `A5-insubstantial` and the `F` group: `F0-security`, `F1-bug`, `F1-build`, `F2-annoyance`, `F3-tests`, `F4-documentation` and so on. As you can see the number is index and usually priority which can be seen in the `P` (Priority group): `P0-dropeverything`, `P2-asap`, `P5-sometimesoon`, `P7-nicetohave` and `P9-somedaymaybe`. This system characterises by very high information density as someone accustomed with it is able to use and assign issues using only two characters. It has a bit higher learning curve that very verbose docker's system but doesn't leave leave new users out.

@gavofyork: It would be awesome if you could comment on how the label system is working for you in ethcore/parity

I personally like the way parity does it as it has lower noise to information ratio and allows for assigning and skimming over labels with minimal thought required when you get used to it. For me it is important as the less thought spent on management equals more time and higher performance during coding.
3. Active and responsive assignment of labels, interlinking and closing issues. This is something we as developers need to work on. We decided recently to make go-ipfs issue tracker about go-ipfs only (previously it was about everything ipfs connected). If it can't be fixed by code or implemented right away then its place isn't go-ipfs tracker. We have many issue trackers open, you can see most of them here: https://github.com/ipfs/community/blob/master/contributing.md#reporting-issues

I would like to here everyone's opinions, no matter if you are collaborator, contributor, user or just bypasser, I love to here it, as perspectives and ideas of unconnected people make OpenSource work.

Bellow in a comment I will make list of labels I think of using.

**cc** @ipfs/go-ipfs-team @em-ly @RichardLitt

P.S. Sorry for the wall of text.