To Ned, re:roles

in #steem6 years ago (edited)

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

  1. 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.
  2. Sometimes your messaging seems to indicate mutually exclusive options. Please be mindful of that.
  3. 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

Sort:  

Word.

I am glad that you start this discussion. We need more actual public democracy!

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?

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?


Thanks for your time.Hello there @austibitbank I hope you may be great. I would like to contact you about how to make an alliance with you or the communities you represent. I am running a curation community and It would be great counting on your support as much as you can when possible.

STEEM




Únete al servidor de Discord de nuestra comunidad.
"Siempre estamos buscando y apoyando talento real como el tuyo."
Iconos tomados de Icons8.com@theghost1980 Saturno Mangieri Curador de @steemitvenezuela y miembro de @sndbox

Thanks for the downvote on my comment. Have a great life!

100% self voting your own comment to pitch your own curation community in an unrelated thread gives a bad first impression. I can't support more communities effectively then I am already sorry

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.

I can translate into Indonesian this post :)

https://busy.org/@develcuy/hf20-why-steem-software-development-process-is-broken-and-why-to-fix-it-now


Not Spam, this is a post I highly reccomend reading regarding to HF20, undervalued (steemit style) and past his payment. My opinion is also there boss.


Cheers!

The thesis of that post is basically that we need testing on a testnet. Testing is underway and it's improving, but it's not a catchall yet.

"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."

The context of that post was a prior chain halt. It wasn't an announcement that HF20 should be approved. It was an announcement that the chain halt won't result in a delay.

"We will be fully staffed and prepared to deal with any problems that may arise. We are making this recommendation because we have the utmost confidence in the safety of the code and we believe that sticking to the scheduled time will minimize wallet downtime on exchanges. As of now, a super-majority of the top 20 Steem witnesses is running version 0.20.2 of steemd which means that, if nothing changes, the hardfork will occur tomorrow, September 25, 2018 at 15:00:00 UTC."

It's possible I continue to misread this, but my interpretation stands after reading it again that Steemit was suggesting witnesses make the change and stay on schedule for the Hardfork on the 25th. The bolded section and the timing suggest to me Steemit was inviting Witnesses to be on HF20.2 to hit the deadline.

I understand the distinction that the argument could be "if you like HF20 don't let this delay you," but I don't find any of that nuance in the post.

COMMUNICATION
It is a start.

Again it is a start.
Thanks to all
Keep on postin' Put all egos away and find a way to make #steem better.

Concise, straightforward, intelligent, and thoughtful analysis of the situation. This is why you’re a Top 20. Hopefully this helps to facilitate practical, common sense solutions that elevate Steem to new heights.

Posted using Partiko iOS

I Love STEEMIT and Thank You @aggroed for putting all on the table. It is voluntary to be here and you were right when you mentioned to @ned that you don't work for him, nor does he work for you..........Great things happen when people are willing to engage in a Meaningful Back and Forth.............

@aggroed, very open hearted talk, it is helpful to the community that you let it out to help us find away forward to a greater height. Carrying all this on your chest wouldn't have been helpful to anyone. We await @ned move. I just think you all have the best interest of the community at heart & getting to the peak means we all work together. Kudos.

Posted using Partiko Android

I believe is important to debate and come to a concensus that both parties feel confortable with. Dictate a direction is not always the best approach and sometimes is better to engage the community.

Posted using Partiko Android

Great and interesting post. As you suggest in a corporate company - and I have worked with 4 - these discussions would be held in the boardroom or in a IT management steering team meeting. I mean open public discussions is fine but to the outside world this may look as chaotic.

Love your critical and constructive criticism and cannot agree more, that more dialog and communication is required to improve Steem's governance. Politics aside, I think Steem urgently needs a proper testnet with as much real-world data and activity as possible, maybe it would be an idea to mirror the mainnet on a separate testnet, such that every user can login there too and test it.

Hi @aggroed!


Your UA account score is currently 8.446 which ranks you at #9 across all Steem accounts.
Your rank has not changed in the last three days.Your post was upvoted by @steem-ua, new Steem dApp, using UserAuthority for algorithmic post curation!

In our last Algorithmic Curation Round, consisting of 223 contributions, your post is ranked at #87.

Evaluation of your UA score:
  • Your follower network is great!
  • The readers appreciate your great work!
  • Try to work on user engagement: the more people that interact with you via the comments, the higher your UA score!

Feel free to join our @steem-ua Discord server

how I wish you were in charge @aggroed or at least had more power. This makes very revealing reading.

I like the idea that not all witnesses need to be heavily involved in code. I very much appreciate all the community focused witness that have started up in the last 6 months.

I still don't really understand how there can be a Ned and Steemit Inc and then call it decentralised.

it's been a real eye opener to me being here in terms of the challenges and pitfalls of decentralisation. quite an education.

I'm very grateful to people, like yourself, who take he time to communicate with us in ways that even I can understand.

I sincerely hope that @ned not only seriously considers all your points but, also, has the courtesy to respond here, publicly.

What a great post, thank you. I echo almost all of your statements. I am still relatively new here but working in the IT industry, I know how development works and frankly HF20 was an utterly abysmal job of roll out. I hope we can all learn from the process and move forward with more standard protocols for these, mainly proper testing before rolling out otherwise this will always remain a mediocre project and will not achieve the successes it can with the right mindset. Cheers!

"code review", if they (steemit), are expecting a line by line review of proposed code, that is the job of a Quality Assurance Team, (my view only). To me code review is code that has passed QA, and then been handed over to be reviewed. Does it work as expected? A person is given a list of what the code should do, and asked to review the working of the code.

  1. Check sign-in function
    a. Did sign-in function work as expected?
    Yes No (circle answer); if no please describe error received

So a big discussion it seems really needs to be done so that everyone is operating under the same expectations. I am pretty much only a consumer on steemit, and a social entity, not much of a High Quality Blog of information and Ideas, more of a social blogger. (I do believe there is a lot of room for people like myself). The testnet was, or at least how I understood it, (after reading all about HF17), was the test area for the witnesses to Test (review), the programing.

Steemit needs to provide functioning tools if they have expectations of something being tested. It is easy for a programmer to say yes it works as it should, but does it work for non-programmers.

🙋WELL DONE @aggroed ! you will always have my witness vote! As well as @yabapmatt !
I totally agree here:
"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."
And hope it happens soon! upped and resteemed , keep up the great work ! GO STEEM MONSTERS GO!!👿👺👹💀👾👍💁

I don't work for you. You don't work for me. We're here to serve this community.

True gem for decentralized governance. HF20 was a failure, but it could be a success all the top guys like you and other witnesses as well as the Stinc realize the mistake and make everything stronger. Peace.

heheh :)

...to interact with the carbon based life forms.

i hope he read it and actually reply for once!

Please help this Blue Baby Patient, Laine Kharece by upvoting the link below. This is not a scam, we just need your support as part of steemit community. Thank you very much for reading and extending a little help.
.jpg
https://steemit.com/upfundme/@wews/steemit-help-a-blue-baby-patient

I enjoyed the languaging of your post and your clarity about our non-hierarchical relationship to each other in this decentralized governance environment we're in.

From my kind of organizational background, it seems to me that the process of doing hardforks has to be worked out first, and then the role definitions will follow after that. Defining roles without first defining the hardfork process would appear to be much more arbitrary (role definitions and scopes are based on what?) and probably subject to change right away, so the time spent on agreeing upon roles would be wasted.

If we take for example the process of creating a meal. The process is described in steps - we call it a recipe. When we have the recipe written down, we can delegate the various steps to this role or that role (if it's a pizza - someone prepares the dough, someone slices the tomatoes and mushrooms, someone puts the pizza in the furnace and takes it out when ready). We start with the process definition and then the roles follow from that.

I think that is what the first step has to be - what is our process for changing the Steem protocol? I suggested one possible process on @timcliff's post about his witness standards: https://steemit.com/witness-category/@timcliff/timcliff-s-witness-hardfork-approval-standards-v0-1#@borislavzlatanov/re-timcliff-timcliff-s-witness-hardfork-approval-standards-v0-1-20181009t174156887z

I would be curious to hear your thoughts.