After Hardfork 20, there have been discussions about Steem's governance. This post constitutes my proposal to the Steem community for a governance process that leads to continuous improvement and agreement among the Steem stakeholders.

Throughout this post, I will be using first principles thinking. This means that I will be sticking, as much as possible, to the most fundamental level of how things work. This helps avoid all sorts of language constructs that can cloud our thinking and reduce our available range of solutions.

The Steem Ecosystem & Blockchain Technology

Let's first look at the Steem ecosystem, i.e. the collection of all projects, organizations and people that are utilizing the Steem blockchain. In order to interact with each other on the blockchain, all of these players have to follow the Steem protocol. The Steem protocol describes the rules of the game. Unlike the legal systems of today where there is a need for a court of law to determine whether a given action conforms to the rules, the Steem protocol uses computer code to verify whether a transaction conforms to the rules and it will not allow it to pass unless it completely conforms. That is, the protocol will not allow you to break the rules in the first place. There is no need for a lawyer or a court to interpret whether a person's action conforms to the established rules - this is completely done by the computer. All this so far is something common to all blockchains.

So far, so good. But what if we want to change the rules of the game (the Steem protocol) because we're noticing problems and we think that some other rules will give us better results?

Changing the Rules of the Game

The initial set of rules, or the set of rules at any given point in time, doesn’t seem to be of that much importance. Most discussion happens around whether this set of rules or that set of rules would work better, whereas the topic with the highest impact would be about how we change the rules of the game, and how do we change how we change the rules of the game.

So how do we go about changing the Steem protocol?

Every person's brain generates ideas, i.e. suggestions for change. Some generate more, some less. Changes in the world happen by someone's brain first generating an idea, and this idea eventually becoming a reality. So, in the context of the Steem ecosystem, here is how this process could look:

Generating the idea
↓
Presenting the idea to the community
↓
Reaching enough witness support
↓
Turning the idea into code
↓
Reaching enough witness approval
↓
Implementing the change
↓
Evaluating how well the change performs

Let's look at how each of these steps could happen.

Generating the idea

The first step is to, well, have an idea. Ideas can be generated individually by a given person, or they can be generated collectively by people brainstorming in a room or on platforms like Steemit.

Creativity, problem solving processes, and brainstorming processes all impact what ideas are being generated. The details of those processes are outside the scope of this post. Let's just state that good ideas can bring about solutions to any kind of problem, whether it be scaling or economics or security or anything else.

One other important aspect is about having an accurate understanding of the current state of events as a starting point for generating the idea. One example of this is in medicine, where an inaccurate diagnosis (inaccurate understanding of the current state of events) leads to wrong treatments. Another example: Likely all of us have seen many cases in politics where there was continuous argument about the current state of events - what happened, who did it, when, what are the available resources we can work with, etc., etc. Contrast this with something like a plane crash event - if the investigators find the black box with the data in it, they can largely reconstruct what happened, agree upon it and suggest changes to how planes are built and operated.

Doctors might use a PET scan to get an understanding of what’s happening in someone’s body. With Steem, we have a digital environment where data is generated constantly from every user action. We are swimming in data. How do we make sense of it all?

This is usually done by determining a set of metrics. Finding appropriate metrics allows us to agree on the current state of events (i.e. how well the Steem ecosystem is doing) and it will allow us to check how much any changes to the Steem protocol are leading to better or worse results. Some metrics we might use could be:

• Number of active users (active could mean having made a post/comment or voted in the last 30 days)
• Number of unique daily visits
• Number of active communities (active could mean having at least x posts in the last 30 days)
• Average number of active users per community
• Percentage of active users from all the users
• Percentage of active communities from all the communities
• Percentage of users who are engaging in self-voting
• Percentage of users who have voted for any witness
• STEEM trading volume
• Price of STEEM (in USD, as a ratio to Bitcoin’s price, and the STEEM market cap as a percentage of the combined market cap of all cryptocurrencies)

The above metrics can be continuously changed and adjusted to better measure whatever we consider important. But this data has to be easily accessible by every single Steem user. Every single Steem user is where new ideas come from. So there would have to be a central place where everyone can go and view this statistical data. This would be our collective dashboard.

If we have an appropriate set of metrics, they will tell us a story, they’ll numerically describe what is going on in the ecosystem. They will also give us a baseline. The baseline is required in order for us to know which changes have made an improvement and which have not.

The metrics also reflect our goals. Can we agree on a set of goals and collectively work to pursue them? The more appropriate the metrics are, the better they will tell us how much we are achieving our goals.

To know how well the Steem blockchain is doing, we can also have another set of metrics that measure the technical performance of the blockchain. These technical metrics could include things like:

• Amount of CPU and RAM required to run a full node
• Blockchain downtime
• Required time to replay all the blockchain transactions since the beginning
• Maximum number of transactions per second the blockchain can handle

Presenting the idea to the community

After an idea is formulated, the next step is to present it to the rest of the people who use the Steem blockchain. To streamline things, there can be a template everyone follows when they present their idea. The template could include standard fields that describe how the suggested change is going to work, and possibly a place for images and mockups.

The most common types of ideas will likely be about improving how well we do, as measured by the metrics. In this case, the idea presentation can include a hypothesis which states upfront the expected improvement of a metric. An example hypothesis: Changing the author/curation rewards for posts and comments to a 50/50 ratio will lead to an increase in the number of active users and an increase in the average number of active users per community. This unambiguously (numerically) describes the change to be performed and the expected outcome.

For an idea like Smart Media Tokens (SMTs), what might the hypothesis be? Perhaps something like: Implementing the Smart Media Tokens protocol will lead to an increase in the number of active communities and an increase in the price of STEEM. An increase in the number of active communities would mean that new companies and organizations start utilizing the Steem blockchain (whether by creating their own tokens or not).

Another type of idea may be about gathering more data regarding the current performance of the Steem protocol. An example is Hardfork 20 where data started to be gathered about the computational costs of various operations on Steem. In this case we may want to weigh in the costs and benefits of generating and collecting the additional data. Small-scale experiments can be performed if needed.

And yet another type of idea may be about changing the abovementioned set of metrics that we use to evaluate how well the Steem ecosystem is doing. Changes in the metrics or new metrics may be proposed. In this case we may want to look at the most downstream metrics that we all agree on (perhaps things like price of STEEM and number of active users), and use them to evaluate which upstream metrics seem to be useful indicators. (For example, number of unique daily visits is not an end goal in itself, but is used as an indicator for things like the number of active users, which is closer to an end goal).

There will have to be a single place where all suggested changes can be browsed by everyone. The stage of each suggested change and the history of all work and communication on it will also have to be available at that place.

Reaching enough witness support

In this step, the community engages with the person or group who proposed the idea. As people ask more questions about how the proposed change is going to work, it gets more fleshed out and detailed.

Many ideas will not get traction. Some will. If and when an idea gets enough support from the witnesses, anyone who wants to do the work to implement the idea can have much more confidence that the change will be accepted, provided that the technical implementation meets the witnesses’ standards.

Enough support from witnesses probably means 17 of the top 20 witnesses, as this is the supermajority required to implement any changes to the protocol. In order for everyone to have more clarity, each witness would (after they have asked all their questions) announce their position on the latest version of the proposed change: either a “I would upgrade my node to a software that implements this idea” or “I would NOT upgrade my node to a software that implements this idea”.

A major benefit of this process is that agreement from witnesses is sought before any coding has been done. Because the proposal consists of only words and mockups at this point in time, any changes to it will take much less time to incorporate. Contrast this to the current situation where witnesses are expected to give their approval or disapproval only after all the coding has been done and the release is prepared.

This will also give us information about where the witnesses and the community stand in relation to a given proposal. Further dialog may reveal what evidence they require to change their stance. This way, an experiment can be designed in order to gather the needed data about how the proposed change will perform. SMTs may make designing such experiments and implementing them on a small scale much easier.

Turning the idea into code

After enough witness support is reached, work can begin on doing the development work. In the place where the idea is proposed, there can be a designated field that shows who, if anyone, is working on making it happen. The development work can be done by the idea proposer and/or by anyone else.

Preferably, there would be back-and-forth between the developers and the community as the development work progresses. If implementation questions arise, or aspects of the idea come up that no one thought about before, these can be discussed and fleshed out.

When the development work is done, the developers announce it is ready for testing and approval.

Reaching enough witness approval

This step is about the witnesses evaluating the development work. Does it perform as advertised? Are all technical, coding and security standards met? Etc., etc.

In order for the witnesses and the community to evaluate the new change, it will most likely have to be implemented on a testnet. The testnet is a test blockchain that mimics the real Steem blockchain but all funds and operations on it are not real, so it’s safe to test new changes and for things to break. If the change requires a hardfork, then the hardfork is scheduled and run on the testnet as a part of our testing process.

Everyone can be involved in the testing: users, witnesses and developers. The community collectively tries to find bugs. There could also be bug bounties. All bugs are reported in a central place (such as the Github repository). Bug fixes would usually be performed by the developers who coded the change, but others can also submit fixes, with possible bounties for this as well.

Each witness gives their green light for the proposal implementation to proceed after gaining enough confidence that the software meets their standards and that all bugs have been successfully fixed. We would proceed to the next step only after at least 17 of the top 20 witnesses have given their green light.

There are many ways things can go wrong when implementing any change. The main purpose of testing is to minimize the potential for things going wrong. How we test makes a lot of difference. If our testing process does not protect us from downtime or other undesirable consequences, we may want to make a change to the process - to perhaps add better description of how testing is to be done, or reduce the allowed scope size for any given proposed change.

Implementing the change

This step is about making the change live. If the change requires a hardfork, the hardfork gets scheduled and run on the mainnet (i.e. the live Steem blockchain).

It also seems highly desirable to have a contingency plan - what happens if the mainnet breaks in some unforeseen way? A plan of action could be developed, which would serve to minimize risks of having loss of funds, incorrect economic calculations, or any other undesirable situation.

Evaluating how well the change performs

After the change is live, we monitor the metrics. How well is the change performing? Do we want to keep it as is, or make an adjustment to it, or go in a completely different direction?

Doing the experiment and having the data will often lead to better understanding and insights, so new ideas will be generated, starting the whole process again.

Ultimately, using a governance process like this one, the decision of whether to keep the change or adjust it or go for another approach will be based on data rather than on the opinion of the STEEM holders or the witnesses or the developers. When using data, all these stakeholders can agree on which changes constitute an improvement and which do not. In this type of process, we can move from pushing for our changes and trying to convince everyone else that we’re right to designing experiments to collectively find out what kind of Steem protocol will produce beneficial results for everyone.

---

Now that we’ve taken a look at how each step could be handled, here are some answers to a couple of questions you may be having:

How much time does it take to go through all the steps?

The steps allow for flexibility when it comes to time - going through all steps from idea generation to implementation can be done very quickly (in a matter of hours), or it can take a long time (weeks, months, years). This flexibility allows for not breaking the governance process when there are emergency fixes that have to be implemented.

What is the approximate size of a proposal?

One of the aims is to use the least amount of time and effort to check how well an idea will perform. Usually, this means looking at the currently available data and doing surveys before even beginning to code anything. And then creating a Minimum Viable Product. Through discussions between the idea proposer and the community, someone may think of ways to reduce the scope of the Minimum Viable Product while still keeping it a viable representation of the idea. Over time, after some iterations and having data on our hands, a good scope size can be found somewhere on the spectrum from very small and frequent changes to large and infrequent changes.

---

OK, let’s do some recap.

Continuous Improvement

Instead of thinking about this or that governance process as the best one, the emphasis here is on getting to continuously better results, as measured by our metrics. The set of steps of the governance process would be continuously adjusted.

When there are suggested changes to the governance process, the witnesses would probably be the ones deciding on which changes get implemented. The evaluation of how well a change to the governance process performs is done in the same way - by looking at the metrics.

How to start with this

If there is agreement that some process similar to the above is desirable, then the first step would be to agree on an initial set of metrics. After that, we would have to create a dashboard where everyone can go to get a better understanding of the state of the Steem ecosystem. (The thing most similar to what I’m describing would be this Trello Dashboard project which I’ve worked on: https://github.com/thevenusproject/trello-dashboard )

The next step after that would be to agree on something like the above set of steps, or on some different governance process, and then perhaps create a Github repository where the steps are described in text format. Changes to the governance process can then be implemented through pull requests.

If needed, at a future point the steps can be turned into code and an app, which can be used by the community to govern itself. But for now, doing it as just text allows us to start quickly and, most importantly, make changes very easily.

The step after that could be to create and agree upon a template for presenting ideas to the community, and decide on which platform we will use for presenting the ideas (some Steem app, or on Github, or on a platform like UserVoice, or some other platform).

As I haven’t developed anything for the Steem blockchain, I may have a limited understanding of some of the technical aspects required to operate it, but I imagine the overall process I’m suggesting is clear. I’m grateful you’ve taken the time to read this proposal and I’m hoping you are willing to explore it with me further.