Ratification Doc 003 - Authority Node Operator Expectations

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 Vikings Crypto Vikings 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 Syncroblock Syncroblock The Factoid Authority The Factoid Authority Tor Paulsen VBIF VBIF
  • Not Viewed None

Should the document be ratified or amended as specified?


Have not voted

Authority Nodes Prestige IT Prestige IT

  • Total voters
    30
  • Poll closed .

Timed Discussion

Discussion ended:

Status
Not open for further replies.
Secured
#62
@PaulSnow -- Based upon what you just wrote above, how about this as a compromise?

https://docs.google.com/document/d/1IylZOUbY5D3_qbRDDOHSFPIKoVav15h8ojTESpQP3Y0/edit?usp=sharing

It's mostly what we already have but formatted in a manner that is close to what you describe above.
Looks much easier to follow and understand. I have made a couple of comments.
Opinions from others on this version? Continue with it or go back to the original?
 
Secured
#64
Please note I DID change a couple "musts" and "shoulds". All Core Requirements became "must" and all "Suggestions" became "should".
The only "should" should be in the introduction where ANO's "should" detail what they are pledging to do, and thus where they will focus efforts outside of running their node(s) and have considered by the community in supporting them as an ANO.
 

Chappie

Timed Discussion Bot
Secured
#66
Paul Bernier has made a motion to extend the discussion. If someone seconds this motion by selecting the button below, a vote on the motion will start.

A majority voting yay will pass the motion and the discussion will be extended for 72 hours. This motion will remain open until the normal discussion period ends or a motion to end the discussion is passed by a majority.
 

Chappie

Timed Discussion Bot
Secured
#67
AdamSLevy has seconded the motion to extend the discussion.

A motion is now active at the top of this thread to vote if you want to extend the discussion. A majority voting yes will pass the motion and the discussion will be extended for 72 hours. This vote will remain open until the normal discussion period ends or another motion is passed.
 
Secured
#68
The only "should" should be in the introduction where ANO's "should" detail what they are pledging to do, and thus where they will focus efforts outside of running their node(s) and have considered by the community in supporting them as an ANO.
Paul, see the discussion here for why we chose that wording. The consensus was to have a set of harder requirements ("musts") and suggested requirements ("shoulds").
 
Secured
#70
Paul, see the discussion here for why we chose that wording. The consensus was to have a set of harder requirements ("musts") and suggested requirements ("shoulds").
Of course, this is my objection. We should have each point described objectively. And many of these points are not necessary for the Core Responsibility of being an ANO. At which point, by your link, I'd claim they should be "May". And I'd have them put their set of expectations in their pledge, and then evaluate them on their pledge. (At that point, the ANO has agreed these points to be "shoulds")

I really don't see why we have to have an emergency removal of anyone that is fulfilling their Core Responsibilities. We should have a system where the regular evaluation (when automated becomes much more frequent) allows them to lose support and fall out of the Authority Set. It should not be part of an early removal process if an ANO doesn't hit all of these "shoulds".
 
Secured
#72
Of course, this is my objection. We should have each point described objectively. And many of these points are not necessary for the Core Responsibility of being an ANO. At which point, by your link, I'd claim they should be "May". And I'd have them put their set of expectations in their pledge, and then evaluate them on their pledge. (At that point, the ANO has agreed these points to be "shoulds")

I really don't see why we have to have an emergency removal of anyone that is fulfilling their Core Responsibilities. We should have a system where the regular evaluation (when automated becomes much more frequent) allows them to lose support and fall out of the Authority Set. It should not be part of an early removal process if an ANO doesn't hit all of these "shoulds".

Let me see if I can get to the crux of the disagreement. In your opinion, if an ANO:

  • Participates in 0% of governance votes
  • Changes their efficiency without informing the community
  • Modifies their pledges without informing the community
  • Never or rarely attends ANO meetings
  • Drops their efficiency to 0% without a commensurate increase in pledges or other value added to the protocol
should they be removed?
 
Secured
#73
Let me see if I can get to the crux of the disagreement. In your opinion, if an ANO:

  • Participates in 0% of governance votes
  • Changes their efficiency without informing the community
  • Modifies their pledges without informing the community
  • Never or rarely attends ANO meetings
  • Drops their efficiency to 0% without a commensurate increase in pledges or other value added to the protocol
should they be removed?
Well that is kinda extreme. I would say that they are on record with their pledges, and if they change their pledges (assuming it specified voting, efficiency, ANO meetings...) then they should lose support and fall from the Authority Set.

Once we have the automation of support, this should be automatic, and happen (I'd guess) fairly frequently. Originally we had considered evaluations every 4 hours, but I think that might be pretty fast.

At this point, Assuming that they are running their node(s), updating their software timely, and responding to any issues on the network, then I think voting them out is not anything of any pressing risk. Perhaps we should have votes more often to manage this reasonably.

The problem I see is that someone that is doing nothing to engage in the process around running a node isn't likely to be running their node reasonably either. If someone isn't running their node reasonably, that someone should be subject to removal.

If someone didn't pledge any efficiency, any participation in governance, any participation in ANO meetings... And we elected them anyway, then how can we complain? Perhaps they are someone like Linus Trovalds, and we get so much out of him running a node, we are glad to have him and the exposure he gives the protocol! If he is covering his Core Responsibility, and meeting his pledge (that he gave to be an ANO), then shout hooray! If not, kick him out. If everyone wants that.
 
Secured
#74
How do they know to pledge things the community cares about though? They don't. They're probably not going to know so they're not going to pledge it and then the community will get upset when they don't do it and they'll either say, "We didn't know we should" or "We didn't pledge it".

Instead, we put expectations the community feels is important in this document and have this document be part of the ANO Application process.
 
Secured
#75
@PaulSnow I think the removal process is objective enough to allow ANOs the flexibility to decide for themselves whether an ANO is of value or should be removed.

I believe a document like this is important for setting expectations for future ANO and current ANOs. This document will also make it easier for ANOs to request the removal of an ANO on grounds of not meeting minimum expectations at which point it is then down to ANOs if they feel a removal is justified.

It doesn't mean there won't be exceptions. If Linus Torvalds does want to become an ANO and everyone votes him in and his pledge is to give exposure and run his nodes but not to get involved otherwise. I firstly doubt anyone would ask for his removal if he was true to his word and secondly even if someone did it would still require a majority of ANOs to remove him.
 
Secured
#76
I've edited the original post to refer to David's edited version of the Expectations document. The content is largely the same as what we workshopped in the original discussion, but it's better organized. I've also added it to the Factom Community Drive replacing the old version. As it stands now, this is the version we will be voting on, with any additional changes we make before the discussion ends.
 
Last edited:
Secured
#77
@Tor Paulsen, remind me the reasoning for moving this to the governance section and making it an 00x doc? @Shuang Leng commented that she thought it shouldn't be part of governance.

@PaulSnow and @David Chapman, Regarding the twilight provision, there's no need to add that. Doc 002 - Administration of governance- and community documents has a process for retiring documents that are no longer needed so we don't need to write in a specific provision for the document itself. This leaves it up to the community about whether we want to eventually retire this document once we have full standing parties set up with an automated standing process.
 
Secured
#78
Paul suggested:


Juggler Extraordinaire of Factom said:
Also, the suggestions should be organized by category, for example:

Community Suggestions
* Read and provide feedback on grants
* Provide analysis and commentary on proposed grants, grants in process, completed grants

Protocol Suggestions
* Provide development support for new features
* Provide testing of new features either on a unit test basis, on one off test networks, or on the testnet

and so forth.
I'll make this change unless there any objections.
 
Secured
#79
Paul and Brian do not like specifying a hard percentage for suggested participation in community votes. Referencing this section


3.1 ANOs should take part in Factom governance in a meaningful way.

3.1.1 ANOs should vote in at least ninety percent (90%) of the votes on the community forum or other voting platform the community adopts.

3.1.2 ANOs should utilize the “ANO Contributions” subforum to post updates on their projects, contributions, or other activities or initiatives in Factom ecosystem at least once a month. These updates may be posted elsewhere and linked to within the forum.

3.1.3 ANOs should timely follow at least ninety percent (90%) of “Minor” or “Major” discussion threads and Document Ratification threads they are invited to even if they don’t participate otherwise.
Paul says:

Juggler Extraordinaire of Factom said:
An ANO should specify what their percentage goal is, not necessarily hold to a number (like 90%)
One of the issues with not making participating in governance an expectation is that if we consistently get below a minimum level of participation we can get stuck unable to make any governance changes due to not meeting our voting thresholds. This gets more likely as we increase the number of ANOs. Implementing full standing parties will change this equation, but that's a ways out and we have to be able to function until then.

My personal opinion is that this expectation should remain, in the Suggestion section so there's less consequence for not meeting it, but I would be ok with reducing to a slightly lower level, e.g. 75% instead of 90%.
 
Last edited:
Secured
#81
Paul and Brian do not like specifying a hard percentage for suggested participation in community votes. Referencing this section

One of the issues with not making participating in governance an expectation is that if we consistently get below a minimum level of participation we can get stuck unable to make any governance changes due to not meeting our voting thresholds. This gets more likely as we increase the number of ANOs. Implementing full standing parties will change this equation, but that's a ways out and we have to be able to function until then.

My personal opinion is that this expectation should remain, in the Suggestion section so there's less consequence for not meeting it, but I would be ok with reducing to a slightly lower level, e.g. 75% instead of 90%.
75% is low. Lowest I think it should be is 80%.
 
Secured
#83
Well that is kinda extreme. I would say that they are on record with their pledges, and if they change their pledges (assuming it specified voting, efficiency, ANO meetings...) then they should lose support and fall from the Authority Set.
There is no way to "lose support and fall from the Authority Set" currently. We need to be able to remove ANOs based on under-performance now, not wait an unknown period of time until we have the full Standing Parties implemented and automated. In order to determine what under-performance is we need a set of expectations.

The problem with using pledges as expectations is they are often highly subjective, vague, and are not standardizable across ANOs. Canonical Ledgers, for example, has already fulfilled most of its pledges. Do we get to skate indefinitely now at 50% efficiency only running our nodes and fulfilling core functions? What about ANOs that said they would reevaluate efficiency after x period of time? Without expectations we are setting up the protocol for the ability to game it and we open the possibility of having non-contributing ANOs who only run their nodes, operate at very low efficiency and don't bring any additional value to the ecosystem.

Once we have the automation of support, this should be automatic, and happen (I'd guess) fairly frequently. Originally we had considered evaluations every 4 hours, but I think that might be pretty fast.
When will we have automated support?
 
Secured
#84
Regarding this:

ANOs should abide by the factomprotocol.org code of conduct when utilizing the website.
Paul says:

Strike. Subjective, and should apply to any website, not just a particular one, even if tied to the factom protocol.

After all, if someone wants to create a FactomCommunity.io sight to gather the community and do stuff to promote the protocol, ANOs should follow their code of conduct too, if they participate.

BTW, I could not find the code of conduct on that website the other day...
Tor agreed in the comments on the doc. Thinking about this, I also agree. As stated it only applies to ANOs using the website anyway so doesn't need to be in this document, IMO. If there are no strong objections I will remove this from the expectations document.
 
Secured
#85
Regarding:

3.7 ANOs should provide relevant information for the “Major Contributors” section on factomprotocol.org and keep it updated.
Paul says:

Part of their campaign. Might also update other sources. Not sure calling it out here makes sense.

Maybe something like "List websites and information you as an ANO will commit to maintaining and keeping up to date. For example (but not limited to) the "Major Contributors" section on factomprotocol.org"
The "Major Contributors" section of factomprotocol.org, and the website itself, did not exist when all current ANOs campaigned so I guess I'm confused about your suggestion means. @PaulSnow
 
Secured
#86
Regarding:

3.8 ANOs should support the efforts of the Factom Marketing Committee/Working Group in promoting marketing launches of Factom protocol announcements and ANO product announcements.
Paul says:

Subjective. Providing measurable goals for marketing or supporting the marketing, promotion, and visibility of the protocol. Include who you might work with, like the Factom Marketing Committee(s), other ANOs, businesses, developers, etc.
The idea here is to encourage ANOs to contribute to marketing efforts such as retweeting, commenting on blog posts, etc. I think providing measurable goals is hard because we don't always know what the marketing committee is going to need. The idea here isn't to "gotcha" ANOs who didn't retweet 4 out of 5 marketing announcements, but to set the expectation that we generally want ANOs to help with marketing as makes sense and as they're able. That's why it's in the "Suggested" section not the "Core Requirements" section.
 
Secured
#87
Regarding this:

Paul says:

Tor agreed in the comments on the doc. Thinking about this, I also agree. As stated it only applies to ANOs using the website anyway so doesn't need to be in this document, IMO. If there are no strong objections I will remove this from the expectations document.
I also agree. It doesn't need to be part of the expectations doc.
 
Secured
#88
Regarding:

Paul says:

The idea here is to encourage ANOs to contribute to marketing efforts such as retweeting, commenting on blog posts, etc. I think providing measurable goals is hard because we don't always know what the marketing committee is going to need. The idea here isn't to "gotcha" ANOs who didn't retweet 4 out of 5 marketing announcements, but to set the expectation that we generally want ANOs to help with marketing as makes sense and as they're able. That's why it's in the "Suggested" section not the "Core Requirements" section.
I do agree that we shouldn't suggest that ANOs participate in other ANOs product announcements. At some point there's going to be competition and there shouldn't be an expectation that you tweet about your competitors products.

The problem with this one the way it is worded is:

1. If the Factom Protocol Marketing Committee plans to attend a conference and wants a huge booth and needs $2500 from every ANO to do it, am I in violation by not contributing?

2. What happens if someone that isn't part of the Factom Protocol Marketing Committee does some form of good marketing. Why should their efforts not be supported?
 
Secured
#89
I do agree that we shouldn't suggest that ANOs participate in other ANOs product announcements. At some point there's going to be competition and there shouldn't be an expectation that you tweet about your competitors products.

The problem with this one the way it is worded is:

1. If the Factom Protocol Marketing Committee plans to attend a conference and wants a huge booth and needs $2500 from every ANO to do it, am I in violation by not contributing?

2. What happens if someone that isn't part of the Factom Protocol Marketing Committee does some form of good marketing. Why should their efforts not be supported?
I don't think "promoting marketing launches" implies a financial commitment. At any rate, if you retweet a few marketing posts, you're "promoting marketing" so are adhering to this suggestion. I could understand the concern if this was a Core Requirement but as one of many suggestions if it really bothers you you could take the minor social hit of not doing any marketing promotion and still be fine if you're in good standing otherwise in the eyes of the community.

With regards to not having to promote a competitor's product, that makes sense so we could leave that out:

ANOs should support the efforts of the Factom Marketing Committee/Working Group in promoting marketing launches of Factom protocol announcements.
 
Status
Not open for further replies.