Ratified Doc 001 - Factom Governance Document (1.4)

Public: Only invited members may reply

  • Viewed BI Foundation BI Foundation Bedrock Solutions Bedrock Solutions Blockrock Mining Blockrock Mining Brian Deery BuildingIM BuildingIM Canonical Ledgers Canonical Ledgers Crypto Logic Crypto Logic Cube3 Cube3 DBGrow DBGrow De Facto De Facto Factom Inc. Factom Inc. Factomatic Factomatic Factomize Factomize Factoshi Factoshi Federate This Federate This Go Immutable HashnStore HashnStore Julian Fletcher-Taylor LUCIAP LUCIAP LayerTech Matter of Fact Matter of Fact Multicoin Capital Multicoin Capital Niels Klomp Prestige IT Prestige IT RewardChain RewardChain Samuel Vanderwaal Stamp-IT Stamp-IT The Factoid Authority The Factoid Authority Tor Paulsen VBIF VBIF
  • Not Viewed None

Should the document be ratified or amended as specified by the thread type?


Have not voted

Authority Nodes Federate This Federate This

  • Total voters
    29
  • Poll closed .

Timed Discussion

Discussion ended:

Status
Not open for further replies.
Secured
#1
Hello everyone.

This timed discussion is created to facilitate the amendment of the Factom Governance Document (Doc 001) to apply suggested changes to make it compliant with other ratified governance- and process documents. Some minor other changes are also suggested; mainly items that are made redundant/obsolete by the previously mentioned documents, or due to other changes that has happened since the document was last updated back in June 2018.

All the suggested changes are detailed in this spreadsheet.

The suggested changes have been added to a copy of the Governance document available here.

The new version has been labeled V.1.4. Please note that there are a host of other changes required and identified (the guides have already started working on a 1.5 version), but this time around we are only looking to do the required amendments to remove inconsistencies between our governance documents, as well as fix some minor, most likely uncontroversial issues.

I would prefer if we could keep the discussion in this thread and not as comments/suggestions in the google-document, as we have experienced that it quickly becomes unmanageable when multiple people are editing simultaneously.


The process going forward:
- 8 day discussion phase (extensions possible)
- Guide vote (4/5 required approval)
- ANO vote (3/5 required approval)


--- The Factom Guides


Edit: Added a .PDF version of v.1.4 of Doc 001. This is the document that will be up for the ratification vote by the standing parties.
 

Attachments

Last edited:

Chappie

Timed Discussion Bot
Secured
#2
This thread is a Document Ratification/Amendment Timed Discussion and I am designed to help facilitate efficient communication.

Guides and ANOs may take part in this discussion and vote. Unless this discussion is ended early or extended, it will end in 8 days after which a vote will take place. After 18 hours from the start of the thread or any point up until 24 hours are left in the discussion, you can make a motion to end the discussion immediately or extend the discussion beyond it's initial time frame by selecting the pertinent button at the top of this thread. If someone "seconds" your motion, a poll will take place which requires a majority of Standing Parties to vote one way or the other.

At the end of the discussion period, Guides will vote first and 4 must vote yes otherwise the process ends. If 4 do vote yes, ANOs then vote and if 60% vote yes, the document is successfully ratified or amended.
 
Secured
#4
Document 001 should NOT be modified to conform to the following documents. Instead, those documents define how we are conforming to the requirements of doc 001, or are working around limitations in infrastructure to conform to the spirit of Document 001.

We should have no references to other documents in Document 001, or you create a circular logic stream where the supporting documents depend on Document 001 for some issues, and document 001 depends on the supporting documents for other issues, and where there is a conflict, there is no starting point to resolve said conflict.
 
Secured
#6
Many of these changes to our basic governance completely wipe out any possibility of onchain governance because doc 100 and doc 102 have no detail of how governance should be done on chain.
Suggestion.

Leave Document 001 alone. Add an amendment that updates the sections that really require updating.

Basically treat Document 001 as a constitution for the protocol.
Doc 001, at present, should be a living document that changes to fit the needs of the protocol. I'd suggest we not try to make on-chain governance fit within the existing confines of Doc 001 but use it as a general guide and modify it as needed to fit into the realities of on-chain governance as we develop it.

If we only add amendments to Doc 001, then before too long, the primary document will be completely outdated and you'll need to scroll to the amendments.

I can see a time where we only do amendments like you suggest, but we're not yet there.
 
Secured
#7
Agree. On chain governance is going to be a large and long revamping of our governance system, I dont think anything were doing now will get in the way of that.

Instead, those documents define how we are conforming to the requirements of doc 001
This doesn't work because we aren't, and should not, be entirely conforming to 001 right now because it is woefully outdated and contains sections that do not make sense to follow at this point.

I do agree that eventually 001 should be a document we rarely touch, and that is why we have designed the structure as 001 defines our core governance, all the supplementary documents which 001 gives power to define the details of those governance implementations. We are not at the stage to be leaving 001 alone though, we are at the stage where we are still building it into a document that makes sense to be the core of our governance.
 
Secured
#8
@PaulSnow While I personally, presently agree with David and Julian as to the logic behind directly altering Doc 001 to reflect the progression of the Protocol (rather than the inception of the Protocol), as it IS a living document, could you elaborate as to why you view on-chain governance as a "wiped out possibility" by these Doc 001 changes?
 
Secured
#9
Also, @Guides fantastic job putting together this spreadsheet tracker. I really appreciate being able to see and contemplate all of the changes (as well as the rationale for the changes) in one place and organized by section of Doc 001.
 
Secured
#10
I think better is to make Doc 001 fit the vision, and make the 10x documents fit the current reality. This is how regulations reflect the law, but don't modify the law.

The constitution of Louisiana is an object lesson: The constitution was continually modified to reflect the current legal thought, and it was continually replaced by the next version. When the old constitution in 1974 occupied an entire shelf. Every law and change of law was applied to the constitution, and it made it a royal mess.

I'd suggest we view the governance document as a constitution, and the other documents as the current application of doc 001.

I certainly believe building circular between these sets of documents is a huge mistake.
 
Secured
#11
@PaulSnow Removing some of the existing, old language from Doc 001 will help us to find uniformity of understanding with Doc 001. Right now, there are allusions to old processes or steps in processes, and these sometimes conflict with present implementations. By directly removing some old language, we can avoid the mental conflict of reconciling what we're reading in our constitution with what we think to be a present implementation.

I think that circular references can also be avoided because we are flexible in the build out of our governance system. We aren't married to any exact structure. By opting now, via public discussion and thereafter ratification, to directly amend and remove particular language in 001, we are enhancing our abilities as individuals and as a group to be of like-mind when furthering and progressing governance and the critical processes therein.

To put it simply, I don't want to have to read an outdated section in Doc 001 and then refer to a subsequent amendment to acquire an understanding of (for example) the Grant process. I would much rather have to open Doc 001 when it accurately describes the high-level process, and then if I want granular step-by-step, I can open a supplementary document as referenced in the Grant section of 001.

While I can understand that preserving a timeline of steps or thought (in governance Doc 001) may have benefits (as I infer you view as important), that same timeline is largely preserved via Factomize open and public discussion and ratification. Imo, the benefits of limiting confusion and ambiguity by having to back-and-forth between potentially conflicting information between documents outweighs the argument for preserving most all Doc 001 language in its original form.
 
Secured
#12
Many of these changes to our basic governance completely wipe out any possibility of onchain governance because doc 100 and doc 102 have no detail of how governance should be done on chain.
Can you detail in which way they "completely wipe out any possibility of onchain governance"?

The proposed new text in 2.5 says:
Doc 100: Guide Election and Removal Processes currently governs how Guides are elected, their length of term and describes a removal process for cause. Once the necessary infrastructure is ready, text governing on-chain guide elections and the use of digital guide identities will be added to this document.

Document 001 should NOT be modified to conform to the following documents. Instead, those documents define how we are conforming to the requirements of doc 001, or are working around limitations in infrastructure to conform to the spirit of Document 001.
I do not agree. My stance is similar to David's and Nic's. Our governance document should be seen as a living document, at least for the forseable future. This is mainly because the current status of the governance document is in no way reflecting the ratified processes.

A good example why we need to amend the governance document is the following section from the current version:
Anyone seeking an amendment makes the suggestion in the, “Governance Chat” channel on Discord for public debate.
If an amendment appears to have support, it is written into the Governance Document by any Guide as a potential edit.
If the amendment is to the Guide section, a channel will be setup where the amendment is debated and the vote is tallied. If the motion passes, the change is ratified.
Since that section was created almost a year ago we have changed the procedure for how to ammend governance/community documents, and leaving that in the document only adds ambiguity and uncertainty to the process. The new suggested text ("Amending it shall only be executed in accordance with the process described in Doc 002 - Administration of Governance- and community documents) cannot be misunderstood and references the process to be utilized for this matter.


We should have no references to other documents in Document 001, or you create a circular logic stream where the supporting documents depend on Document 001 for some issues, and document 001 depends on the supporting documents for other issues, and where there is a conflict, there is no starting point to resolve said conflict.
I do not agree. The use of cross-references and nested documents is one of the core principles in use for making and maintaining a functional document structure.

It is vey common to have a high-level document which describes the overarching principles and then references lower-level documents which provides the nitty-gritty details, i.e. what we are in the process of implementing here (we already have actually, we are now just paying our "document update debt").

The suggested structure is quite simple. The governance document provides a high level description of a subject, and then points to a process that governs that specific subject:
----->>> Guide election/removal process document
----->>> ANO removal process document
----->>> Document amendment process

Note that these processes requires full standing party support to be amended, as described in the suggested secton 7.2 of the governance document:
Additional Factom governance and community documents shall be created and administered in accordance with the procedures set forth in Doc 002.
There is nothing "circular" about the above, as you have links to ratified documents that describes the different processes in detail.


The only time you will have issues with the governance document being in contradiction with the processes is when the governance document is "out of date" in regards to newly minted or amended processes. This is currently an issue (right now there are multiple contradictions which we are trying to fix in v.1.4), but that is mainly due to the fact that we have created these processes without simeoultanyously amending the governance document so the processes matches up.

I do believe that we should look into either amending Doc 002, or Doc 001 to state that no additional processes shall be introduced that contradicts what is described in the governance document, i.e to require that the documents are amended/ratified in lockstep.

Suggestion.

Leave Document 001 alone. Add an amendment that updates the sections that really require updating.

Basically treat Document 001 as a constitution for the protocol.
Doc 001 was hastily thrown together over just a few weeks, and to be frank; it is not a good constitution. There are way too much minutia, obsolete elements and even a lot of stuff that does not make sense in an on-chain governance system. As David and Nic pointed out above; having an up-to date document that has been contineously amended as required by the standing parties will ensure that the protocol governance is easy to comprehend by new entities entering the space, as well as providing a functional framework for the standing parties and the community. Having an every growing set of amendments that supercedes the governance document and then each other is cumbersome for everyone involved and makes participating in governance harder and more difficult than necessary.
 

Chappie

Timed Discussion Bot
Secured
#13
We are now 18 hours into the discussion. You may now make a motion to extend this Document Ratification/Amendment Discussion by an additional 72 hours or end this conversation by selecting the pertinent button at the top of this thread. This option will end when there are 24 hours left in the discussion.
 
Secured
#14
We support the approach undertaken by the Guides. Very good points made by others in this thread also. @David Chapman summed things up pretty well, so I'll just copy and paste:

Doc 001, at present, should be a living document that changes to fit the needs of the protocol. I'd suggest we not try to make on-chain governance fit within the existing confines of Doc 001 but use it as a general guide and modify it as needed to fit into the realities of on-chain governance as we develop it.

If we only add amendments to Doc 001, then before too long, the primary document will be completely outdated and you'll need to scroll to the amendments.

I can see a time where we only do amendments like you suggest, but we're not yet there.
 
Secured
#15
While I don’t disagree with the idea of a single constitutional document and that there is a myriad of benefits of having one, Doc 001, in its current form, is rather ill suited to be treated and perceived as such.

However, if we chose the single document model, I do think that modifications should be quite rare and only dealing with generic issues, in order to push Doc 001 closer in the direction of a complete, all-encompassing foundational document. For example, in the US Constitution – “nor shall any person be subject for the same offence to be twice put in jeopardy of life or limb” is a very generic statement which has subsequently taken form through over 200 years of statutes and court precedent. In that sense, if we want to stick to the reliability and benefits of a single constitutional document, then I disagree with the propsed addition that Doc 001 “is a living document that will need to be amended on a regular basis.”

The alternative is to spread governance through multiple equally paramount documents and not have a single reference point. Something like the Brits, who don’t have a single written constitutional document, but instead, are governed by a set of different written statutes, common law, parliamentary actions and god knows what else. I mean the sun never set on the British Empire, and it never sets on the Factom ecosystem as well, so that’s that for what it’s worth :D Plus, they both gave us Ben Jeater who is a don.

In all seriousness, I would be very cautious in case we move on with the multi-document ‘constitution’ route, because then we get into the cross-reference problem that Paul is describing, and it can get exponentially messier really quickly.

Whatever route we chose, in my opinion, we should avoid referencing documents by a specific name and number.
 
Secured
#17
Hi, It seems to me that we have two choices. We either let the governance evolve as a series of interconnected documents or we ensure a single set of principles on which to base the governance (a constitution). Whichever way we go we need to ensure that these documents reflect the reality of "today's" situation; this could be interpreted as living documents.
It seems easier to me to have some high level principles on which we can all agree and that are sufficiently wise and robust that they do not need regular revision. In this way the progressively more detailed governance documents can be a cascade from a single constitutional document. If Doc001 does not do this then shouldn't we work hard at ensuring it does?
 
Secured
#18
It seems easier to me to have some high level principles on which we can all agree and that are sufficiently wise and robust that they do not need regular revision. In this way the progressively more detailed governance documents can be a cascade from a single constitutional document. If Doc001 does not do this then shouldn't we work hard at ensuring it does?
This is my (and some other's vision). We'd like the governance document to be a high level document providing a high-level framework for every sub-topic, and then have it link to process documents like this
Guide election/removal process document
ANO removal process document
Document amendment process

to provide the details and minutia.

As the process documents require the same kind of support as the governance document itself to be amended, we can be sure that they are not inadvertently changed or subverted, and these processes can be invoked when certain events are to happen instead of trying to create an ad-hoc solution based on the "constitution with amendments" that has to be socially governed and the constitution/amendments interpreted.

My long term goal is to have the governance document and the processes moved to GitHub, and have amendments to the documents done via Pull requests that gets approved/turned down via the future on-chain voting system.
 
Last edited:
Secured
#19
Doc 001 was hastily thrown together over just a few weeks, and to be frank; it is not a good constitution. There are way too much minutia, obsolete elements and even a lot of stuff that does not make sense in an on-chain governance system. As David and Nic pointed out above; having an up-to date document that has been contineously amended as required by the standing parties will ensure that the protocol governance is easy to comprehend by new entities entering the space, as well as providing a functional framework for the standing parties and the community. Having an every growing set of amendments that supercedes the governance document and then each other is cumbersome for everyone involved and makes participating in governance harder and more difficult than necessary.
What we are trending towards is governance with all sorts of procedures, deadlines, processes, approvals, and other real world stuff that isn't going to map onto on-chain governance and standing parties. I do agree that doc 001 needs to be simplified to general principles, and you quote a few examples were we stuffed details into doc 001.

I am seeing resistance to simplification and resistance to looking towards on-chain governance. In principle I think a nest of growing interconnected documents is going to make the governance of the protocol more difficult.

I'd like to update 001 to be more general, inspirational, and vision oriented. In contract, We have generated a set of documents (the 10x series) that lays out what we are doing today.

I like that separation rather than confusing the needs. We really do need one document to point to for inspiration and for those new to the protocol. And at this point we need other documents that say what we are doing. I'd like to see how we transition from the 10x docs to online governance within the context of a more general view.
 
Secured
#21
BTW, checkout the constitution for the state of Louisiana. Replaced through the years nine times, the last replacement was in 1974. At that point, a shelf of a document was replaced by something like 120 pages.

The "living document" frequently updated, and referencing numerous supporting documents (making them sections of the main document) is pretty much the path to that sort of future. Of continues expansion until expansion collapses on itself, to repeat the process again and again.

(To the credit of Lousisina, and they don't get or deserve much, they have refrained from entangling it in day to day law since 1974, so perhaps this version will last a bit longer.)
 
Secured
#22
@PaulSnow I'd certainly be in support of a refactor.

Right now, we need to fix the doc 1.3 bugs for a 1.4 release and we can plan for that future 2.0 refactor.
The up or down on these changes (entangling doc 001 with the other documents) is a real problem for me. I see the need for some changes, but this is a pretty big lump of good and bad (in my opinion) to take as an up or down quickly.

I'd also like to start integrating stuff we know towards decision making going forward. We can manually allow ANOs to vote their efficiency, for example.
 
Secured
#23
Can you clarify what the exact issue you see with this system is?

The system is as follows:

-001 Provides the "vision" and overview for governance.
-Supplementary documents describe the details of processes.
-001 Points to those documents to ensure that they are discoverable and to give them official credence.

So do you think that we should just make 001 grow super long by putting all of these processes in 001?

Or that we should have process docs, but 001 just shouldnt point to them?

Or that we shouldnt have process documents at all?
 
Secured
#24
As I see it, the current consensus is to carry on as originally outlined in this thread and as such, we should do so unless that consensus changes. Suggestions:

1. Now would be a good time to update the "Federation" logo to the current logo.

2. Standing Party Definition - Page 7
A party that has standing in the protocol to support a given outcome in any process. These processes include selection of guides, authority set members, and/or grant proposals.
To
A party that has standing in the protocol to support a given outcome [REMOVE EXTRA SPACE HERE] in any process. These processes include but are not limited to selection of guides, authority set members, and/or grant proposals.
3. Introduction 1.1
The following documents the governance model for the Authority Servers and the protocol.
to
The following documents the governance model for the Authority Set and the protocol.
4. 1.2 - 1.4
1.2 The network will be initially governed by a set of Guides entrusted with promoting the best interests of the protocol and the community depending on the continued orderly operation of the protocol.

1.3 The long term plan is to automate many of the objective components, the weighting driving decision making, and other aspects of protocol governance. As an interim step, the Guides will provide governance, allowing a period of experimentation where policies can be swiftly adjusted to meet the needs presented by running the protocol in a real world setting. As governance is fundamentally a human process, it is likely that not all aspects can be fully automated.

1.4 The Authority Set, Guides, Developers, and Community will work to develop and refine workable processes. Once agreed upon, these processes will be implemented into the protocol.
There is substantial redundancy and deprecated info here. I suggest:

1.2 The network is governed by the Standing Parties. The long term plan is to automate many of the objective components, the weighting driving decision making, and other aspects of protocol governance. As governance is fundamentally a human process, it is likely that not all aspects can be fully automated. The Standing Parties will work to develop and refine workable processes. Once agreed upon, these processes will be implemented into the protocol.
 
Last edited:
Secured
#25
Section 2
1.

Guides are a group of entities charged with maintaining orderly operation of the protocol. Guides are selected by the Standing Parties, and work with the community to promote and maintain the protocol.
to
Guides are a group of entities selected by the other Standing Parties who are charged with maintaining orderly operation of the protocol.
Remove:
The Guides will provide flexibility and the ability to respond quickly during the startup of the autonomous network. Governance approaches will be tried using the Guides prior to deployment of new features, versions, and updates of code to the protocol. The governance rules in this document and administered by the Guides will be built into the protocol as the processes are proven to be workable through the real world running of the network.
2.
Section 2.1.3 and section 2.1.4 are now redundant with the changes to 2.1.4. Remove 2.1.3.

3.
2.6.2 is redundant with 2.6.1. Remove 2.6.2.
 
Secured
#26
Section 3.

1. In my opinion, you can remove the entire intro there, not just the signing part.

2. 3.2.2 - Remove - deprecated

3. 3.2.4 - Remove - deprecated

4. 3.3.5.2 -
Plans for hot backup servers and guard node networks.
to
Plans for hot backup / brainswap servers.
5. 3.5
Independence must be enforced socially through campaigns. We can’t measure independence on the blockchain.
to
Independence must be enforced socially through campaigns as you can't measure independence on the blockchain.
6. 3.6.1
Initially, the protocol will have limited standing parties to manage the protocol. As such, the initial authorities will be evaluated by their support, and approved by the guides. As authority servers come online, they will provide additional support to back subsequent appointments.
to
Initially, the protocol will have limited standing parties to manage the protocol. As authority servers come online, they will provide additional support to back subsequent appointments.
 
Secured
#27
Section 4.

1.

4.1.2
Grants are required to advance the protocol, through building infrastructure, promotion, development, education. Grants must go for either having done work for the protocol, or to support future work on the protocol.
to
Grants help advance the protocol through building infrastructure, promotion, development, education. Grants must go for either having done work for the protocol, or to support future work on the protocol.
2.
4.1.5 paragraph 2:
For complex efforts, grant awards will be issued on completion of milestones specified in the grant proposal. When a grant has multiple payments, 2x or more of the tokens should be set aside to manage currency risk (falling or rising FCT values) that might cause under paying or over paying the grant.
to
For complex efforts, grant awards may be issued on completion of milestones specified in the grant proposal.
3.
4.1.6 - Remove

4.
4.4
Initial Grants
to
Recurring Grants
5.
4.4
The protocol needs to support a number of activities immediately as part of the grant funds. This section provides some suggested projects that would potentially make up the first three quarters of funding and be hard coded into the protocol.
to
The protocol needs to support a number of activities on a recurring basis via grant funds. These include:
6.
4.4.1 -
Guides will be compensated via the grant pool. Guide remuneration started the 8th of June 2018 and is reviewed every three months thereafter by the Standing Parties
7.
4.4.3 - Remove - I don't feel this needs to be defined as a recurring grant anymore.

8.
4.4.4 - Remove

9.
4.5 - Remove (it is now covered by 4.4.1 above)
 
Secured
#28
JUST FYI @David Chapman, we are just intending to do smaller changes in 1.4 and have already starting identifying more comprehensive changes for 1.5 as stated in my first post:

The new version has been labeled V.1.4. Please note that there are a host of other changes required and identified (the guides have already started working on a 1.5 version), but this time around we are only looking to do the required amendments to remove inconsistencies between our governance documents, as well as fix some minor, most likely uncontroversial issues.
The reason for this is that we have a lot of other ongoing changes in the community right now and we are trying to be cognizant about bandwidth. In addition we would like the legal working group to have more time to look at those changes.

Can I suggest that I input your suggested changes in our 1.5 tracking document for now, and we seek to find common ground regarding the changes suggested for 1.4 this time around?
 
Secured
#29
The reason for this is that we have a lot of other ongoing changes in the community right now and we are trying to be cognizant about bandwidth. In addition we would like the legal working group to have more time to look at those changes.

Can I suggest that I input your suggested changes in our 1.5 tracking document for now, and we seek to find common ground regarding the changes suggested for 1.4 this time around?
I'd like these changes to be considered for 1.4. Most are not controversial. I'm fine with those that are controversial waiting for 1.5.

There will always be a lack of bandwidth. Let's fix glaring issues now.

Thank you.
 
Last edited:
Secured
#30
I'd like these changes to be considered for 1.4. Most are not controversial. I'm fine with those that are controversial waiting for 1.5.

There will always be a lack of bandwidth. Let's fix glaring issues now.

Thanks you.
I appreciate you taking the time to write these up David. Let me discuss it with the other @Guides.

I agree if there are very simple, noncontroversial changes these could go in 1.4, but I'd prefer to push back any items that might require back and forth and discussions for consensus to go into 1.5.
 
Status
Not open for further replies.