This is a long one, but after a lot of discussions, both internal and outside our company, I feel it is important. So please take the time to read and give your feedback. Like the site itself, this is a starting point for discussion.
Intro
Yesterday we launched phase 1 of the Secret Network’s new website. I also published a forum post for which this is a companion. If you haven’t seen it yet please visit The Secret Network Website: Phase 1 Completed and leave feedback, it is really important.
This post is about where we go from here. So far the site was built privately by Stake or Die! in consultation with the Secret Foundation. This was done purposely to get us to a fully functioning starting point at a speed that would have been impractical with a fully collaborative open process. Now that Phase 1 is over, it is time to bring everyone into the fold. The question is how to do this in the most productive sustainable way possible.
What follows is a process designed by myself and Stake or Die!. Like the website itself it is rough, but also comprehensive. We feel that a full plan is the best place to start the conversation so that we can refine the idea as quickly as possible and start working towards the future. Thanks in advance for feedback. Here is the our proposal for a process for building the website going forward.
Proposal
In order to grow and evolve the website needs constant updates from big and small. Depending on the size and scope of the updates, the approach will be different. Broadly speaking, there are three categories with their own processes:
- Bug Fixes
- Content Updates
- Design / Functionality Updates
Bug Fixes
For bug fixes the process is pretty straightforward and should begin as soon as possible. Bugs can be pointed out by anyone, at any time, and fixes can be made by anyone. Using the contribution guidelines on Enigma’s Github (here), we encourage anyone to submit pull a request that they think fits in this category. Different sections of the site will have different moderators so that content expertise is prioritized. This is all pretty straightforward and can be ironed out quickly.
Content Updates
This includes things like blog posts, new written sections of pages, added links to collections of links that already exist, etc etc. Basically, anything that is adding to parts of the site that are already in place. These changes will be made similarly to the bug fixes, but will need additional approval by the new Website Committee. Some approval will be in the form of positional approval. For instance the foundation will be able to add new Blog posts regularly as a function of its position.
Everything else needs approval on a weekly basis by the website committee. Each committee will bring such changes to the Website Committee for approval. Most will be approved easily, but because this is new, we want a second pair of eyes to ensure that further community discussions aren’t needed.
Design / Functionality Updates
These are core changes that will add or change the fundamental look, feel, and/or structure of the site. They include things like changes to the site map, changes to the brand guidelines, new illustrations or animations, new sections with new components etc etc. We view these types of changes as falling under the general heading of “Big Changes”. The rest of this post is about Big Changes.
It is my belief that for a number of reasons, big changes need a fairly strict, systematic process. First off, it is possible, even likely, that we will need to look for outside work to make big changes and that will require compensation. Secondly these changes are by their nature fundamental and as such could be controversial. Third, they will take time and bandwidth to execute and thus to be prioritized and scheduled. Finally, for the previous reasons and others, big changes will lend themselves to, for lack of a better word, “red tape”. We want to grow this thing quickly and to do that we need to avoid making constant course corrections during execution. That is a recipe for inaction.
So I would like to propose a system that, for ease of reference as well as totally unnecessary grandiosity, I have named the Governable Community Design Process or GCDP. It isn’t that complicated, but I like giving it a name 
. So what is it exactly?
GCDP is a system designed to aggregate and filter broad community input into actionable initiatives that can be completed in a timely manner and then improved upon where necessary. It has 5 steps
- Community - Input
- Committees - Recommendations
- Website Committee - Prioritized Initiatives
- Foundation / Community Pool - Approved Work Plan
- Execution
Here is a simple diagram that shows the stakeholders in each step:
The most obvious thing that stands out here is the Website Committee. So I want to briefly introduce that.
Website Committee
In order to focus efforts and speed up results we need a representative body that can push the go button when it needs to be pushed. So today we are announcing the formation of the Website Committee. The Website Committee is an invite only committee composed of representatives of the current committees. Its job is to manage the GCDP. All committee representatives will have equal footing except the design committee representative who will have the final word in case of disagreements.
The design committee:
This is a new committee also that is looking for members.
We need people who have experience in many forms of design.
Examples: graphic design, systems design, educational design etc
If you are interested, please make yourself know on Discord.
Why is the design committee the lead?
The word design may bring to mind only artistic notions such as color or layout etc, but we mean it in a much broader sense. Design in the sense of the organization of outward facing content. In other words its job is to take work the community is doing and show it to the public in the best way possible. The website is the most prominent stage for this as such it will be the final arbiter.
So how will this work in progress?
In Github, a kanban board will be maintained with columns for each of the five steps. This will be the map of the process.
Feedback
At any point anyone who wants to can propose ideas in the form of forum posts. An example may be something like a post titled: “I would like there to be an animated infographic that illustrates Smart Contract execution.” The post should be thoughtful, focused, and actionable. By that I mean it should at least suggest the need for a concrete update. Each of these posts will be added as a task to the feedback column of the kanban board and with any luck a broad community discussion will ensue.
Recommendations
Each week committees will devote some time to addressing feedback that they feel fits within their domain. In this case the education committee may decide they like they want to talk about the merits of the idea. And let’s say they agree and want it to move to the Website Committee. They will organize their thoughts taking ideas where appropriate from the broader community discussion and prepare to bring it up at the weekly website Committee meeting. The task will at this point be moved to the 2nd column.
Prioritized Initiatives
At the weekly Website Committee meeting, representatives will bring up tasks they want to be completed and make their case for it. In this case the Education committee would say, we think the highest priority for us is this infographic, and we think it should live on a new page under the development page. After discussion the Website Committee will then update the ordered list of prioritized initiatives. The committee will also decide what approval mechanism they think best fits the task: foundation or on-chain proposal. The task moves to the 3rd column. Waiting for approval to be considered.
Approval
The Website Committee then will come up with a plan to get approval. Let’s assume for this the committee thinks the foundation is the right path. If the foundation then agrees to consider it, the task will move to the 4th column. The foundation and the Website Committee will figure out the right plan to execute. In this case maybe the original post had a list of artists who do this type of thing well and one artist was a clear favorite. The foundation would then reach out to the artist and agree on a price. If all goes well funding will be approved and the work begins.
Execution
The task moves to the 5th column. This last step will be different for each update. But for this example let’s say a member of the education committee and a member of the design committee volunteer to work with the artist to get the work done. If funded by the foundation, foundation members would also be involved. When completed, it will be approved by the Website Committee and if approved pushed to the site.
Re-Feedback
The task moves back to the feedback column marked as completed, a forum post goes up, and the process starts over again.
Conclusion
That is it. GCDP is our proposal of how to move forward into the future in a sustainable way that allows broad participation but also ensures tangible timely results. We look forward to feedback on this process and hope it can be one of the first decisions we make on this website as community, together.
One final note, from now until the 20th of November, development of this, or the improved version of this, process will be a major goal for Stake or Die! At the same time we need to remain active and be making improvements in line with our Phase 2 commitments. As such some improvements may short cut this process leaning more heavily for now on committee recommendations and foundation direction. In other words, assuming this process will be the process, it will not be fully realized until after the 20th.