[bisq-network/proposals] Use a GRPC API as core API and use wrappers around for other API types (#136)

Chris Beams notifications at github.com
Thu Dec 12 20:32:51 UTC 2019


@chimp1984 wrote:

> Yes would be good to have closed proposals still highly visible. We use tags to make search easier but not the best solution. Maybe something like a project board for work in progress or staged work/proposals waiting for devs to work on it might be good?

I suggest that we:

 - tag approved proposals as `was:approved`
 - use a GitHub project board as you describe above to transition approved proposals into, e.g., `On Hold` and `Work in Progress` columns, and
 - only close an approved proposal when the work it describes has actually been delivered OR when consensus has been reached that the proposal should be dropped, at which point we add the `was:dropped` label and close the issue with an explanatory comment.

Note that the proposed `On Hold` column above is a little more general version of "waiting for devs to work on it" without being overly specific that this is the only reason that an approved proposal could be put on hold. It could be blocked on other work getting delivered first (like the Android app can't be completed without the rpc api) Maybe we want that level specificity though. `Waiting for Contributors`? If we want the generality, maybe `Blocked` is better than `On Hold`?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/proposals/issues/136#issuecomment-565174682
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20191212/d135e5eb/attachment.html>


More information about the bisq-github mailing list