From an idea to an upgrade, the Livepeer improvement cycle is clear and simple: write an LIP on Github, foster discussion, put it to a vote, and then the Livepeer team implements it. Here's our look at Livepeer's governance-driven improvement cycle.
- LIP #19: Poll Based Governance (Mar 30, 2020 - Github)
- Livepeer Governance Proposal Voting (May 6, 2020)
- Livepeer Governance in a Nutshell (Apr 10, 2020)
- Governing the World’s Open Video Infrastructure: Livepeer Case Study (Mar 24, 2020)
Livepeer's proposed governance process is simple and useful:
? Someone will propose a change & discuss that idea
✍️ Then they'll draft a Livepeer Improvement Proposal (LIP) in Github
? The writer will foster a discussion that addresses criticisms, revising the LIP
?️ Then they'll launch a poll for LPT stakers to vote on the proposed LIP
▶️ The Livepeer team will include the successful LIP in the next upgrade
If the poll passes the vote, the core team will be expected to execute the changes proposed in the LIP (with exceptions). First we'll look at LIP-19 to illustrate the governance process, then go a bit deeper into the LIP process that's used to propose and discuss a change.
The LIP process will be part of Livepeer's governance process for creating, discussing, and evaluating technical and economic proposals. LIPs will be created in Github to propose new features, collect community input on an issue, and to document design decisions for the Livepeer protocol. Essentially any change to Livepeer should begin as an LIP. What’s an LIP?
A Livepeer Improvement Proposal is a design document that either:
An LIP should provide concise technical specifications and rationale for the proposed feature. Its author is responsible for 1) building community consensus and 2) addressing criticism. The LIP process is clear, and you can skip to that here.
The LIP process begins with a new idea for the Livepeer protocol or community. Ideally the proposer will vet their idea before writing the LIP to gauge interest and get initial feedback. Key public locations for discussions include the issues for the LIP repository, the Livepeer forum, the Livepeer Discord, and the Livepeer subreddit.
After drafting the LIP and addressing community criticisms, the LIP can be the subject of a poll. If LPT stakers vote in favour (simple majority), the Liveeper team will be expected to enact the LIP in the next Livepeer upgrade, with some exceptions.
Notably, this is a new governance process that is being ratified using the process itself via LIP-19, a bundled proposal containing LIPs 15 and 16. There are two ideas here:
Yondon championed the drafting of LIP-19 after the ideas were described in several blog posts. He fostered discussions for LIP-15 here and most notably LIP-16 here. There were also some discussions in the community Discord governance channel and in the governance forum category here, as well as discussion that took place in the most recent Livepeer community call.
Yondon addressed a number of criticisms and made revisions, and then extended the Last Call status to allow for final discussion of LIP-16 before marking its status 'Proposed.'
Now LIP-19 is the subject of a Livepeer poll. If the vote is in favour of LIP-19, the bundled changes will be legitimized and marked Final, and doing that won't require a protocol upgrade. If you want to influence Livepeer changes, you should be involved with the proposal at the earliest possible stage.
LIPs begin by being marked DRAFT and are then open for consideration. Most of the discussion, debate, and questions should occur in the draft phase, during which time the proposer is responsible for fostering this discussion. Interestingly, at this point a poll may optionally be launched to gauge LPT staker sentiment.
When the proposer is satisfied that the LIP has undergone sufficient discussion/iteration, they can request that the LIP be marked with LAST CALL status. If the LIP editors (Livepeer team) are satisfied that all concerns have been addressed, they will approve and merge the proposer's 'Github pull request' to assign Last Call status. Last Call lasts around 10 days. It's the opportunity for publicity, objections, and requests for changes. You can read more about Last Call here.
After Last Call, the LIP is marked PROPOSED, which means it either is or will be the subject of a poll. In other words, anyone can create a poll for a Proposed LIP and that poll will then be voted upon. You can read more about the voting process here.
If a Proposed LIP is rejected in the polling application, it will be assigned the status REJECTED. Those that don't meet quorum will remain as PROPOSED. If a Proposed LIP is passed in the polling application, it will be assigned the status ACCEPTED, whereupon the LIP will be set to be included in a scheduled protocol upgrade. At any point before being accepted, an LIP could be marked ABANDONED if it has either been inactive for an unspecified period of time or if the LIP no longer has a champion.
Once the LIP has been included in a protocol upgrade, the status of the LIP will be marked FINAL.
LIPs should be as focused as possible. Make it a single proposal or idea, keeping in mind that the LIP editor reserves the right to reject LIP unfocused or broad proposals. A draft LIP should first be submitted as a pull request on Github after receiving feedback from the community and refining the technical language around an idea. If approved, the LIP editors (Livepeer team) will assign an LIP number and merge the LIP marked as DRAFT. Once merged, changes to the Draft LIP may be submitted as pull requests until you believe that the LIP is mature enough for the next stage. You can read about the stages above.
1) The preamble header: a title, the author(s), the LIP Type, LIP Status, date created, any dependencies (requires, replaces, or part-of another LIP), and the URL for discussions.
LIP Types (read more here and also note LIP-15)
Standard track - any changes that affect the Livepeer protocol
Informational - general guidelines or information for the Livepeer community
Meta - processes surrounding Livepeer including proposals to change processes
Parameter - an update to protocol contract parameters
2) The Abstract section should provide a concise description of what is being proposed.
3) The Motivation section should describe the goal(s), intent, and limitations of the proposal.
4) The Specification section should detail the syntax, semantics, and key details of what is being proposed.
5) The Specification Rationale section should contextualize the technical choices relative to the Motivation section.
6) The Copyright section should detail any copyright claims or releases.
The LIP author is responsible for building consensus within the community and documenting dissenting opinions. Being part of the community will be an important part of creating a successful proposal.
This article is part of the Livepeer governance education initiative. We want an engaged and competent Livepeer community that participates in an increasingly decentralized governance process–all part of a healthy network that will support the Livepeer Project’s mission to Build The World’s Open Video Infrastructure.
Hopefully you found this useful. Questions? Comments? Feedback is always welcome! I’m on Twitter.