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

Should the document be ratified or amended as specified?

  • Yes

  • No


Results are only viewable after voting.

Timed Discussion

Voting will end:

Secured
#1
This is the Ratification Discussion for Doc 003 - Authority Node Operator Expectations. At this point, the document should be fairly complete, but we can still make changes in this discussion before the ratification vote. Please review the current document carefully, including any outstanding comments or suggestions in the document, and suggest any further changes or raise concerns that would prevent you from being able to vote in support of ratification of the document.
 
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
#3
There was some dispute in the previous timed discussion thread regarding the 7 day limit for updating a node. Julian and David were in favour of reducing that to 72 hours at that time, whereas Tor and I were in favour of it remaining at 7 days. These are the arguments that were made for and against a 72 hour period:

@David Chapman:
7 days seems absurdly long. We're all supposed to have 24/7 coverage after all. I would hope we could all hit 72 hours for normal updates.
@Julian Fletcher-Taylor :
At the most fundamental level, our job is to be proper nodes for the protocol. Needing 7 days to update is not showing up to our job for a week ;)

I support 72 hours as well.
@Tor Paulsen:
There are a few (good) reasons to keep a rather long update time for “general updates”:
- You might not want everyone to update at the same time instantly. Having it done over a week means that we can stop the rollout if problems arise with some of the nodes (this happened with one of the releases just a few months ago and we stopped the rollout).
- The core committee does absolutely not want to have to ”time” the release of updates. A good example is right now... We’ll see a release today (most likely) and with a holiday on our hands that means that many people are not working. With a 72 hour window this would have been an issue. Heck, you do not even need a holiday: a release on a Friday would mean that ANOs would have to do it over the weekend....
- For an ordinary release there is no reason at all to actually have everyone update within 72 hours. Our updating scheme should be designed (and is) in a way that new releases doesn’t break backwards compability so different versions of factomd normally works together
- We all know that most ANOs are spending a ton of time on Factom, and providing some leeway when to do a specific thing that is not time sensitive is good practice. There is no need to push everyone to rearrange their week to get this done when it is not beneficial for the network.
- And the last thing: If someone has not updated within a week.... Then they have had a lot of time to do it, and if they didn’t... Well then anyone can inquire as to why....
Alex:
72 hours does just seem unnecessarily short for non-urgent updates.

Also, there are some occasions where it could be challenging. For example, I recently wanted to do some server maintenance that required brain-swapping out two Leaders, performing a system snapshot, applying the updates, performing another snapshot, then swapping the leaders back in. Those snapshots take a lot of time to complete (like 7 or 8 hours), so the updates took place over several days.

Updates are the perfect time to do that kind of maintenance. You don't want to have to shift things around and start transplanting servers more than is absolutely necessary, because every time you move an identity you increase the risk that you'll make a mistake and trigger an election. A longer update window gives people the opportunity to package their updates with essential server maintenance. You don't want or need to rush that.

I also support Tor's statement that spreading updates out over a long period gives us more opportunity to spot any critical errors with the release.
Original comments available on this thread: https://factomize.com/forums/threads/ano-expectations-and-requirements.1148/page-2

The discussion ended with the suggestion that 5 days might be an okay compromise. However, I would still very much like to hear the opinions of @briandeery and @Niels Klomp as I believe they could bring invaluable experience to bear on this discussion. So if you guys wouldn't mind sharing your opinions? Thanks.
 
Secured
#4
I'd like to propose an "unwarranted efficiency" clause. Something like:

"An ANO's value provided to the protocol should be inline with their efficiency."

Without this clause, two things could happen:
1. All an ANO has to do is adhere to the other "expectations" and they can drop their efficiency to 10% or so
2. If they already have a very low efficiency (e.g., 25%), then they only need to adhere to this document's minimum "expectations." We really need to avoid a situation where An ANO at 25% efficiency is doing 1/5th of the work that the average ANO at 50% is doing.
 
Secured
#5
I support Matt's suggestion.

ANOs should not publish any disparaging, derogatory or otherwise detrimental comments regarding the Factom protocol, except as expressly required by law. Raising issues about a feature or starting a discussion about possible improvements is acceptable; implications or accusations that the network has serious flaws in public should not be made by any members of an ANO.
I think the optics on this are poor. It makes it seem that we're stifling the free speech of network participants. I would remove this altogether.
 
Secured
#6
I support Matt's suggestion.



I think the optics on this are poor. It makes it seem that we're stifling the free speech of network participants. I would remove this altogether.
We also support removing the text Alex is referencing above.

Regarding update times we also support 7 days for ordinary updates based on the discussion above. It is not necessary to use a lower time period and it would only put extra pressure on already busy ANOs.

The rest of the document looks good in our eyes. Looking forward to having it ratified (hopefully).
 
Secured
#7
1. I agree with Alex about about Section 2.16. I feel like that is a tactic a company trying to limit PR damage would employ. We're better than that.

2. Section 2.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.
What if I want to abstain? Does that count as a non-vote?


3. Section 2.14 - ANOs should review and vote on every grant proposal during Factom grant application rounds.
What if I want to abstain? Does that count as a non-vote?

4. Section 2.8 - ANOs should make reasonable and good faith efforts to adhere to their currently listed ANO-pledges.
Adhering to "currently listed pledges"?

What about adhering to initial pledges? Or at least adhering to putting forth an equivalent amount of effort to what initial pledges were (i.e., things change)?
 
Secured
#8
I also agree that 7 days seems like a reasonable amount of time for a standard update. We can always reduce this figure in the future once our infrastructure is stronger and the codebase less bug prone.

As it stands getting all ANOs to upgrade within a 72 hour window could actually lead to infrastucture instability if we were to introduce a new bug into the codebase.
 
Secured
#9
1. Agree too. We need to be able to say whatever we want about the protocol. The only consideration here is that we may have something like "If you are aware of a serious bug or design flaw, you will disclose this to the core code committee and refrain from mentioning it publicly for 90 days"

2-3 Agree. Abstaining is important, and we also have to handle potential refusals

4. I think at some point, maybe not yet but eventually, we as a community need to move past initial pledges. So much has changed and so many have changed from their initial pledges. I think we socially enforce the initial/current pledge dynamic for now and not write "initial pledges" into documentation and stick with "current pledges"
 
Secured
#10
4. I think at some point, maybe not yet but eventually, we as a community need to move past initial pledges. So much has changed and so many have changed from their initial pledges. I think we socially enforce the initial/current pledge dynamic for now and not write "initial pledges" into documentation and stick with "current pledges"
This was never about "what the actual pledges were." This is all about people making promises regarding time/effort put towards the protocol. I could care less if people change pledges or don't execute their initial pledges, BUT they should still be expected to contribute the same amount of time/effort that they initially promised they would (just in a different manner than originally intended). If they no longer have the capacity to do so, then raise efficiency up to 70%. This can also be referred to as, "taking responsibility for one's own actions." AKA, being an adult.
 
Secured
#11
I think the optics on this are poor. It makes it seem that we're stifling the free speech of network participants. I would remove this altogether.
This was my suggestion to be added. It was meant as a way to stop angry/disappointed individuals in an ANO from damaging the outside opinion of the protocol. It was not meant to stifle constructive criticism of the protocol.

Without a clause similar to this any one of us could start a campaign to damage the reputation of the protocol while shorting the market and there's not a thing we can do to stop that person because there is no other mechanism within this document.

You could argue that the "emergency measures" ANO removal from Doc 101 - Removal of ANO from the Authority Set for Cause could cover this situation, but Doc 101 doesn't define this particular cause either.

I would like to keep some form of "don't be a dick to others" clause in the document to ensure we have a clause in Document 003 that we can point to when we raise a motion for removal under Document 101.
 
Secured
#12
I can empathise with your intention, @Ben Jeater. However, I think the solution as it currently stands is worse than the problem it tries to solve.

Regarding a "don't be a dick" clause, 2.10 states that ANOs should abide by the factomprotocol.org code of conduct. The CoC covers a lot of stuff about how we all treat each other, so violation of that CoC would be grounds for removal. You can see a draft of the CoC here: https://docs.google.com/document/d/1b_0T43wlFPeGc9DryLQMSdhNrwHjppEpjUGKxgqe9Cs/edit

Would that be sufficient, or did you have something else in mind?
 

Chappie

Timed Discussion Bot
Secured
#14
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
#15
Hi

Very supportive of making the ANO expectations clear through this document.

There are some good principles that now seem to be running through it:

Participate in governance
Keep nodes running with up to date software
Keep in communication
Pull your weight
Be supportive of other ANOs (Disagree in private and commit)

There is only one clause I am concerned about, given the global nature of what we are doing, namely:

2.12 If financially feasible, ANOs should make reasonable efforts to have at least one person from their team attend Factom Retreats which may be held once per year.

I think it is really important to have face to face meetings but consider that there are other reasons for potential non-attendance than financial. It could be health, it could be family, it could be sheer capacity for some ANO's trying to balance ANO work with a full time job.

Therefore I would urge that the apparently primary reason for non attendance - finance - be either changed to address some of these other valiid reasons or we just take out the "If financially feasible" and simply leave it as " ANO's should make reasonable efforts..." They can then judge and as appropriate justify whether they have made reasonable effforts under the circumstances.
 
Secured
#16
Thank you for highlighting this, @Mike Buckingham. Our code of conduct states that we should make an effort to be inclusive, and i think that ethos should apply here. There are many valid reasons that a representative might not be able to attend a retreat, and I believe trying to guess those in advance could lead to unnecessary hardship for otherwise hard working and diligent ANOs.

So I support your proposal that we amend the clause to "ANOs should make reasonable efforts...". That makes the expectation clear without putting hard working people into a difficult position.
 
Last edited:
Secured
#17
This was my suggestion to be added. It was meant as a way to stop angry/disappointed individuals in an ANO from damaging the outside opinion of the protocol. It was not meant to stifle constructive criticism of the protocol.

Without a clause similar to this any one of us could start a campaign to damage the reputation of the protocol while shorting the market and there's not a thing we can do to stop that person because there is no other mechanism within this document.

You could argue that the "emergency measures" ANO removal from Doc 101 - Removal of ANO from the Authority Set for Cause could cover this situation, but Doc 101 doesn't define this particular cause either.

I would like to keep some form of "don't be a dick to others" clause in the document to ensure we have a clause in Document 003 that we can point to when we raise a motion for removal under Document 101.
I think that Section 1.3 of Doc 101 covers spreading dishonest information with the intent to damage the protocol:

(i) the ANO has committed any action or omission involving dishonesty or fraud with respect to the Factom Protocol...
(v) the ANO has committed other action or omission that constitutes gross negligence or willful misconduct with respect to the Factom Protocol or that involves intentional conduct against the best interest of the Factom Protocol.
There's only so much you can do to protect the protocol from speech, though, as even if we booted an ANO for this behavior they could still engage in the negative information campaign as a non-ANO (and arguably would be more motivated to do so having been removed as an ANO).
 
Secured
#18
I can empathise with your intention, @Ben Jeater. However, I think the solution as it currently stands is worse than the problem it tries to solve.

Regarding a "don't be a dick" clause, 2.10 states that ANOs should abide by the factomprotocol.org code of conduct. The CoC covers a lot of stuff about how we all treat each other, so violation of that CoC would be grounds for removal. You can see a draft of the CoC here: https://docs.google.com/document/d/1b_0T43wlFPeGc9DryLQMSdhNrwHjppEpjUGKxgqe9Cs/edit

Would that be sufficient, or did you have something else in mind?
Section 2.10 only applies to people utilizing the website (emphasis added):

ANOs should abide by the factomprotocol.org code of conduct when utilizing the website.
 
Secured
#19
Hi

Very supportive of making the ANO expectations clear through this document.

There are some good principles that now seem to be running through it:

Participate in governance
Keep nodes running with up to date software
Keep in communication
Pull your weight
Be supportive of other ANOs (Disagree in private and commit)

There is only one clause I am concerned about, given the global nature of what we are doing, namely:

2.12 If financially feasible, ANOs should make reasonable efforts to have at least one person from their team attend Factom Retreats which may be held once per year.

I think it is really important to have face to face meetings but consider that there are other reasons for potential non-attendance than financial. It could be health, it could be family, it could be sheer capacity for some ANO's trying to balance ANO work with a full time job.

Therefore I would urge that the apparently primary reason for non attendance - finance - be either changed to address some of these other valiid reasons or we just take out the "If financially feasible" and simply leave it as " ANO's should make reasonable efforts..." They can then judge and as appropriate justify whether they have made reasonable effforts under the circumstances.
I agree with this. I've penciled that in as a change but will wait to apply it until we've given others a chance to weigh in.
 
Secured
#21
I would like to also support the amendment of 2.12... One could in addition also tie it to efficiency, as pure infrastructure ANOs might not benefit from such a meet up i the same way as developer-ANOs for which networking is much more important. Infra-ANOs will of course also have to communicate with both the greater community and other infrastructure-ANOs; but there are already multiple forums (literally) where we see vibrant and relevant discussions.

I don't know if it is the best solution, but I'd suggest we at least consider it.
 
Secured
#22
Jumping in here. We like the way the document is written regarding node update and timelines. We had a similar system when I was a maintainer on military aircraft back in the day. It was called Time Compliance Technical Orders, and had different levels of response dependent on the type of action. Routine, Urgent, and Immediate.

Seven days for a routine update (assuming it is just that and no urgency is required) should not require inordinate amount of effort to accomplish and should be updated at the time and choosing of the ANO. Updating by a block height is self-explanatory and ideally 7 days worth of time is given, but so long as the code and core folks are directive in their intentions, less time (72, 48, etc...) is acceptable. As for emergency action, we’re likely in a stall condition and it should be all hands available to rectify the situation ASAP.
 
Secured
#23
In that case, I propose we add a/the code of conduct to this expectations document. Perhaps it can be a lighter version, but it strikes me as sensible to codify that we not be abusive to each other, for example.

Thoughts?
The Code of Conduct was written specifically for the factomprotocol.org website and particularly to meet some qualifications for exchange listings that required having one. It's not a community ratified document and doesn't currently have a procedure for updating it so I'm leery of making it a requirement in the expectations document. Do you feel that Sec 1.3 of Doc 101 is insufficient for addressing you and Ben's concerns?
 
Secured
#25
I would like us to add a provision that states something like this:
- If an ANO suspects or knows that either one of their nodes or their Factom authority identities have been compromised by a third party, they should disclose this information as soon as possible to the chair(s) of the Core- and Code-committee.

Internal changes in an ANO's sysadmin composition might also constitute a risk, and should be discussed with the committee if deemed relevant to ensure the safety of the Authority Identity keys and the wider Factom network.


Note: The act of disclosing this kind of information to the committee should be commended by the standing parties, as doing so is an important aspect of maintaining and increasing the Factom network's security as a whole. It enables the Core- and Code-committee to reveal and identify potential system security issues, and ensures that Authority nodes are not operating with compromsised identities.
----


This concept of self-reporting is in my business (Air Travel) known as "just culture", and it is considered one of the main pillars necessary for contineous safety improvement.

"Just Culture" is a culture in which front-line operators and others are not punished for actions, omissions or decisions taken by them which are commensurate with their experience and training, but where gross negligence, wilful violations and destructive acts are not tolerated.

Punishing air traffic controllers and pilots with fines or by suspending their licences can discourage the front-line operators from reporting any kind of mistake, with a consequent reduction in safety information.

It is therefore fundamentally important to encourage the development of an environment in which occurrences are reported and the necessary processes for investigating and developing preventive action (such as re-training, improved supervision, etc.) are put in place.
My opinion is that we as ANOs need to embrace the same approach and provide an atmosphere where reporting issues related to security breaches etc. is accepted and commended, and that entities doing so should fear no social repercussions for disclosing this information.

It is the Core- and code- committee's duty to handle bugs and security issues, and the relevant information will be disseminated to the other ANOs in private when deemed necessary.
 
Secured
#26
1. I agree with Alex about about Section 2.16. I feel like that is a tactic a company trying to limit PR damage would employ. We're better than that.

2. Section 2.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.
What if I want to abstain? Does that count as a non-vote?


3. Section 2.14 - ANOs should review and vote on every grant proposal during Factom grant application rounds.
What if I want to abstain? Does that count as a non-vote?
You propose we add in the ability for abstaining?
 
Secured
#29
@Samuel Vanderwaal I don't think it does, as it does not specify anything with regards to how ANOs conduct themselves with respect to one another.

This isn't really a dealbreaker for me though, and I don't want to make a big fuss about it.
As I mentioned previously, I'm only concerned about this approach because I don't think linking to a non-ratified document as part of the expectations is a good idea as there is no process for changing the CoC currently. Do you have specific wording you'd like to add that accomplishes the same goal as the CoC?