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.
All the suggestions should be just that, unless part of a Candidate ANO's pledge under which they became an ANO.

Then they should be graded on their performance under their pledge. Of course, I really don't like the idea that we have suggestions that are very subjective because in fact, yes, they can be used against a perfectly fine ANO.

I'd like to push back on the idea that, on the long term, that we are dependent on ANOs to be involved in everything. We need to develop standing that is more broad, that allows more parties to be involved. And first and foremost, ANOs need to do their job of running nodes, and building the actual infrastructure that runs the protocol (as we have to support more and more load).

I'd like it to get to the point that the task of running the infrastructure is enough to keep ANOs busy and yet they are also well funded to make the position competitive, and enables other activities.

We have to avoid the temptation to demand that every FCT an ANO gets must be spent for the protocol. Nobody is going to want that job.
 
We have to avoid the temptation to demand that every FCT an ANO gets must be spent for the protocol. Nobody is going to want that job.
No one has ever pushed for this. I truly have no clue how this conclusion can be reached.

I'd like to push back on the idea that, on the long term, that we are dependent on ANOs to be involved in everything. We need to develop standing that is more broad, that allows more parties to be involved. And first and foremost, ANOs need to do their job of running nodes, and building the actual infrastructure that runs the protocol (as we have to support more and more load).

I'd like it to get to the point that the task of running the infrastructure is enough to keep ANOs busy and yet they are also well funded to make the position competitive, and enables other activities.
I am pretty sure it's a good thing we have 20+ businesses building on the protocol, marketing it, and finding end-users. Why would you want to ever want to stifle that?
 
I am siding with Paul here regarding the long term vision of an ANO.

My take (again, long term being a key word) is that the ANOs are supposed to operate the infrastructure and not be expected to "build on it, market it and finding end-users". It is in fact kind of against our vision of having different types of standing parties where ANOs are just one (I'm not against an ANO doing it all either - but it shouldn't be officially expected and can be handled through pledges as @PaulSnow suggests).
 
No one has ever pushed for this. I truly have no clue how this conclusion can be reached.



I am pretty sure it's a good thing we have 20+ businesses building on the protocol, marketing it, and finding end-users. Why would you want to ever want to stifle that?
As @Tor Paulsen said, and I'll restate, it isn't about stifling involvement in all these activities. I take the position that we can't require involvement in all these things.

Candidates should have the opportunity to sign up for their involvement in what they are interested in doing. That's enough.
 
We aren’t requiring them. We are saying they SHOULD. They will be given this document as part of the signup process and asked to state which they pledge to. If they don’t want to do something they don’t have to and if we elect them anyway then we shouldn’t expect them to. Their pledges will be in the contributions forum for all to see. But if they don’t know about these suggestions how are they going to know what the community values and what they should decide what to put energy towards or not?
 
Last edited:
So; is this something we could agree on:

- We formulate the expectations doc in a way that states that the "shoulds" of the document is a list they ought to pick from when creating their pledges?

if so; do we need the current ANO-set to sift through the list and update their ANO-contributions thread with the "shoulds" they will adhere to?
 
So; is this something we could agree on:

- We formulate the expectations doc in a way that states that the "shoulds" of the document is a list they ought to pick from when creating their pledges?
That would work for me. And update their pledges if they add or remove in the future.

if so; do we need the current ANO-set to sift through the list and update their ANO-contributions thread with the "shoulds" they will adhere to?
Yes.

EDIT- I rescind this stance after thinking about Matt's statements below. We should have expectations. If people choose to abide by them or not is up to them. Some may choose not to support them if they don't, others will choose to support them.
 
Last edited:
I think having each ANO have a different set of Guidelines they will abide by is way too convoluted. Either have guidelines ANOs need to abide by or don't.

There's absolutely nothing wrong with having expectations for ANOs. If someone doesn't want to adhere to the ANO Guidelines, then this is not the right opportunity for them. None of these Guidelines are overly burdensome.

Let's also not forget that this "Guidelines" doc is the basis for removing deadbeat ANOs. If none of these Guidelines carry any true weight, then how are you going to remove a deadbeat ANO? Wouldn't that make all the work we've put into this document (and the ANO Removal process in general) a giant waste of time?
 
I think having each ANO have a different set of Guidelines they will abide by is way too convoluted. Either have guidelines ANOs need to abide by or don't.

There's absolutely nothing wrong with having expectations for ANOs. If someone doesn't want to adhere to the ANO Guidelines, then this is not the right opportunity for them. None of these Guidelines are overly burdensome.

Let's also not forget that this "Guidelines" doc is the basis for removing deadbeat ANOs. If none of these Guidelines carry any true weight, then how are you going to remove a deadbeat ANO? Wouldn't that make all the work we've put into this document (and the ANO Removal process in general) a giant waste of time?
Regarding that last part; I'm actually coming a bit around to the view that the standing parties themselves decide which ANOs to support or not without having to actually consult a list of do's and don'ts... That is how it will work "on-chain" in the future as well; you can put your standing behind anyone you like - or remove it from anyone you like...

So in theory we don't really need an "excuse" to vote someone out; the individual standing parties can decide unilaterally that they won't support a specific ANO...

On the other hand I do absolutely believe we want the document describing our collective expectations as well - as a way to guide ANOs to operate in a way consistent with what the standing parties deems good ANO practice....
 
Regarding that last part; I'm actually coming a bit around to the view that the standing parties themselves decide which ANOs to support or not without having to actually consult a list of do's and don'ts... That is how it will work "on-chain" in the future as well; you can put your standing behind anyone you like - or remove it from anyone you like...
1. And the difference between "not supporting" an ANO and "voting them out" is what? :)

2. How far off is this onchain solution? I'm guessing a while. Therefore, we need a stopgap.
 
Tor, in order to decide who we do and do not like in an efficient, logical manner we need data available in an easily digestible manner. We can't expect all Standing Parties to follow along every single aspect of this ecosystem. So to vote for ANOs, we need to have those expectations so that data can be generated based upon them AND Standing Parties can ask questions.

If we don't have all of this, voting for ANOs is going to be throwing darts while blindfolded.

This isn't a stopgap. Whether voting in on chain or not people need data so they can make a sound decision.

"Let's see. This ANO voted in all votes. Ran a stable server. Regularly updated the community. Is at X efficiency. And also did X, Y, Z. Great, I'll continue to support them."

"Let's see, this ANO voted in 12% of votes, their server was down on a regular basis, only updated the community once, their efficiency is only X% and they didn't seem to do anything else. Yeah, I'll remove my support"
 
I am fine with a list of suggestions for an ANO to use in constructing their pledges and their campaigns. It is a tool for an ANO (or prospective ANO) to leverage for support.

I am pretty much against the idea that an ANO can be called a "deadbeat" if they are meeting their Core Responsibilities, the things that we have them for in the protocol, and are performing to the expectations that they set with the community. Especially just because this document says that they "should" do, what, about 11 or so other things? None of which are Core Responsibilities?

I am working very hard to build the infrastructure and the demand on the protocol that I hope to make ANOs work hard to keep the protocol up and running, secure the hardware, deploy it, etc. It is great if ANOs want to do lots of stuff in addition to that, but if they end up focusing on whatever is their priorities but they are good at the Core Responsibilities, then I do not view them as "deadbeats".

I believe differences of opinions about priorities for ANOs do in fact vary over the community. A am a fan of setting expectations on these ideas by the ANO in their campaign pledge documents. And I am a fan of continuous campaigning, where changing your pledge is okay (but if the standing parties don't like it, you might get the boot).
 
Tor, in order to decide who we do and do not like in an efficient, logical manner we need data available in an easily digestible manner. We can't expect all Standing Parties to follow along every single aspect of this ecosystem. So to vote for ANOs, we need to have those expectations so that data can be generated based upon them AND Standing Parties can ask questions.

If we don't have all of this, voting for ANOs is going to be throwing darts while blindfolded.

This isn't a stopgap. Whether voting in on chain or not people need data so they can make a sound decision.

"Let's see. This ANO voted in all votes. Ran a stable server. Regularly updated the community. Is at X efficiency. And also did X, Y, Z. Great, I'll continue to support them."

"Let's see, this ANO voted in 12% of votes, their server was down on a regular basis, only updated the community once, their efficiency is only X% and they didn't seem to do anything else. Yeah, I'll remove my support"
And we are set up for political evaluations where we are creating confusion about what really matters for an ANO and these other things (that have nothing to do with their effort to keep the protocol running). As you demonstrate by sandwiching Core Responsibilities between a number of suggestions.

You and I might have a really big divergence in how we view the ultimate construction and governance of the protocol. I see a world where certainly ANOs are quite involved, but so are many other parties. Where the different categories of support force the various groups in the protocol to work with each other and listen to their ideas and perspectives.

And I believe in focus, and I don't expect everyone to have the same focus as everyone else, and certainly not over 11 different directions.
 
Yep, the quote is missing, sorry. Here's a quote I pulled from a comment of yours on the doc:


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'm fine with this organization change but can you list which of the suggestions should be "Community" and which should be "Protocol"? I'm not quite tracking the division you have in mind.
 
I think we need governance to fit the protocol as it exists right now.

Its great to have a vision that standing parties will vote entities in and out of the authority pool but right now we haven't even got a full set of authorities. I think this is ultimately the biggest problem.

Either we decide that ANOs are allowed to stay in the authority set as long as they fulfill their infrastructure requirements and until they can be voted out by standing parties or we put together this document which sets out a list of requirements that we need ANOs to perform right now.
 
Last edited:

Chappie

Factomize Bot
The final poll is available for Guides to vote on now for 3 days. If Guides pass the vote with 4 "Yes" votes then ANOs will be able to vote. If Guides fail to pass, there will be no further action.
 
Status
Not open for further replies.
Top