| 3 Aug 2018 |
 @bridge:decred.org | [slack/jy-p] however, using pi to store project documents is straightforward | 10:04:59 |
| @bridge:decred.org | [slack/bee] That would require either an additional Pi instance for policy docs, or dedicating a special place in the "main" Pi instance | 10:05:02 |
| @bridge:decred.org | [slack/jy-p] nah, just a particular type of proposal | 10:05:16 |
| @bridge:decred.org | [slack/jy-p] proposal is "here is an updated version of a policy document", it gets voted in and becomes the new policy document | 10:05:52 |
| @bridge:decred.org | [slack/bee] so you suggest to reuse the Proposal entity to also host policy docs | 10:06:00 |
| @bridge:decred.org | [slack/bee] a new proposal for every new version of every doc | 10:06:20 |
| @bridge:decred.org | [slack/jy-p] it could also be a single proposal that receives updates over time | 10:06:44 |
| @bridge:decred.org | [slack/jy-p] there is no hardcoded lifecycle for a proposal yet | 10:07:14 |
| @bridge:decred.org | [slack/jy-p] realistically, these docs won't be changing very often | 10:07:30 |
| @bridge:decred.org | [slack/bee] ok I get the idea now. New proposal per version or one proposal with periodic updates is a matter of presentation and UX, underneath it is Git-like: every new version is a new document with different hash. For sane UX of course people will want to see all past version of certain document | 10:09:24 |
| @bridge:decred.org | [slack/jy-p] proposal to create some policy document -> users comment -> proposal updated -> stakeholder vote to ratify -> proposal updated -> stakeholder vote to ratify, etc | 10:09:46 |
| @bridge:decred.org | [slack/bee] One UX element the Documents would require compared to "regular" proposals is the ability to view Documents only | 10:10:55 |
| @bridge:decred.org | [slack/jy-p] yeah, and you could see all the prior versions in that single proposal. we could also break it up into a separate proposal per update | 10:11:02 |
| @bridge:decred.org | [slack/jy-p] i don't see any harm in ppl being able to also see the comments, but we could make a page that aggregates our various policies that only presents the latest version of them | 10:11:52 |
| @bridge:decred.org | [slack/bee] For some current (non too decentralized) examples: https://github.com/collections/policies , especially https://github.com/github/site-policy -- this has a ton of docs | 10:13:20 |
| @bridge:decred.org | [slack/bee] For some current (non too decentralized) examples: https://github.com/collections/policies , especially https://github.com/github/site-policy -- this has a ton of docs (edited) | 10:13:24 |
| @bridge:decred.org | [slack/bee] For some current (non too decentralized) examples: https://github.com/collections/policies , especially https://github.com/github/site-policy -- this has a ton of docs (edited) | 10:13:27 |
| @bridge:decred.org | [slack/jy-p] stuff like policy documents is precisely why we didn't create an exhaustive top-down spec for politeia - we need it to be flexible enough to handle unknown unknowns from a use-case perspective | 10:19:48 |
| @bridge:decred.org | [slack/Richard-Red] handling it on Pi directly sounds good, the edit -> comment -> ratify cycle is really the core of it, easy to express in Github terms but if it's easy to do it directly then yeah, sounds good | 10:29:36 |
| @bridge:decred.org | [slack/jy-p] doing this for code would require quite a bit of work, but markdown docs should be easy | 10:34:15 |
| @bridge:decred.org | [slack/Richard-Red] yeah I imagine it's much trickier for code and you'd lose a lot more from not using Github | 10:35:38 |
| @bridge:decred.org | [slack/Richard-Red] but I'm curious how easy/fast it could be done, because there's a fairly immediate need for some of these documents. The basic description of how Politeia works, and examples of what an acceptable proposal looks like, for example are sensitive to minor changes and needed for a proper launch | 10:37:34 |
| @bridge:decred.org | [slack/Richard-Red] Also, I wrote this up as a distillation of the discussion about contributor "vetting" yesterday. Writing it up raises the question of Who are the established contributors to talk to in a sub-domain? That becomes a kind of status and important to know for new/prospective contributors. https://github.com/RichardRed0x/governance-docs/blob/master/recruitment.md | 10:40:01 |
| @bridge:decred.org | [slack/thedecreddigest] Nice @Richard-Red. One reason I was thinking that disputes should be able to be raised externally to stakeholders in a transparent way is because the group of existing contractors vetting work may be incentivised to prevent the on boarding of a new contractor company if their own on-going work is in short supply. Basically eliminate competition. Not saying this is the case with any current contractors (it isn’t at all), but just thinking what issues might arise at scale in the future. | 11:17:17 |
| @bridge:decred.org | [slack/Richard-Red] This is interesting: https://github.com/aragon/nest/issues/47 | 13:19:21 |
| @bridge:decred.org | [slack/Richard-Red] Looks like Ethereum/Aragon recognizing issues with getting a reliable signal from a community that has no formal means of signalling. The outputs of a successful proposal could well be broadly useful. | 13:22:45 |
| @bridge:decred.org | [slack/jy-p] gee, communicating and signaling is important. good thing nobody is working on this :face_with_rolling_eyes: | 13:28:45 |
| @bridge:decred.org | [slack/Richard-Red] @thedecreddigest Yeah I think there are probably going to be some disputes sooner or later, so good to start thinking about a resolution process, but I find it hard to imagine any of the current contributors I know engaging in that kind of sabotage. The way the project works, ticket-voting is the ultimate decision-making force and it can over-rule any other decision, so it makes sense that Voting is ultimate way to resolve any dispute. Transparency will be required wherever Voting is deployed, or bad information will lead to bad decisions. | 13:29:36 |
| @bridge:decred.org | [slack/Richard-Red] but, for a lot of things, it shouldn't have to come to Voting on it, and too many proposals like that would be a sign that something is wrong. | 13:30:36 |
| @bridge:decred.org | [slack/thedecreddigest] Got lost reading this a bit, but for anyone who wants a read: https://medium.com/amentum/the-crypto-governance-manifesto-7c40df928b04 | 13:46:48 |
