Document Discussion ANO Expectations and Requirements

Timed Discussion

Discussion ended:

Status
Not open for further replies.
Secured
#1
The community has requested earlier access and participation in drafting new documents and two Guide meetings ago we decided on an approach to drafting new documents that engages the community from the very beginning. As suggested by Shuang from LayerTech the process is going to be:
  • Engage the community to put together the ideas and basic content of the document
  • Legal review of the ideas and content
  • Draft the document
  • Legal review of the document
  • Document ratification discussion and vote
This timed discussion is the first step for the ANO Expectations and Requirements document. In this case, we already have a partially drafted document to start with but it still needs vetting and fleshing out of all the ideas and suggestions for additional content. Nothing in the document should be considered finalized or set in stone--it's all open for discussion.

The goal for this document is to create a list of community expectations and requirements for all ANOs to adhere to so there's no ambiguity about what ANOs expect from each other. This should include things like voting participation levels, pledges, software upgrade response time, etc.

Please review the document and discuss what expectations and requirements are appropriate for ANOs in this ecosystem. This is a major discussion, so will last for 8 days. At that point I will take the consensus developed in this thread, have legal review it and then will draft up a document for ANO ratification.
 

Chappie

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

Everyone 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 may 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 and if a majority of voters vote yes by the time the discussion is scheduled to end, the time period will be extended for 72 hours.
 
Secured
#3
We have just finished a grant round where 4 ANOs didn't vote on any grants at all. Abstaining is a valid action, but in this case they abstained on every vote (and didn't take part in discussion either).

Engagement with the grant process is essential in order to ensure an equitable and efficient allocation of protocol resources. Therefore, I believe there should a requirement for some level of engagement in grant rounds.

Do others agree? If so, could this come under section 2.1?
 
Secured
#4
"Requirements" could be interpreted that an ANO should be removed if any of these are not met, is that the intention?

For example, if an ANO normally responds to Emergency alerts immediately, but one time they take 2 hours and 10 minutes to respond, I don't think this document should say they should be automatically booted. What if we call this something like "Expectations and Guidelines", and we can still point to it when defending the removal of an ANO?
 
Secured
#5
I'm also in agreement that the part "requirements" should be removed, and that this is a set of expectations that we all (or at least 4/5 guides + 3/5 ANOs) agree on should be adhered to....

The repercussions of not doing so is only social and nothing else; i.e we don't describe that they should be removed or "punished" in the documentation.
 
Secured
#7
I'm also in agreement that the part "requirements" should be removed, and that this is a set of expectations that we all (or at least 4/5 guides + 3/5 ANOs) agree on should be adhered to....

The repercussions of not doing so is only social and nothing else; i.e we don't describe that they should be removed or "punished" in the documentation.
We do need to be careful about this. This then really is a preparatory discussion. In that spirit should we not have two elements: requirements, which have consequences and expectations ...which may have consequences? I am being contentious to prompt discussion.
 
Secured
#8
I think that we need a method for removing ANOs who consistently fail to participate in the ecosystem and who do not perform on their pledges. I don't mean ANOs who occasionally miss voting or respond to alerts in three hours instead of two, but ANOs who are clearly freeloading and not making a good faith effort to participate in the ecosystem. The current removal document does not have any method for this. There are a couple of options:

* Add something for this specifically to the ANO removal document
* Create a list of "Requirements" which are removable offenses and "Expectations" which are social consequences only
* Otherwise define how many missed "expectations" or "requirements" warrant a removal
* Leave it subject for ANOs to make the argument about which missed requirements or expectations warrant a removal
 
Secured
#10
"Requirements" could be interpreted that an ANO should be removed if any of these are not met, is that the intention?

For example, if an ANO normally responds to Emergency alerts immediately, but one time they take 2 hours and 10 minutes to respond, I don't think this document should say they should be automatically booted. What if we call this something like "Expectations and Guidelines", and we can still point to it when defending the removal of an ANO?
Hi, In this event the requirements have not been defined properly. By way of example shouldn't we define a mean time and a standard deviation within which ANOs need to respond to Emergency alerts?
 
Secured
#12
I think that we need a method for removing ANOs who consistently fail to participate in the ecosystem and who do not perform on their pledges. I don't mean ANOs who occasionally miss voting or respond to alerts in three hours instead of two, but ANOs who are clearly freeloading and not making a good faith effort to participate in the ecosystem. The current removal document does not have any method for this. There are a couple of options:

* Add something for this specifically to the ANO removal document
* Create a list of "Requirements" which are removable offenses and "Expectations" which are social consequences only
* Otherwise define how many missed "expectations" or "requirements" warrant a removal
* Leave it subject for ANOs to make the argument about which missed requirements or expectations warrant a removal
Hi Sam, I think you are on the right track when you talk about two lists, requirements and expectations.

It may be inappropriate for automatic consequences to follow and consider that, using the ANO removal process or something like it, may be justified. This should enable due consideration of mitigating factors (ill health, family problems etc).

"Measurement" of the offence may be inaccurate and in turn should be subject to scrutiny which a review process could provide.
 
Last edited:

Chappie

Timed Discussion Bot
Secured
#13
We are now 18 hours into the discussion. If you have taken part in the thread, you may now make a motion to extend this Major Discussion by 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
Hi Sam, I think you are on the right track when you talk about two lists, requirements and expectations.

It may be inappropriate for automatic consequences to follow and consider that, using the ANO removal process or something like it, may be justified. This should enable due consideration of mitigating factors (ill health, family problems etc).

"Measurement" of the offence may be inaccurate and in turn should be subject to scrutiny which a review process could provide.
Just want to chime in here again...


I don't think we can describe that "this is a requirement - and if you don't do this you will be removed!"...

This is because the ANO-removal process is a social one and can only be executed by the standing parties and you cannot "force" them to vote in one or the other direction when the ANO is up for removal... And we are absolutely not interested in having a "central authority" to execute this on behalf of the community...

So in my mind the only thing we can do is to define EXPECTATIONS, i.e the standing parties EXPECT you to do a, b and c (examples: participate in governance, respond to alerts- and update requests and adhere to your pledges (or change them if you don't intend to)....... And the consequence of not living up to these expectations is that someone (a standing party) can invoke the ANO-removal process to have you removed.
 
Last edited:
Secured
#16
We have just finished a grant round where 4 ANOs didn't vote on any grants at all. Abstaining is a valid action, but in this case they abstained on every vote (and didn't take part in discussion either).

Engagement with the grant process is essential in order to ensure an equitable and efficient allocation of protocol resources. Therefore, I believe there should a requirement for some level of engagement in grant rounds.

Do others agree? If so, could this come under section 2.1?
Added the following:
ANOs will read every grant and vote on every grant.
 
Secured
#17
I have done some changes as well.

- Approved the suggestions for renaming the document "Authority Node Operator Expectations".

- Changed shall/will to should (these are expectations and not requirements)....

- Suggested to refer to "working group" instead of committee (if we are going to make such a change for decentralization-purposes (committees are deemed more centralized than working groups) we should amend it prior to ratifying this document.

- I suggested amending the part about having to attend all but one ANO-meeting a year. ANO-meetings are not part of our official community governance structure at this point, and there are no process that describes when they should be held (timezone), how long in advance they should be announced (I know we have a "last thursday(?) in the month thing going - but it's not official)... Attendance is not defined (showing up for roll call and then sneaking off?).... So for now I believe we should go with "ANOs should attend the monthly ANO meetings".

- ANOs will make every effort to have at least one person from their team attend a Factom Retreat once per year.
^^^^ I am a bit uneasy about this one... I think that this limits our abilities going forward. Personally I believe we will move more and more into specialization of the roles in the ecosystem where the ANOs will focus more and more on infrastructure hosting only and compete with each other on efficiency. We might even see efficiencies in the 95-99% percent; and also maybe have dynamic efficiencies where ANOs are part of the authority set for only a few blocks at a time before being replaced.... And then dipping back into the authority node set a few blocks later etc....

So going down a route where every ANO is supposed to make every effort to travel is in my opinion not a good choice... Especially considering that we have ANOs all over the globe (NZ to US is a 20+ hour flight)....

Amending this to "should attend" is a better route to take IMO.

- I suggested amending the 99.9% requirement to "as close to 100% uptime as possible".... It will still account for the ANOs who leave their servers offline, and we don't really want to impose centralized monitoring of uptime etc... Also who has the burden of proof? is it "the accuser"? The core committee? Someone else?.... Better to have it generalized, and if it is an issue it can be pointed out that "it was offline for 4 hours on the XX date without the ANO reporting/explaining it - and they were unreachable for xx duration".... And then a social decision can be made based on that....
 
Secured
#18
I totally understand trying to enforce participation and engagement.

However for things like ANO meetings it’s hard for some people, including us, to guarantee attendance at these.

It’s not due to lack of engagement but employment to pay bills and support Factom projects.

Whilst we can outsource server operation to fallback mechanisms, we can’t really outsource ANO meetings.

Again for ANO retreats - well that’s far far easier for people living in US.

These problems melt away with higher FCT price. Today, they are a reality of survival.
 
Secured
#21
I have added some comments, suggestions, and additions to the document.

I see this document as a way of providing "guidance" to ANOs for when they should consider cancelling payments to another ANO. At the moment there is no community guidance I can point to and say "This ANO violated this clause, so I set my server to vote to cancel their payments".

I hope I got the cancellation of payments thing right; I'm still hazy on that part of Factom :oops:
 
Secured
#22
I appreciate everyone contributing to the discussion. Originally I was thinking we'd hash out the ideas in this thread and only then would we make changes to the document, but I see a lot of people have been contributing suggestions directly to the Google doc. That's fine if that's how people want to do it but I'd encourage everyone to post all the changes they suggest directly in the document here as well, so we can keep the discussion in one place. Google Docs is not well set up for a detailed discussion, IMO.
 
Secured
#23
List of suggested changes to resolve:

  • Will vs Should
    • This seems to be about whether or not these actions are to be mandatory with social consequences or rather just social guidelines
    • @SL @Nikola are there any legal differences to be aware of that might suggest one wording over the other?
  • "Reasonable and Good Faith"
    • Does this need to be defined for 2.8 to have meaning or does this term already have legal connotations? @SL @Nikola
  • Is abstaining from votes acceptable? Should it be counted as part of voting participation?
  • ANOs discovering bugs or vulnerabilities in the Factom protocol must not disclose these bugs publically for at least 180 days. Bugs and vulnerabilities must be raised to the Factom Core Development Committee to allow patches to be rolled out across the network.
    • 180 days seems like a long time to me. Is this standard? Anyone from Core, Code and Tech Committee want to comment? @Niels @briandeery @AdamSLevy
 
Secured
#24
List of suggested changes to resolve:
Will vs Should
This seems to be about whether or not these actions are to be mandatory with social consequences or rather just social guidelines
However it is worded, it needs to be clear that there are very real social consequences for not adhering to the expectations. You might not get booted for one issue or maybe even two (it all depends on perspective), but three? Four? There is cause to remove you.

Is abstaining from votes acceptable? Should it be counted as part of voting participation?
While I am of the opinion that we should never abstain from a vote, IF it happens, there should be an "abstain" option so that those who don't bother to vote can't claim to have abstained.
 
Secured
#25
However it is worded, it needs to be clear that there are very real social consequences for not adhering to the expectations. You might not get booted for one issue or maybe even two (it all depends on perspective), but three? Four? There is cause to remove you.
I agree. Let's see what legal says about the difference between the wording.

While I am of the opinion that we should never abstain from a vote, IF it happens, there should be an "abstain" option so that those who don't bother to vote can't claim to have abstained.
I'm not sure I agree with this. I can think of some reasons why some Standing Parties might justifiably abstain from votes. I do agree that we need to make a distinction between abstaining and simply not-voting. I'm in favor of the next grant round scoring providing abstaining as an option.
 
Secured
#26
The expectations document is coming together nicely but I do think it is misleading to mix requirements and expectations together.

"Shoulds" and "Reasonable expectations" would be better separated to make it clearer to a new ANO that there is a clear difference between them. I would also suggest that we try and order them so the most important ones are closer to the top of the document to signify their importance. Right now two "must nots" are at the very bottom of the document.

I understand this is just the first step document so if my suggestions are out of line with that then I apologize :)
 
Secured
#30
Will vs Should
  • This seems to be about whether or not these actions are to be mandatory with social consequences or rather just social guidelines
I have been using "shall" to create obligations and to express something is mandatory; however, it is suggested (in several sources) to use "must" instead of "shall" to avoid any confusion.

===========
Use "must" instead of "shall".

shall imposes an obligation to act, but may be confused with prediction of future action
will predicts future action
must imposes obligation, indicates a necessity to act
must not indicates a prohibition
should infers obligation, but not absolute necessity
may indicates discretion to act

To impose a legal obligation, use "must."

To predict future action, use "will."

DON'T SAY: The Governor shall approve it.

SAY: The Governor must approve it. [obligation]

OR: The Governor will approve it. [future action]"

===========
see: https://www.archives.gov/federal-register/write/legal-docs/clear-writing.html.

This document is going to be tied to the ANO removal document. If an ANO can be removed for not meeting certain standards set forth in this document, then meeting the standards should be an obligation for the ANOs. If this is merely a suggestion or a guideline, then removing an ANO for not meeting the standards can be very controversial.

I agree with maxlambda that requirements and non-mandatory expectations should be separated.
 
Status
Not open for further replies.