| 2 Aug 2018 |
 @bridge:decred.org | [slack/thedecreddigest] lol. i suppose i meant incentivised and automated. i’m thinking of how we can open it up to avoid the “decred contractor group is centralised and won’t approve my work for payment” complaints. but yeah, that way is a good starting point! | 15:03:31 |
| @bridge:decred.org | [slack/jy-p] hmmm, fair point. maybe if disputes get escalated to the proposal system, it would include the full history of the dispute | 15:05:07 |
| @bridge:decred.org | [slack/thedecreddigest] yeah i like that idea, that way all disputed decisions are in effect made ran past stakeholders for a final say, and the whole prior decision-making process is transparent. | 15:08:43 |
| @bridge:decred.org | [slack/thedecreddigest] yeah i like that idea, that way all disputed decisions are in effect ran past stakeholders for a final say, and the whole prior decision-making process is transparent. (edited) | 15:08:53 |
| 3 Aug 2018 |
| @bridge:decred.org | [slack/decoy] having a solid dispute resolution process would really benefit us in the long run. one idea would be to use an independent 3rd party of 1-3 people to rule on disputes. both parties would agree to honor the decision and the cost of their review time would be born by the losing party. | 02:20:55 |
| @bridge:decred.org | [slack/decoy] once pi goes live will the dev fund be a corporate entity? is the fund subject to legal action by aggrieved contractor's? | 02:23:22 |
| @bridge:decred.org | [slack/decoy] @jy-p responding to your 7:39am post in general regarding non-performance issues. | 02:32:11 |
| @bridge:decred.org | [slack/decoy] i get where you are coming from here and in practical terms think you are absolutely right. but with decentralized contract admin i think we need to avoid subjectivity like the plague. extending grace is well intended but in this system i think it could backfire and open us up to criticism. i think stakeholders will learn a single non-performance issue on a minor contract item should not be held over the head of contractors. | 02:32:44 |
| @bridge:decred.org | [slack/decoy] i'll support the direction you take this but believe noting the actions publicly would be the best direction. i would also like each action to allow for a response from the contractor to explain the cause for the issue. "my lead dev bought a boat and sailed off in the direction of the Maldives." contractor's will learn no one is being picked on it's just how the system works best in a decentralized context. full transparency. | 02:37:14 |
| @bridge:decred.org | [slack/decoy] i'll support the direction you take this but believe noting all admin actions publicly would be the best direction. i would also like each action to allow for a response from the contractor to explain the cause for the issue. "my lead dev bought a boat and sailed off in the direction of the Maldives." contractor's will learn no one is being picked on it's just how the system works best in a decentralized context. full transparency. (edited) | 02:41:36 |
| @bridge:decred.org | [slack/decoy] i'll support the direction you take this but believe noting all admin actions publicly would be the best direction. i would also like each action to allow for a response from the contractor to explain the cause or reason for the issue. "my lead dev bought a boat and sailed off in the direction of the Maldives." contractor's will learn no one is being picked on it's just how the system works best in a decentralized context. full transparency. (edited) | 02:41:54 |
| @bridge:decred.org | [slack/decoy] i'll support the direction you take this but believe noting all admin actions publicly would be the best direction. i would also like each action to allow for a response from the contractor to explain the cause or reason for the issue. "my lead dev bought a boat and sailed off in the direction of the Maldives." contractor's will learn no one is being picked on, it's just how the system works best in a decentralized context. full transparency. (edited) | 02:42:15 |
| @bridge:decred.org | [slack/decoy] once pi goes live will the dev fund be a corporate entity? is the fund subject to legal action by aggrieved contractors? (edited) | 02:43:18 |
| @bridge:decred.org | [slack/Richard-Red] https://twitter.com/spencernoon/status/1025109024767975425 | 05:50:27 |
| @bridge:decred.org | [slack/Richard-Red] this guy gets it | 05:50:40 |
| @bridge:decred.org | [slack/Richard-Red] I've been thinking about how github and that kind of approach could be further integrated into governance.
Documents like the Decred Constitution define a set of policies which guide contributors to the project. Looking at Politiea's development, with a view to it taking over as the major decision-making force of the project, there is a already a need for additional documents that clearly define processes (e.g. what is the proposal submission, review and payment process) and principles which are fundamental to how Decred's off-chain governance works.
These documents need to have the backing of stakeholders to be effective, and so it makes sense that they be ratified by ticket-voting. They should also be subject to change, as nobody expects everything to work perfectly immediately.
Proposals that are Pull Requests to change these documents, subject to Politeia Vote for review, would be an easily-automatable mechanism for deciding and describing how the various aspects of Decred's governance works. | 07:00:58 |
| @bridge:decred.org | [slack/Richard-Red] I've been thinking about how github and that kind of approach could be further integrated into governance.
Documents like the Decred Constitution define a set of policies which guide contributors to the project. Looking at Politiea's development, with a view to it taking over as the major decision-making force of the project, there is a already a need for additional documents that clearly define processes (e.g. what is the proposal submission, review and payment process) and principles which are fundamental to how Decred's off-chain governance works.
These documents need to have the backing of stakeholders to be effective, and so it makes sense that they be ratified by ticket-voting. They should also be subject to change, as nobody expects everything to work perfectly immediately.
Proposals that are Pull Requests to change these documents, subject to Politeia Vote for review, would be an easily-automatable mechanism for deciding and describing how the various aspects of Decred's governance works. (edited) | 07:01:31 |
| @bridge:decred.org | [slack/Richard-Red] I set up a repository to play around with the idea: https://github.com/RichardRed0x/governance-docs/blob/master/README.md | 07:02:05 |
| @bridge:decred.org | [slack/jy-p] having a dispute resolution panel is certainly a good way to approach this. it's important that it's not always the same panel, to avoid centralization | 09:52:12 |
| @bridge:decred.org | [slack/jy-p] putting the cost of the panel on the loser might be a bit much, but it has some merit | 09:52:55 |
| @bridge:decred.org | [slack/jy-p] it was suggested to me by a journalist that pi could be used to replace github. perhaps we should keep these documents internal to the proposal system since it's already backed by gh | 09:55:25 |
| @bridge:decred.org | [slack/jy-p] this would cue users to view the content in the proposal system as the reference point versus github | 09:56:08 |
| @bridge:decred.org | [slack/Haon] That makes sense | 09:58:41 |
| @bridge:decred.org | [slack/Haon] Maybe not for code contributions, but for content changes it is useful | 09:59:55 |
| @bridge:decred.org | [slack/bee] > pi could be used to replace github
what features exactly? the issue tracker? | 10:01:19 |
| @bridge:decred.org | [slack/Haon] Version control, data repository and review platform? | 10:02:56 |
| @bridge:decred.org | [slack/bee] Yeah, I mean for what content? The policy/process documents? | 10:03:18 |
| @bridge:decred.org | [slack/jy-p] yes | 10:04:02 |
| @bridge:decred.org | [slack/bee] So instead of making a repository with policy docs, they are instead hosted in Pi and are subjet to Pi approval process | 10:04:04 |
| @bridge:decred.org | [slack/jy-p] replacing github for code is a massive amount of work, so it's definitely out-of-scope | 10:04:25 |
