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
Speaking hypothetically, do you think these standards would have authorized your witness to enable HF20?
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
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.
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!
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.
I see.
By the way, I find "STINC" to be a pejorative. Good luck with your witness.
I told him not to call Coca-Cola "coke" too, some people equate it with drug use... ;)
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.
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.
So aside from the question... and this might be setting myself up here, how'd you like the doc?
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:
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?
I'd sign on to this! in fact, I will...
@sapphic supports No-Bull Witness :D
Not every witness make 300 SP per month. I can't afford to pay another server with 40 SP per month.
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.
@noblewitness, I gave you a vote!
If you follow me, I will also follow you in return!
Have fresh pile of what U just drug in here, bub...
I love this gif - may I use it too? (I will totally use your line underneath as well! - nice fudge with that).
Have at it. I just got it from a gif search ;)
Probably my favorite award.
How about nope? It's our servers you are clogging up for no good reason. Buhbye now!
that's not to you, Cork.
that's on the bot
It's an awfully large gif, bud :) But not at all inaccurate! :)