This Charter outlines the structure and responsibilities of the Developer Advisory Board and its participants. It is authored and maintained by the Optimism Developer Advisory Board.
This is the Season 7 Charter, which supersedes and replaces the Charters of all previous Seasons.
The Developer Advisory Board exists to provide technical expertise across the Optimism Collective. This leads us to two overarching goals:
- Support the Optimism community through important technical decisions, such as protocol upgrades.
- Ensure that funding for technical projects is allocated in a way that best advances the goals of the Collective.
- The members of each Developer Advisory Board subcommittee will be elected by the Token House at the start of each Season.
- After the election is complete, the members of the Devleoper Advisory Board will perform an internal vote to assign the additional internal roles.
- Representatives may serve on one subcommittee and have up to two additional internal roles per Season.
- There are no term limits for representatives, but they may be implemented in the future if the need arises.
The Lead is responsible for ensuring that the Developer Advisory Board is both meeting its current objectives and finding opportunities to further support the Collective. This includes:
- (a) leading all board meetings and internal decisions.
- (b) overseeing the decisions and feedback of all subcommittees.
- (c) leading board discussions on approving protocol upgrades, and communicating these decisions (along with helpful voting context) to the community.
- (d) act as the tiebreaker for the Audit subcommittee and Foundation Mission subcommittee if the members disagree.
- (e) collaborating with other Council Leads to find opportunities to provide support across the collective.
- (f) tracking KPIs and drafting the Season 7 retrospective at the end of the season.
Members are elected into one of three subcommittees. Each subcommittee is responsible for working on a different type of Mission (Foundation, Governance, Audit). The Token House will elect the members to each of these subcommittees based on their expertise and skills.
- The Audit Mission subcommittee (2 members) is responsible for selecting applicants to provide subsidized audits for.
- The Governance Mission subcommittee (3 members) works with the Grants Council to provide technical feedback on all Mission applicants.
- The Foundation Mission subcommittee (2 members, plus the Lead) is responsible for selecting which teams are chosen to fulfill the Foundation Missions.
- The OP Labs Representative (1 member) floats between these teams, providing support and insight into OP Labs' roadmap and perspective.
The members of these subcommittees exist with the mandate of ensuring that the best possible applicants are selected for each Mission. This means they are responsible for:
- (a) providing support to potential applicants to drive more high quality applications,
- (b) supporting the evaluation of applications as requires by their subcommittee (either making selections or providing feedback).
In addition to the subcommittee responsibilities, there are two additional roles that individual Developer Advisory Board members will take on. These roles will be voted on internally by the Developer Advisory Board and include: Ops Lead and Mission Scouts.
- The Ops Lead (1 member) is responsibile for managing the operations of the board, including:
- (a) improving the IOPs
- (b) scheduling meetings
- (c) interfacing with other Councils
- (d) organizing tools and processes for the DAB to perform its duties
- (e) looking for any other opportunities to make changes that will keep the DAB’s efforts focused and effective
- The Mission Scouts (2 members) fill the additional responsibility of crafting Missions, which requires:
- (a) deeply understand the OP Labs roadmap, and thinking creatively about missing gaps that Missions could fill,
- (b) specifically, stay closely on top of interop developments, including protocol level changes and products being built,
- (c) conceptualizing, getting consensus on, drafting, and posting the ongoing Foundation Missions, and
- (d) working with the Grants Council to ensure their Mission process takes into account the specific technical outcomes that would most support the Collective.
- If a member wishes to resign before the end of their term, they must communicate this change to the Lead at least 7 days prior to this change taking effect.
- Their position will be offered to the non-elected candidate who received the most votes in the Token House election. If this individual is no longer available or interested, we will continue down the list of candidates in order of votes received. If no suitable candidate can be found, the Lead may appoint a replacement for the remainder of the term.
- The Lead will then adjust quorum as needed and communicate the change through the structure’s Communication Thread.
- All Developer Advisory Board members are subject to Representative Removal as outlined in the Operating Manual. Removal votes will occur before the end of the next voting cycle. A contingent vote for their replacement on the Council will run in the same voting cycle. Please see Representative Structure Framework for additional details about edge cases related to removal.
- All representatives may be removed from their position for failing to uphold the responsibilities outlined in the relevant Charter or for failing to act with honesty, integrity, and transparency. If there is a vote to remove a representative, the Lead, or a simple majority of the remaining membership, may appoint a replacement for the remainder of the term.
- The Developer Advisory Board will conduct a retrospective at the end of term which will be posted to the forum by the last day of the term.
- While persistent structures will be assumed to be renewed each Season, delegates may submit Dissolution Proposals if they believe a persistent structure is no longer fulfilling its mandate and should be discontinued.
A Proposed Budget, linking to this Charter, will be proposed by each prospective Lead, subject to approval by governance. The Lead may propose a budget that contains variable rewards for members, provided that the evaluation algorithm for rewards is approved by a simple majority of members by the end of the first month of the term.
The canonical version of Charters for persistent structures will be published to GitHub. Any material updates to the Charter will be reflected with a new version number at the top of this document, at which point the updated version will go into effect.
This Charter must seek governance approval for changes to the mandate, scope, or budget approved by Optimism Governance.
It should finally be reiterated that the role of all structures are intended to be progressively and programmatically reduced over time, as its functionalities are no longer needed or can be effectively managed by other means. Ultimately, it is the goal of the Collective to reach a state of protocol and governance reliability that allows for the full and final dissolution of any non-essential structures.