Ratified Doc 003 - Authority Node Operator Expectations

Public: Only invited members may reply

  • Viewed Bedrock Solutions Bedrock Solutions Blockchain Innovation Foundation Blockchain Innovation Foundation Blockrock Mining Blockrock Mining Brian Deery BuildingIM BuildingIM Canonical Ledgers Canonical Ledgers CryptoLogic CryptoLogic 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 LayerTech LayerTech Luciap Luciap Matters Matters Multicoin Capital Multicoin Capital Niels Klomp PrestigeIT PrestigeIT Quintilian RewardChain RewardChain Samuel Vanderwaal Stamp-IT Stamp-IT Syncroblock Syncroblock The Factoid Authority The Factoid Authority VBIF VBIF
  • Not Viewed None

Should the document be ratified or amended as specified?


Have not voted

Authority Nodes PrestigeIT PrestigeIT

  • Total voters
    30
  • Poll closed .

Timed Discussion

Discussion ended:

Status
Not open for further replies.
Added a number of comments to the document in google docs. Some of the big ones:
  • Many of the measures (like 90% voting record) are too easily gamed without actually providing value.
  • As the protocol grows, the expectation that every ANO will be deep into every issue and meeting may not be realistic. We should have some amount of delegation to ensure the work gets done, but doesn't become a procedural burdon on people trying to do work.
  • This document should have a twilight provision that drops the document once we have full Standing Parties
 
Added a number of comments to the document in google docs. Some of the big ones:
  • Many of the measures (like 90% voting record) are too easily gamed without actually providing value.
  • As the protocol grows, the expectation that every ANO will be deep into every issue and meeting may not be realistic. We should have some amount of delegation to ensure the work gets done, but doesn't become a procedural burdon on people trying to do work.
  • This document should have a twilight provision that drops the document once we have full Standing Parties
1. How do you game the 90% other than voting without paying much attention?

2. We're already delegating work. The committees and working groups showcase as much. We don't expect every ANO to delve deep into every issue. We SHOULD expect every ANO to delve into extremely important tasks like reading grants and votes.

3. What changes once we have all Standing Parties other than we'll need to amend the process?
 
Added a number of comments to the document in google docs. Some of the big ones:
  • Many of the measures (like 90% voting record) are too easily gamed without actually providing value.
The idea behind having general statements such as "ANOs must participate meaningfully in the governance" and specific statements such as "ANOs should vote in at least ninety percent (90%) of the votes on the community forum" is that we wanted to leave the hard requirements ("musts")somewhat subjective whilst still providing specific recommendations ("shoulds") for behavior. This was my attempt at synthesizing the different opinions and view points from the first round discussion regarding this document.

We want to encourage ANO participation in governance without mandating a hard list of requirements that ANOs can get removed for violating once or twice. If you vote 88% of the time it's not automatically grounds for removal, but if you're consistently not participating in governance in a meaningful manner than the argument can be made that you should be removed.

  • As the protocol grows, the expectation that every ANO will be deep into every issue and meeting may not be realistic. We should have some amount of delegation to ensure the work gets done, but doesn't become a procedural burdon on people trying to do work.
I strongly agree with this. I'd like to see Committees/working groups take larger roles to take some burden off of general governance participation but we still need people engaged and participating in meaningful ways for important governance items.

  • This document should have a twilight provision that drops the document once we have full Standing Parties
This makes sense to me.
 
Can you help me understand why this document should be retired once we have full standing parties? What changes?

The primary purpose of this document, in my opinion, is to supplement the ANO removal document and provide some social guidance until we have a more automated ANO system, e.g. what's described in the Governance Document (001) or your tiered ANO system. Maybe it still makes sense to have an expectations document after that point, though, I guess I don't have a strong opinion on that as it will likely depend on the exact details of how we implement the new system.
 
Last edited:
We will always need an expectations document. We're already getting people saying, "We don't know what the expectations are". As new ANOs are brought on with the current or a tier system, they need to know what is expected of them.
 
We will always need an expectations document. We're already getting people saying, "We don't know what the expectations are". As new ANOs are brought on with the current or a tier system, they need to know what is expected of them.
Expectations are a funny thing. It is like a company, where my expectations for the CFO are not the same for the CMO or a developer, or a project manager.

I do view the protocol as having many facets, I am worried that we are creating "A Mold" in which each ANO must fit.

I like subjective, and I like options for contributions, but am a little weary of requirements that I cannot personally meet. I have to have quite a lot of people to come close to meeting all the requirements my company has already. I always envisioned ANOs as working on different things, and having a range of topics of focus across ANOs, and being graded on their (distributed) value.
 
Expectations are a funny thing. It is like a company, where my expectations for the CFO are not the same for the CMO or a developer, or a project manager.

I do view the protocol as having many facets, I am worried that we are creating "A Mold" in which each ANO must fit.

I like subjective, and I like options for contributions, but am a little weary of requirements that I cannot personally meet. I have to have quite a lot of people to come close to meeting all the requirements my company has already. I always envisioned ANOs as working on different things, and having a range of topics of focus across ANOs, and being graded on their (distributed) value.
We're not all CFOs or CMOs or developers. We're ALL ANOs. And while we may each have different focuses, there needs to be expectations set forth. We're not saying every ANO should do development. We're not saying every every ANO should do marketing. We're not saying the ANOs should do marketing, they should provide updates to the community, they should respond to issues with the network within certain time frames, they should take part in the grant process, they should maintain updated emergency contact info. We're setting forth the basic, fundamental values we feel are important for an efficient, functional governance and stable network.
 
Can you help me understand why this document should be retired once we have full standing parties? What changes?
I believe in an environment where ANOs are constantly campaigning for support, they can find the sweet spot for delivering value and maintaining the support they need to remain an ANO. And a new comer can find that gap in the armor of the existing ANOs where they can make a compelling case for change, and replace the less active ANOs.

We can make a case for voting records (do they vote?) and for being informed (have they read the grant proposals?). But I don't want to kick out the ANO that is rainmaking projects into the protocol and the dev ANO that is building new and exciting infrastructure. Just because they were too busy to read grants unrelated to their interests, or worse. Just uninformed voting to get a "tick" to keep themselves in place.
 
Except we're not all CFOs or CMOs or developers, we're ALL ANOs. And while we may each have different focuses, there needs to be expectations set forth. We're not saying every ANO should do development. We're not saying the ANOs should vote, they should provide updates, they should respond to issues with the network within certain time frames.
Actually it does say every ANO should vote.
 
I believe in an environment where ANOs are constantly campaigning for support, they can find the sweet spot for delivering value and maintaining the support they need to remain an ANO. And a new comer can find that gap in the armor of the existing ANOs where they can make a compelling case for change, and replace the less active ANOs.

We can make a case for voting records (do they vote?) and for being informed (have they read the grant proposals?). But I don't want to kick out the ANO that is rainmaking projects into the protocol and the dev ANO that is building new and exciting infrastructure. Just because they were too busy to read grants unrelated to their interests, or worse. Just uninformed voting to get a "tick" to keep themselves in place.
I agree ANOs will find their sweet spots. This isn't about sweet spots. This is about expectations the community wants to set forth.

As people said earlier in the thread, these are expectations where we use "should" a lot and only "shall" on occasion. My guess is nobody is going to boot an ANO who is kicking all sorts of ass in other areas if they don't take part in some process they "should" have.
Yes, they SHOULD take part in these areas and as we get bigger hopefully each team will be able to afford someone dedicated to these processes and the community, but there is a lot of leeway built into this document.

These are the values the community feels ANOs should uphold. In the end, if the community DOES want to boot an ANO because they're too arrogant to provide updates despite being asked over and over again not to, then that is their right.
 
Please see my edited version. I was distracted when I wrote that.
The core requirement is to run a node, and respond to any issues in the network.

One might argue that they additionally need to be plugged into network policy, software updates, protocol development (at least at a high level). But the point is to do what is necessary to support of the core requirement.

Should ANOs attend the yearly retreat? Honestly I question that, and more fundamentally I question why it is an "ANO" yearly retreat? Why isn't it a convention? Why are we drawing lines between Guides/ANOs and the rest of the community? There was a need this year for an ANO retreat, but there was also a real need for a Factom Summit. Because a protocol is a broad tent and we increasingly have to blur the line between ANOs and the community. The Summit produced public content and a platform to talk not only to the community but to the world. The ANO retreat was inward facing, with little public ramifications.

We need both, but the community is the real focus.

Should ANOs vote on every grant? I am struggling to see why. If grants are out there, far unrelated to the Core Responsibility of running a node, I don't see why every node operator has to be involved. If the grant pool grew to $10 million per month (maybe around $136 FCT), that could be a huge number grants (say $50k per grant avg, that's 60 approved grants! Assuming half make the cut, that could be 120 grant applications to judge and weight every 3 months!). That's huge required overhead for about 75k per month, especially if those funds are being used by an ANO to maintain a complex server set up, fund support engineers, and perhaps seed a business.

This is why we want to delegate responsibilities. Beyond the core requirement, everything else should be part of their campaign to remain an ANO. Perhaps they should demonstrate responsible delegation? Or demonstrate Marketing value? Or infrastructure value? I think the community should relied upon to set the standards that make sense.
 
Last edited:
Paul, just in case, let me first say my tone is not in any way confrontational, negative, angry, etc. I'm enjoying this debate :)

The core requirement is to run a node, and respond to any issues in the network.
Agreed and some of these expectations surround the core requirement. And we're defining other expectations as well. If the ANOs don't want these expectations, then the ratification vote will showcase as much. If they do, the vote will showcase as much and that's how a functional decentralized system should work.

One might argue that they additionally need to be plugged into network policy, software updates, protocol development (at least at a high level). But the point is to do what is necessary to support of the core requirement.
If you feel any of that should be added as an expectation, you're welcome to make that argument.

Should ANOs attend the yearly retreat? Honestly I question that, and more fundamentally I question why it is an "ANO" yearly retreat? Why isn't it a convention? Why are we drawing lines between Guides/ANOs and the rest of the community? There was a need this year for an ANO retreat, but there was also a real need for a Factom Summit. Because a protocol is a broad tent and we increasingly have to blur the line between ANOs and the community. The Summit produced public content and a platform to talk not only to the community but to the world. The ANO retreat was inward facing, with little public ramifications.
Should they? In my opinion, they should try. MUST they? No. The ANO retreat was extremely valuable and I'd love to hold one at least once a year. As the Factom Protocol grows and more Standing Parties have a seat at the table, then any formal governance discussions like we had at the Retreat should be much more inclusive as part of a broader convention like you suggest. But even when there's the broader convention, creating an ANO Only aspect will have value. If other ANOs disagree then we won't hold a retreat portion and that's ok. But yes, I agree with what you're saying here and as Standing Parties come on board we'll want to be inclusive of them.

Should ANOs vote on every grant? I am struggling to see why. If grants are out there, far unrelated to the Core Responsibility of running a node, I don't see why every node operator has to be involved. If the grant pool grew to $10 million per month (maybe around $136 FCT), that could be a huge number. That's huge required overhead for about 75k per month, especially if those funds are funding a few developers and a complex server set up.
Yes, they should vote on every grant but as we've discussed elsewhere, there should be an option to "Abstain" as a vote. They should read the grant and if they realize they either have no interest or don't have the knowledge necessary and aren't swayed by the discussion surrounding it, then it will be perfectly reasonable for them to abstain. But it's critical they actually make an effort.

This is why we want to delegate responsibilities. Beyond the core requirement, everything else should be part of their campaign to remain an ANO. Perhaps they should demonstrate responsible delegation? Or demonstrate Marketing value? Or infrastructure value? I think the community should relied upon to set the standards that make sense.
I'm all for delegating responsibilities. There's a reason I'm not on the Core and Technical Committee. I have no business being on there and I delegate those responsibilities to those who do. There is no expectation that everyone should be on the Core and Technical Committee or Marketing or Legal for a reason. Those aren't fundamental values the community feels should be expected of an ANO. And in many casing, "Voting" is how you responsibly delegate power to others which we both agree ANOs should demonstrate.
 
And we're defining other expectations as well.
In software, we call this pre-optimization. The term refers to fixing performance issues before you actually know you have a performance issue.

I see no reason for us to set expectations beyond the Core Responsibility of an ANO at this point.

Further, I see many of these "expectations" as trying either to 1) ban apathy, or 2) force the spending of funds on "nobel" activities.

You cannot ban apathy. So I am against 1) If a task isn't important to an ANO, then their contribution when forced will not have the value desired.

And ANOs should make a profit!!! So I am against 2). I don't feel any one group (ANOs, Guides) should force particular ANOs to spend their resources outside their Core Responsibility as an ANO.

If an ANO makes a pledge, then so be it. That's their choice, and I'd bet they will continue pledging above and beyond the Core Responsibility of an ANO. Because they have to campaign.

Say we go up to $1000, and now ANOs are making $500k per month! Great! We are going to get real competition for ANO slots, we have funds for Tiered ramps into the ANO set, and the ANOs now have a real motivation to campaign to be ANOs, and they will show up at ANO retreats, and Factom summits! They will want the stage in front of a community!

And you see the need for a ramp into the ANO set, and I see the need for a ramp into the governance process. I am not sure where the assumption that one needs to be a Standing Party at this point to have contributions of value to the governance process and discussions. And I value ANOs that want to just go heads down and work on their own priorities.

Let the community set the expectations. When the price is high, the expectations will be high. When the price is low, then expectations will be lower. Naturally. And without writing out expectations that might not fly with everyone. And can't be enforced by the document anyway.

Instead, set the expectation that the community will have expectations, that ANOs will make pledges, and that the standing parties will enforce expectations and pledges... by supporting ANOs that meet expectations and their pledges, and demoting from the ANOs that do not meet those expectations, and their pledges.
 
Last edited:
I see no reason for us to set expectations beyond the Core Responsibility of an ANO at this point.
Except we've already had one ANO who has complained that they didn't know what the expectations were and used that as the reason for not taking part. A large part of this process is due to the community setting expectations. There was serious upset that some did not take part in the grant process for example. I'm not speaking that just ANOs were upset, there were a lot of people upset in the community. And feedback we received from an ANO was, "We didn't know what was expected". And the community being upset is fair but the ANO not knowing what was expected was fair as well. How could they? They're new and can't follow every word of the community. They need simple to follow expectations.

These aren't noble activities. They're almost all important expectations for sound operation of the network and governance. And the more ANOs who come on and the busier we get, the more important it will be to be able to hand them a document and say, "If you want to be an ANO here's what's generally expected of you."
 
Last edited:
Except we've already had one ANO who has complained that they didn't know what the expectations were and used that as the reason for not taking part. A large part of this process is due to the community setting expectations. There was serious upset that some did not take part in the grant process for example. I'm not speaking that just ANOs were upset, there were a lot of people upset in the community. And feedback we received from an ANO was, "We didn't know what was expected". And the community being upset is fair but the ANO not knowing what was expected was fair as well. How could they? They're new and can't follow every word of the community. They need simple to follow expectations.

These aren't noble activities. They're almost all important expectations for sound operation of the network and governance. And the more ANOs who come on and the busier we get, the more important it will be to be able to hand them a document and say, "If you want to be an ANO here's what's generally expected of you."
Are we saying that a brand new protocol needs some shaking out? Or that there are serious and unsurmountable flaws here? I really don't see even in your issues here anything that requires a formal set of expectations.

I like ANOs being involved. But I hope they compete to be involved, rather than just follow some checklist. And I'd like expectations to evolve, not create a concrete set of what is required and (by implication) what isn't.

[Edit]
Please note... If an ANO isn't performing to their Core Responsibility (maintaining a node, updating timely as releases are issued, and responding to network issues as needed) then they need to be removed. If we just don't think they are doing all this other stuff, then are we certain we can't bring them around? If we can't, should we not just vote them out? Perhaps add a thinning step to each election round?

Ultimately support should be adding ANOs and removing ANOs just as a matter of course.

I really feel that competition for the opportunity should be the driver of involvement rather than a checklist.
 
Last edited:
We're very close to the deadline for this ratification vote. The issues being raised now are addressing fundamental issues rather than finer details. I don't think we have time to properly address these concerns.

Having said that, I'd be keen to know if you can suggest some concrete actions, @PaulSnow? Also, I am interested to know whether Inc will be voting in favour of this expectations document as it currently stands?

Edit: Am i right that we can extend the discussion indefinitely, @David Chapman?
 
Are we saying that a brand new protocol needs some shaking out? Or that there are serious and unsurmountable flaws here? I really don't see even in your issues here anything that requires a formal set of expectations.

I like ANOs being involved. But I hope they compete to be involved, rather than just follow some checklist. And I'd like expectations to evolve, not create a concrete set of what is required and (by implication) what isn't.
I agree 100% that expectations should evolve. All of these processes including our primary governance document should be evolving documents.

There are no serious or insurmountable flaws here. I am of the opinion that things are starting to come together quite nicely and these processes will make everything that much more efficient and transparent.
 

Chappie

Factomize Bot
PaulSnow 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.
 
I'll make a motion to extend (did make such a motion :) )

We had a discussion about this at the ANO retreat, and (for me) it didn't seem clear why we needed a formal ANO removal process beyond just voting bad ANOs out.

And this document does not address what we should do should an ANO intentionally or unintentionally break the network and require removal to maintain the network (a more needed clarification). << Wrong thread! Sorry!
 

Chappie

Factomize Bot
Matt Osborne 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.
 
What are the core principles? I believe a rock solid set of requirements which are pretty darn simple:
  • Core Responsibilities: Run your node, maintain your node, and timely support network maintenance if needed.
  • Deliver on your Pledge
How do we evaluate ANOs? Well that is rock solid as well:
  • Have they committed to performance in their pledge that meets your expectations?
So the document should be clear:

We should thus document the Core Responsibilities:
  1. What we have found is required to run Authority nodes
  2. What we have found is required to update nodes to current releases.
  3. What we have found is required to do to to maintain the network.
  4. What we have found is required to stay current on requirements for 1, 2 & 3 as the protocol evolves.
We can provide a list of suggestions for Pledges, drawn from what ANOs have done, what the community would like to see, and the creativity of the applicant. Could include (not limited to):
  • Be active in the community discussions
  • Provide expertise in various grant categories
  • Provide marketing of the protocol
  • Develop applications that drive protocol usage
  • Develop open source infrastructure
  • Support protocol developers
  • Participate in governance
  • Organize and participate in grant process
  • Apply for grants to promote/support/extend the protocol
  • Whatever...
And warn any potential ANOs not to bite off too much. No ANO can do everything.
 
Status
Not open for further replies.
Top