You are viewing a single comment's thread from:
RE: Witness Standards For Team NobleWitness
Speaking hypothetically, do you think these standards would have authorized your witness to enable HF20?
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?
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.