Witness Standards For Team NobleWitness

noblewitness (49) in witness-category • 6 years ago

Witness Standards For Team NobleWitness

This document is to be considered a "living document", subject to modification and replacement with subsequent posts made on the Steem Blockchain.

This document is a collaborative effort, approved by all four members of Team @NobleWitness, which include @SirCork, @Gmuxx, @RhondaK and @Anarcho-Andrei.

Our expectations of all Steem Witnesses (Including ourselves):

A witness should always remember and place importance on stakeholders and users needs first and foremost, for without them, there is no need for witnesses to exist in the first place.
A witness should maintain a current, functionally specified and always operational witness server node.
A witness should always maintain a back up server, ideally with automated failover protocols in place to ensure maximized uptime and availability.
A witness should be aware, involved and committed to reviewing code changes to the SteemD block chain core software, as found in github.com
A witness should be involved in testing, evaluating and where and when possible, involved in suggesting or even implementing patches to this code which ensure chain continuity, growth and operational intent as reflected by consensus of voting stakeholders on the platform, and in conjunction with other witnesses in positions high enough to be responsible for chain modifications by consensus.
A witness should be able to articulate changes to users when asked and proactive when possible in relating change related and general meta information about the operation of the block chain to block chain users, whom are all stakeholders of some level, on this delegated Proof of Stake, decentralized system.
A witness, in our opinion need to little more than the above to meet the "letter of the law" as it were with regard to operating as a viable and committed witness node. However, we on team @NobleWitness also feel much more is nescessary of a truly committed witness on the Steem Blockchain and this can include but is not limited to, creating user tools, forming and/or participating in communities of steem users, engaging in philanthropic projects, promoting steem and our chain as the best in the world, encouraging users and aiding in user retention, and holding our peers and the other chain maintainers and app operators and developers to high standards of proficiency, professionalism and perseverance.

Our standards for adopting a Hardfork:

At minimum we should understand the changes to be implemented and consider the ramifications of their inclusion or exclusion, alike.
We should be provided with appropriate documentation by any developer of a new feature and allowed time to review the documentation and the code.
We should have access to a community test network that emulates the live environment in a viable way and we should have time and access to this network in order to perform our due diligence on upcoming change requests prior to their inclusion or omission from core code commits.
We should move quickly to determine our position on acceptance or deferral of a potential hardfork (or any minor incremental version changes) and register our vote, should we be in a consensus making rank, or register our opinions with those in such consensus determination positions in adequate time for our professional opinions on the matter to be heard and applied.
We should be committed to the longevity of the chain, the operational capability of the chain, the functional viability of the chain and the security of the chain. When we are unqualified in a specific technical area, and we should be qualified in at at least one or more of these areas, we should engage in education or have someone on our witness teams who are such qualified persons at our disposal. If using an external person beyond a witness team or individual witness operator, this should be DISCLOSED to platform voters and stakeholders. We need to know who is really making the decisions for any given witness operator and we feel any less of an expectation is a remission on the part of the voter AND the witness in focus.

General Software Development Best Practices:

Regression and Forward Testing is required and paramount to success. Really there is very little to add to to this obvious assertion.
Understand version control and how we apply it here. In our case on Steem, this presently means Github and the Steemd repository. At least one person on every witness node team should be registered with github and involved in review and participation therein on a case by case issue and pull request basis when a witness has relevant, contextual input to add to the conversations and decisions that are made there.
Iterative development and continuous and frequent incremental improvement is better than massive wholesale sea change level based releases. Mitigate mistakes by making smaller mistakes, and make no mistake, mistakes will be made!
Where possible, seek user input on potential changes, and measure twice, cut once, to ensure adoption is not met with rejection before surprising your users with new changes that catch them off guard. Users are generally in preference of not knowing how a car runs to simply drive it, but offering users the chance to provide input may surprise you with the lucidity of some of their feedback. We are NOTHING without users so let's not alienate them completely before we even begin.

Additional Remarks:

We expect a little bit from you non-witness users of the platform as well...

We expect you to become educated voters, and to do your due diligence regarding the application of your 30 available witness votes.

We urge you to examine and evaluate the various criteria many use to make such selections and to supply your own criteria as well when making your decision.

We expect you to continue to use the platform in the ways made possible by it's tremendous potential and offerings and we urge you to, like us, embrace the change, chaos and excitement that comes along with such rapid growth and development.

In such uncharted territory as that which we continuously advance toward, through and beyond, we expect you to lean into the curves, growing, improving, adapting, and improvising toward overcoming your individual obstacles, and we will help with that when and wherever we can to achieve success as you might define it for yourselves.

To those of you who already have opted to assign one of your 30 valuable votes to our team, we would like to say Thank You!

Thank you for trusting, empowering and supporting Team @NobleWitness, The No Bull Witness as one of your selected representatives chosen to be responsible for acting as one of your advocates for the security, operational capability and general caretaking of the part of the future of this blockchain upon which we all mutually share our inputs and operate on together.

We look forward to a bright and rosy future as we work side by side with users of the platform to usher in a new age of freedom, liberty and opportunity for everyone participating in this ongoing, and ever so exciting adventure.

We're all in this together and as @SirCork has said since his earliest steem related streams began back in 2017:

"Teem work makes the steem dreem work!"

Kindest Regards,
The @NobleWitness Team
@Gmuxx, @Anarcho-Andrei, @RhondaK, and @SirCork
"The No Bull Witness Team!"

Learn More on our blog at http://steemit.com/@NobleWitness
or by visiting our project and tools homepage at http://steem.agency

witness-category witness-update steem development standards

6 years ago by noblewitness (49)

$35.12

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!

Sort Order:

Trending

[-]

inertia (73) · 6 years ago

Speaking hypothetically, do you think these standards would have authorized your witness to enable HF20?

$0.14

3 votes

[-]

sircork (64) · 6 years ago

In this case, no. What is not included in this document and which should have been, perhaps, but was not really presented as part of the "assignment" as it were, is a section on what we expect from "steemit, inc" and perhaps that section is rightfully not part of the assignment, as they are merely one of many entities who could theoretically or practically submit acceptable changes to the steemd codebase.

That missing section would call for clear, concise and timely change documentation in a single location, with comprehensive coverage of changes, and intended/expected outcomes. "Dig in github" is not an acceptable answer here.

Further, clear and concise comments in the code, at the affected lines, would be helpful, but not always required, if the above documentation was able to reference specifically altered files, and even line number level pointers. Again, "use github diff" by and of itself as an answer is not acceptable in a proper QA protocol and wouldn't be acceptable here either, in an environment within historically incrementally developed code, touched by dozens of developers over two years, without standards at a consistent level over time.

Still further, we've argued this point before, conceding points in both directions to each other that the test environment was neither properly configured to emulate a reasonable staging environment nor made unililatery available in a well documented, established location wherein all witnesses desiring to exercise their obligation/right/need/intent to test on it were even aware of how, when and where it was.

So if we included requirements for developers and code gatekeepers, primarily Steemit Inc at this time, then no, this nor the 19.x version that produced unintended fork crashing the week prior, would NOT have been acceptable.

Given our guidelines above, the testing requirement could not adequately be fulfilled minus the above, so no, we could not have in good conscience greenlighted this HF at the time of release.

That said, I also know from our direct conversations, that you yourself are working on these very issues directly now, and as I have said to you in public in person, in SteemSpeak, I have faith you are going to aim for the correct infrastructure to make some of this all more possible, and effective.

Good question, speaking hypothetically :D

$0.10

3 votes

[-]

sarez (64) · 6 years ago

1.- Steemit. Inc needs to be more user friendly, specially during changes
2.- Witnesses need to act FOR all Steemians
3.- Witnesses should act like responsible adults
4.- HF20 could have gone smoother if only all the above parties cared enough.
Did I get this right? If Steemit is to remain the best place to be @sircork we need more witnesses like you.

$0.00

[-]

sircork (64) · 6 years ago

If I take you exactly as written I'd agree you got it right.

If I get confused about #1 and aren't sure if you mean the company needs to be more user friendly, Id agree, in terms of communications and their current record of piss poor management behavior, but if you mean steemit.com the condenser blogging UX interface to the chain, well, it could be better, but that's not the same as the block chain itself. And as such outside the real requirements of a witnesses attention or focus.

Thank you though, for the compliment!

$0.00

[-]

anarcho-andrei (64) · 6 years ago (edited)

If we're going to be honest, hypothetically we wouldn't have enabled HF20 by our criteria. The biggest block would be inadequate/ad hoc testing guidelines for the testnet. Granted, there is a level of common sense in testing any new software update for unwanted or unpredictable behavior, and we're not privy to all communications between Steemit Inc. and others. However, I don't think the code was adequately tested prior to adoption, nor was there a chance to do so, and this is not the fault of the witnesses that were testing it.

Cork and I were typing at the same time, but he managed to get his out a bit faster. lol His points are more fleshed out, but they echo the same sentiment.

$0.09

2 votes

[-]

inertia (73) · 6 years ago

I see.

By the way, I find "STINC" to be a pejorative. Good luck with your witness.

$0.00

[-]

sircork (64) · 6 years ago

I told him not to call Coca-Cola "coke" too, some people equate it with drug use... ;)

$0.25

1 vote

[-]

anarcho-andrei (64) · 6 years ago

I edited the post to change it to Steemit Inc. I'm used to using it as shorthand, so I apologize for including it here.

$0.00

[-]

inertia (73) · 6 years ago

Yeah, I didn't mean to short circuit the discussion with that. And I'm aware that top witnesses use the pejorative as well.

I think what's more important is that it be discussed on the blockchain. It's too bad that not enabling a hardfork is viewed as simple apathy.

I hope that posting standards becomes the norm.

$0.07

3 votes

[-]

sircork (64) · 6 years ago

So aside from the question... and this might be setting myself up here, how'd you like the doc?

$0.00

[-]

inertia (73) · 6 years ago (edited)

It's really not up to me. It's more important that your witness declares its standards and adheres to them. The real questions are:

Do you think you can use this standard to justify the adoption or rejection of a hardfork?
Do you think it would be justified for the community to maintain their vote for your witness if you adhere to your standards when dealing with a hardfork?

That last one has an inverse corollary: If you reject a hardfork and the community retaliates by dropping support for your witness, is the community unjustified because your standards have not been met?

$0.00

[-]

sircork (64) · 6 years ago

A. The standards give us the tools to make the decision, they do not make the decision.

B. Both the premise and the inverse corollary don't really directly apply either. It's not up to us to "think the community is either justified OR unjustified" in any witness decision they make as stakeholding voters and users of the platform. We certainly WILL think about it, but it is somewhat irrelevant to the decision making process. In the sense we will listen to the community feedback as insinuated and and in some ways directly relayed in the post, it is our job to determine if a hardfork should occur or not, that is contingent on what is IN it, and IF that update actually works.

Then it's our call to make if we press the go or no button, and with every decision we make, we will gain fans and lose fans. That's just the nature of change in general.

Is the community "justified or unjustified?" The question is moot. The community is always justified to do whatever it wants to do with it's votes.

Thanks for your feedback! I (and probably I'm safe in saying, "we") appreciate that you took time to look at this post.

$0.00

Show 2 more replies

[-]

sircork (64) · 6 years ago

$0.07

2 votes

[-]

underground (67) · 6 years ago

I'd sign on to this! in fact, I will...

@sapphic supports No-Bull Witness :D

$0.00

[-]

fbslo (70) · 6 years ago

A witness should always maintain a back up server, ideally with automated failover protocols in place to ensure maximized uptime and availability.

Not every witness make 300 SP per month. I can't afford to pay another server with 40 SP per month.

$0.00

1 vote

[-]

sircork (64) · 6 years ago

Most of us didn't when we were smaller, but the cost of lost blocks as you advance, makes it a necessity above about 80... and affordable on the income. We came to witness first, and safeguard the chain. Any income is secondary in that pursuit for our team. Not sure about all others, but it's important to consider why people witness. And the costs.