To Ned, re:roles
Ned,
You recently wrote a post on @steemitblog called "Steem Governance is multi-party." First, let me start by saying thank you for engaging. I think it's great for the community when you're out here discussing things on the platform. However, in this case it's hard to get on board with what you're doing. I don't completely agree with your direction and I'm not thrilled by the process by which you're doing it.
Your basic pitch as I understand is that witnesses need to produce code review standards by which they will accept hardforks. That's a fair ask, but you aren't involving us as a community so much as telling us what we need to do. I feel like this would be better handled as a discussion and possibly public forum than simply telling us what our roles are or how our roles fit into your scheme. Code review is really just one part of a Witness job, and certainly not the whole thing. You make it seem like the whole thing.
In your scheme (the post image) witnesses don't get to propose code? Is that not our function? What about design scope of new code to add? Should we have input into that? You've painted a very narrow box of what a witness does. I'm not dying to hop into that box as I think we provide more and have to provide more based on decisions Steemit made.
Discomforting start
The process you're putting forward feels frustrating as I perceive this current push for witness hardfork adoption standards as a knee jerk reaction born out of the hard landing of HF20.
Just prior to HF20 Steemit asked all witnesses to adopt the hardfork in this post.
"After completing the audit, we are highly confident in this release, and we have recommended that the witnesses upgrade their nodes in preparation for the planned switchover tomorrow."
Then when the implementation didn't go well you stated in a comment:
"I began mentioning it much more strongly prior to the hardfork when some Witnesses began admitting they hadn’t read the release notes and some top 20 Witnesses only began testing two days prior to the proposed HF. Ask Lukestokes or Reggaemuffin who began prompting Witnesses for their published standards and when.
Going forward speaking loudly to the definitions of the contiuents of Steem governance and their roles, especially going into SMTs and other innovation, is absolutely critical. Without stoic Gatekeeping from our Witnesses, the governance is weak. Without Gatekeepers holding devs accountable to Gatekeeper’s standards, or more importantly, without standards, deliverables are under tested. Without Stakeholders of users and businesses holding Gatekeepers accountable, Gates remain low. We need to raise the Stakeholders voice and raise the Gates and raise the demands for optimal approach to development, which should show itself in aggregate of Witnesses’ standards. Personally as a stakeholder I want from this governance a robust combination of conservative process with consistent drive toward innovative development. There are certainly marked improvements to make here in the short term."
At the time this statement felt a lot like "the hardfork didn't go as planned because the witnesses didn't do their work." I agree with a lot of what you're saying here, but the timing especially makes it feel like you're blaming witnesses for the initial failures of HF20. This feels especially bizarre given the post the day before saying essentially "please trust us even though there was a bug. We need to move forward anyway."
Was it a failure of witness standards?
It's hard to stand up and shout "Yes, witness standards will fix all of this!!!" Limited activity on the chain was identified, a fix was made, and it still didn't work. To me that's just part of adjusting a living blockchain. We're fixing a battleship while at warp. Shit's gonna break and all fixes won't work exactly as planned in the actual production environment. That said within 5 days we were backup and running with a much improved system. I'm skepitcal now that it's actually possible to get it right on the first approach every time, but I have unshakable faith we'll get it right after a little bit of iteration.
Ironically, the witness standards that you want, currently best exemplified by Tim's Post, would have required we don't push forward with HF20 which you were directly asking us to push forward. That is until it had been up and running and more stable on the test net first.
Which do you want? Launch on that exact date or holding back development of critical infrastructure until testing is better prepared as per witness standards? Those were mutually exclusive and you seem to be asking for both.
Testnet Challenges
Since the hardfork I've been logging into the testnet ever other day to check a very simple action. I refresh the page and try to vote on a post. Nothing happens. If I make a comment and then vote it works. It doesn't appear that the testnet is working for the lowest cost and most common activity on the chain. I think the testnet, training around it, and culture regarding it needs a lot of improvement before we can look to it to save us from rough implementations of hardforks.
Roles
I'm actually really excited to have a discussion about what is the role of a witness. I'd also like to clarify what is the role of Steemit. While we're at it we should try to work out what is the role of content creators, content consumers, and dapp creators. It's a very important question and one that should allow us to better help one another if we coordinate and agree in principle.
What should we expect stakeholders do?
I don't think this will go well if we tell you what your role is or you tell us what our role is. I don't work for you. You don't work for me. We're here to serve this community. This has to be a voluntary arrangement where we all get to feel like our approach, process, and execution adds value to the Steem ecosystem. Your current approach feels like you're dictating to me what my job is. I'm not comfortable with that.
I gleam from your public statement
"The Witnesses are the gatekeepers of the code. It is ultimately their decision whether code that is created by developers should be adopted and implemented in Steem. This is the role Witnesses are elected to serve..."
In this context it seems as though you're saying my job is to be a code monkey. Review line by line the code and determine if it will work. My problem is the last line "This is the role Witnesses are elected to serve." As phrased it feels like it narrows the role of Witness to just that where as in reality the scope of what the majority of the top 20 do is much larger.
My interpretation is further informed by this statement:
"We would expect that the standards governing the Witness’ own process for verifying code, and verifying that code process standards are met, would include information and documentation about each Witnesses’ code testing apparatus, or that employed by whomever performs their code review. We expect further that Witnesses who leverage their own apparatus for code review would be much more valuable to Steem than Witnesses who do not."
Again, this is in line with we're here to help you with code testing. I think the role of the witness starts even before that with designing what tweaks this chain needs to grow and succeed. We're here to have a discussion with stakeholders to make sure their needs are met. Code review is certainly part of the process, but honestly it's like step 6-7 and you seem to say it's priority uno.
Steemit's role?
Steemit seems to have structured themselves such that their role is specifically core blockchain code development. Sales, marketing, customer support, user experience, and other typical business operation don't seem to be priorities. By your decision on company scope you're putting other typical functions back on witnesses and the community as problems to solve. You're both asking us to do more while also saying our role is just code reviewers.
If Steemit is here to deal with the silicon based machines you are then by default putting it on witnesses to interact with the carbon based life forms.
Despite some of my critisims here I actually really love the vision of Steem as a blockchain for Dapps. I took that to heart and started Steem Monsters with much of that in mind with one of my literal purposes being to try to lead by example and show what's possible within that vision. I'm highly supportive of the vision, but I think some of the details and the process by which Steemit, Witnesses, and Stakeholders engage one another needs work.
Steemit's choices inform Witness decisions
When Steemit became a blockchain development company and narrowed it's definition to that it informed how much time Witnesses have to devout to other aspects of running a decentralized autonomous organization. It's not as simple as review code.
We have to alot time to manage servers especially during hardforks, review code while the system is in deep shit, manage the people or projects that helped us gain attention, help promote this place, help keep members engaged, help redesign the interface and provide additional interfaces. The list of how witnesses fill in is pretty extensive.
As a group we have a lot of roles to fill, so I question your assumption that every single person in this group has to be the code reviewer. There's literally too much work to be done to be 20x redundant. In the four higher education technology/software companies I've worked for ranging from 5B/year to 1M/year in revenue devs have accounted for 10-20% of the staff. It's not 100%.
At times you make it seem like everyone should be a C++ Dev. They can be great. They can also halt the chain. Being able to code doesn't imply they are an ethical fit for the role. Simply doing code review seems less important than making sure the intent of the code is a good for Steem in the first place. Just because one can code doesn't mean the code they develop will alleviate problems on the network. Code review feels on par with helping spread the Steem Ecosystem (sales/marketing) or helping current users have success (client success). It's one of many functions this chain needs to grow, but again I don't agree with the assertion that all witnesses need it.
Even if I did agree how many do that now? One? Two? The genius of Steem is that you don't need a PhD in computer science to be a successful dapp developer here. Yes we need code review, but it's not the only thing.
I'm ok having code review on the list. The idea that it's "OUR ROLE" as if we're here to simply make sure your code works feels incorrect and frankly insulting.
My number 1 hardfork review concern- public hearings
So, let me address your request of me. Namely what's my code review process.
I think the most important part of accepting code is public review. I think Steemit leadership and devs should be in public answering questions about what the code is, how it works, what the intent is, and detailing the nuance.
Code is Law. Passing laws in a democracy requires a public hearing.
I want Steemit to have a public forum just like any other democratic process about the law they are proposing. Public hearings are critical to governance, and it's something you and your company have avoided since I've been here.
Even in our distopian modern Democracy it would be unheard of for a lawmaker to propose and pass a law with literally zero public debate.
So, now what? My main ask is something Steemit has declined multiple times from me for about a year. How can you ask me to provide standards when the most basic request I have is ignored for over a year. How can we have a good review if we can't understand the real intentions behind the choices made when coding?
I suppose I could be obstructionist, but I'm not sure that adds value... I want to support this project and Steemit, but I feel like you guys are avoiding a central piece of governance.
So, how we find a middle ground?
My requests
- Please don't define the witness role. Invite me and other witnesses into a conversation about roles, and let's do that as a community together. Once we have roles determined then let's have a discussion if roles aren't being fulfilled. Telling us our portion of governance is weak and failing without engaging us in a discussion of what our portion is feels more like lashing out than fixing problems.
- Sometimes your messaging seems to indicate mutually exclusive options. Please be mindful of that.
- You seem extremely introverted, and as a consequence so is the culture of your company. Please make a push to include public hearings and public discussions live on recorded voice and or video conversations a part of the standard operating plan for hardforks and code changes.
My next step
When I worked BASF, the world's largest chemical company, I worked in a sustainable marketing division. While there I created a decision making guideline that I've used ever since. I'll make a Witness version of this public in the coming week, and talk about how Code Review is an important part of a larger role of the Witness and how we as a team can meet our collective goal of witnesses of sustainably growing the Steem Ecosystems for all stakeholders.
Gratitude
Ned, this post is critical of your current approach, but very strongly appreciative of what you do and I'm stoked to see you engage publicly in the discussion. For that I give you high praise and look forward to working with you to establish some guidelines around roles of various stakeholders and figuring out how we can collaborate to push Steem forward.
This is my home. I love it here, and I'm happy to spend my days trying to help it grow. I'm looking forward to collaborating on it's continuous improvement.
Sincerely,
Aggroed
AKA Dr. Blair Reich
Top 20 Witness
Founder of the Peace, Abundance, and Liberty Netowrk
Founder and Executive Director of the Minnow Support Project
Founder of MSP-Waves
Founder and CEO of Steem Monsters
Word.
I am glad that you start this discussion. We need more actual public democracy!
Reviewing the code that you plan on running should be your most important task beside running said code at scale.
I consider code review and testing to be technically as hard if not harder than writing it.
There's simply too much to respond to here to do it well, unfortunately. But thank you for writing the response.
I can see we haven't met on the same understandings, though.
For instance, no, I'm not suggesting Witnesses should be Code Monkeys -- but the ramifications of what I'm saying -- that Witnesses are the ultimate gatkeepers of the code -- may be that they should be Code Monkeys -- that is if a Witness believes in Upgrades. If a Witness does not believe in Upgrades -- then I can't imagine them reviewing much new code. Further -- if the Witness wants Upgrades but doesn't want to review code -- that's fine -- and it's even better as long as the Stakeholders understand. Incentives in Witness positions to have their operators do as their Stakeholders would wish should cause the right balances between Stakeholders and Witnesses over Tendencies to Upgrade or Not, and for what reasons.
In short -- I'm not telling anyone to do anything. I am suggesting that the balance of governance will work itself out. And I am suggesting that some prompting, such as posts like these, will help it become worked out faster. Really, it wouldn't make a difference if I had told you and others what to do. Like you said, you don't work for me and vice versa. If I had, you could ignore me, or not. On the surface, like that, DPoS doesn't really care.
I'm not entirely sure how you meant "the balance of governance will work itself out". But when engineering a piece of software or a machinery, we never let it work itself out. It's always designed based on our best understanding of how it will function. If it functions differently from how we predicted, then we tweak the design continuously until it does work the way we want. That is why computers, bridges, trains, etc. work quite reliably most of the time - because there was a certain process used when creating them.
The classic idea of democracy with division of power and the public voting for this party or that party was developed as a social technology that performed better than previous social technologies like feudalism where the rules of the game didn't allow most of the public to change the rules of the game. Blockchain as a social technology, and Steem as a particular implementation of it, seems to hold promise for a massive upgrade of the currently established social technology. One of the promises it holds, to me, is in changing the way things are done. If we use processes that are used in the world of technology and engineering, then reliable solutions will be produced (i.e. there is a massive track record of reliable solutions already produced using these processes).
It's a different way of thinking. The governance process has to be designed so that the needs of everyone get met. It's not about striking a right balance or anything like that. The best engineering solutions often times are about changing a trade-off to a situation where we have all the desirable things we want and the undesirable things are absent. It's about creating a solution that repeatedly performs the way we want it to perform.
How can this be done, in practical terms? I think the first step is to create a procedure for doing hardforks. If the procedure works well, we will see the results in the form of smooth hardforks happening and working the way we want them to. If the procedure doesn't work well, there will be downtime, issues and a lot of unpredictability when doing hardforks. If the latter is the case, then we will tweak the procedure for doing hardforks, and then measure how well it performs.
This is akin to scientific experiments - when a scientist performs an experiment, he or she has to write down the steps for others to be able to reproduce the experiment and get the same results. This is currently totally missing from the way our society governs itself, and I think with blockchain technology we can demonstrate how it can be achieved, and Steem can be the first example of it.
I usually avoid the debates on here, but, I'm a General Civil Mediator in the State of TN so maybe some input might help.
One thing I know is that open discussion and being willing to listen to each other is the first step in finding a mutual resolution. I would propose that the leadership team and the witnesses sit down together to make sure everyone is on the same page about the current expectations and future goals of Steemit. I'm still learning a lot about Steemit and how different blockchains operate, so free to tell me to mind my own business...no hard feelings here.
Yet HF20 sure has upset a lot of people. I'm still confused as to why a new person or low SP holders should get less of a voice. FYI...I'm upvoting this so it gets seen and again maybe this proposal will help...if not feel free to flag me and down vote, I don't care. I really believe in this place regardless and hope it succeeds. It will be interesting to see.
Have witnesses ever rejected a hardfork from Steemit?
The big thing that drew me to steemit was it's collaborative nature. Developers coming together with people who get the word out can make an awesome project. It's a mindset that I see ina lot of the witnesses, as well. When HF20 blocked users out of the network, witnesses like @aggroed and @crimsonclad too the time to tell people what they were up to. @therealwolf made a brilliant post that broke down the HF20 changes ina way that was easy to understand. It is a community that looks after itself, and doesa pretty damn good job of doing it.
I think you got the nail on the head, @aggroed. Dialog and discussion will goa long way in the long run, and will help alleviate quite a few concerns. We already know the community can come to a consensus on issues, so it should be difficult for @ned to open a dialog with the witnesses that inhabit this site. I mean, hell. Even your disagreement with @reggaemuffin last January over the SBD peg was the most civil disagreement I've ever seen on social media! We can definitely make something that works.
This is extremely well-put and spot on target. It's fundamentally witnesses' job to evaluate a hard fork, but the idea that that should be doing code review rather than managing code review is very off. You need to be paying attention to the people doing the code review, not necessarily doing it yourself.
(Please don't blame introversion, though. There's no reason introverts can't communicate well, we just have to be somewhat more intentional about it, which in this case is necessary anyway.)
It would be awesome if you, @ned, would join us at our monthly Steem Witness Panel. The many we have had have been informative, constructive and directional, aligning many top witnesss to come to concensus facilitated by the panel discussions.
Thanks
Quite a bit to chew on here. As a lower tier witness with @steemcreative, I'm interested to see what roles are expected of us outside the top 20. The comments should make for good reading.
Yeah I also think it was an attempt to pass the buck. They were unsure of the code and wanted to save face by misdirecting the blame toward witnesses.
Not cool @ned.
I think if someone sees a potential problem they should be able to present it off chain for further study. The witnesses are coming out of pocket for the sake of the network. At least let them get on the same branch and work together for all of our benefit.
This is my dream too that is why I am still here after all the BS and intend on staying. I believe in who I vote for. Stop mucking up my crypto!
Thank you @aggroed for all your valuable contributions to the network.
Peace.