Add a proposal-accepted tag

[ValarDragon]

Right now, there isn't a good way to discern via our tagging standards between a proposal we're debating on, and a proposal we've accepted and want to implement. I propose that we add a proposal-accepted tag, and that we remove the proposal tag once its clear that we want to go ahead with a proposal. Golang has one and I think it makes a lot of sense: https://github.com/golang/go/issues?q=is%3Aopen+is%3Aissue+label%3AProposal-Accepted

[alexanderbez]

I think this is a great idea! Do you think we should setup preliminaries for when a proposal can be "accepted? i.e., a thorough enough spec has been laid out with uses cases and potential implementation details.

[ValarDragon]

Thats a good point. I think that there should be some indication of how the proposal would be implemented. For non-minor changes, I think the API changes should have concrete proposals.

Not sure if we want to require a thorough spec, because I imagine a lot of proposals are going to be small things / on the scale where making a spec may not be worth the time. (Rather, updating the docs would be sufficient)

[alexanderbez]

@ValarDragon, just a detailed description will suffice...like an abstract. @ebuchman thoughts?

[ValarDragon]

That sounds good to me!

[rigelrozanski]

Cool - just added to Cosmos-SDK

[xla]

The problem we run into is that tags just become a dumpster for all kinds of concerns. In tendermint we are trying to use tags now as classification what domain they belong to and of what nature they are (feature, bug, etc.). We just introduced a boad to track design documents and proposals.