You are viewing a single comment's thread from:
RE: Witness Standards For Team NobleWitness
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?
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.
I only bring up the question about justified vs. unjustified because it's moot. If you publish the standard, "HF21 shall not use big-endian serialization" and you find during code review that it does, regardless of why, it deviates from your standard and cannot be adopted.
Then the release notes are posted, hardfork timestamp committed and tagged to a version number. All that's needed is for witnesses to adopt, and you don't.
Then, let's say the community pulls support for your witness. I would say the community is unjustified in that situation because you posted a standard, you adhered to the standard. If the community was going to pull their support, it should have been when the standards were published.
Anything else seems like a political move after that.
It seems we agree.
As Ringo Starr once said, as heard at the end of a song when they were famous but recording in "The Cave" where the Beatles began...
"Thank you very much, and I hope we passed the audition!"