Developer Advisory Board: Internal Operating Procedures

brockelmore - No Role
Jan. 11, 2024, 11:52 a.m.

The Developer Advisory Board has agreed upon our internal operating procedures. We share these procedures with the Optimism community to provide transparency on how decisions are made with regards to our mandate. To read more about our mandate, see the introduction here 4 . In short, we, the board, will assess technical aspects of Delegate Mission Requests, Mission Applications, and completion of technical milestones. This document details the decision making process for those assessments. Members of the board can be reached in the Optimism discord in channel #developer-advisory-board under the Commissions & Councils tag Alternatively, you can reach the board at developeradvisoryboard@optimism.io. Internal Procedures The internal procedures in this document govern the activities of the Developer Advisory Board (DAB). The document sets forth the processes the DAB will follow in order to assess and approve Delegate Mission Requests, Mission Applications under Intent # 1 , and technical milestone completion. Apart from the strict mandate of assessment and approvals, the DAB aims to provide general technical advisory to the Grants Council. This will be on an “as able” basis, and may extend to Delegate Mission Requests generation, Mission Applications outside intent # 1 , and more. There are effectively 3 work periods for the DAB: Delegate Mission Request Assessment, Mission Application Assessment for voting cycle # 20 , and Mission Application Assessment for voting cycle # 22 . The Developer Advisory Board will have a meeting every 3 weeks. An agenda will be sent out prior to the call, and minutes will be published. Grants Council members are encouraged to join. Much of the internal board communication may occur on telegram. Delegate Mission Request Assessment Procedure Each board member is to review all Delegate Mission Requests (DMRs) under Intent # 1 . The ultimate goal is to come to consensus on technical viability, provide feedback, and approve or deny a DMR. DMR Assessment Cycle Procedure The Cycle Procedure is set forth in detail in sections that follow. The DMR Assessment Period will last approximately one month, ending on February 7 , 2024 During the DMR Assessment Period, the DAB will have one objective: approval or denial for each Delegate Mission Requests under Intent # 1 . Objective 1 - Approve or Deny each DMR The DAB will publish final approvals with justifications by the last day of the DMR Assessment Period. Assessment of a DMR under Intent # 1 should consider the following: Does this mission meaningfully progress the Optimism ecosystem towards technical decentralization? Is this mission technically feasible on a reasonable timeline? Are the success criteria indicative of actual success? Can the suggested solution be improved? Milestones: Will the milestones accurately track progress? Can they be gamed? How can the milestones be improved? Etc. A public rubric may be created to encapsulate these and other questions for future use by the Developer Advisory Board Communication intended for public and DMR proposer consumption should occur on the forum post containing the draft - correspondence with other board members can occur elsewhere A vote can occur either on the forum post or via internal board communication, but outcome and justification must be posted publicly on the forum post The outcome of the vote should be accompanied by breakdown of how many votes each option received e.g.: Approved: 2 Not Approved: 3 Abstained: 2 Mission Application Assessment Procedure For Mission Applications, the Developer Advisory Board will review and work with the Grants Council on the technical merits of the applications, as well as communicate with applicants to provide feedback. should strive to communicate with applicants to provide feedback. The Review & Feedback Period will last three weeks. The Review & Feedback Period will end: Voting Cycle 20 : March 27 , 2024 Voting Cycle 22 : May 8 , 2024 The Review & Feedback Period has three objectives: ( 1 ) Review; ( 2 ) Applicant feedback; ( 3 ) Grants Council Advising. Objective 1 - Review Each member is expected to be familiar with all applications to facilitate discussion No less than 3 members will review each application and be intimately familiar with it Board members may volunteer to be a reviewer, and if no, or too few, volunteers come forward, the board lead may assign members All members should know high-level details of each application Given the potential for wide-ranging technical intricacies, a rubric for technical feasibility may not be applicable. However, the following should be taken into consideration during review of a Mission Application: Light review of previous work Does the applicant display a history of work in the field? If the applicant is a company or team, review of team members may be required Apart from work in the specific field, what comparable fields has the applicant worked on? What have the outcomes of that work been? Proposed Solution review Does the proposed solution address the DMR? What parts of the stack are possible today and what parts need research and development? (e.g. extending EVM/op-geth/op-reth versus improvements to zero-knowledge proving time) Does the solution have any technical demerits, including but not limited to: Theoretically impossible Technical risk Missing design element High complexity, low maintainability Security and or mechanism flaw Antithetical to Intent # 1 (by design or accident) Does the solution have any technical merits, including but not limited to: Novel simplicity Improved expected performance Ease of integration Execution/Milestone Plan review Consider any points of development that you foresee as potentially troublesome Evaluate timelines - do they seem reasonable? Is the milestone plan missing parts of the solution? Miscellaneous Is there some other factor that makes this applicant more or less likely to succeed on a technical basis? Objective 2 - Applicant Feedback One member of the board will be the point of contact for an applicant to provide feedback Board members may volunteer to be the point of contact, and if no volunteers come forward, the board lead may assign someone Developer Advisory Board members are encouraged to engage with applicants to gain clarity on implementation details, previous work, etc. If there are technical demerits, communication with the applicant should occur to provide transparency both to the applicant and the wider Optimism ecosystem as to the reasoning behind the board’s recommendations Object 3 - Grants Council Advising Internally, board members will communicate about applications and come to consensus on application frontrunners and justifications In the case of unanimous agreement amongst reviewers of applications for a DMR, the reviewers should write a justification for their recommendation In case of contention, other members should go deeper into the applications and all members are to ranked-choice vote on their recommendation In the case where no consensus can be reached, the Lead will decide the recommendations and communicate that no strong consensus has been reached to the Grants Council Members should be in communication with the Grants Council to facilitate sharing of knowledge, answer questions, and provide their recommendations on Mission Applications A meeting is to be held between participating members of the Grants Council and the Developer Advisory Board in the last 3 days of the cycle where: Presentation of applicant frontrunners and justifications should be discussed DAB members should be prepared to answer questions on applications from Grants Council members In addition to this “final recommendation” meeting, ongoing communication during the voting period will occur. This communication can be used to facilitate additional advising from the DAB to the Grants Council for Mission Applications outside Intent # 1 . For Mission Applications outside of Intent # 1 , the Grants Council should proactively reach out if technical advisory is requested If any DAB member wishes to provide technical advisory of a non-Intent # 1 , they may reach out to the Grants Council Milestone Assessment Procedure Milestones for accepted Mission Applications require assessment as to their completion. This completion can determine whether the applicant receives payments or not. The Milestone Assessment Period has one objective: ( 1 ) Review work-product; Objective 1 - Review Work-product Prior to milestone-based disbursement At least 3 members of the board must review the work product and evaluate if the milestone has been reached If this is functionality benchmark: Does the provided work-product meet the criteria of the milestone? (Does the code run?) If this is a specification document: Does the specification meet the original goals? A “no” to either of the evaluation criteria above should be brought to the Board Lead and they will bring it to the Grants Council for further deliberation A “yes” should be communicated to signal the board’s approval Contention or questions around completion will be brought to the Grants Council for further deliberation Final Developer Advisory Board Communications A summary of the Developer Advisory Board’s work and recommendations will be posted on the forum after the Delegate Mission Request process and each Mission Application process. Delegate Mission Request refusals (if applicable), Application recommendations and justification summaries, should be expected to be part of this summary. As some work will be ad-hoc advisory, that work may not appear in this summary. DAB meeting minutes will also be linked in this post.

The post outlines the internal operating procedures of the Developer Advisory Board (DAB) within the Optimism community, focusing on assessing and approving Delegate Mission Requests, Mission Applications, and technical milestones. It details the decision-making processes, work periods, and assessment procedures for DMRs and Mission Applications, emphasizing transparency and communication within the board. Additionally, it explains the roles and responsibilities of board members, review criteria, communication methods, and interaction with the Grants Council. The post concludes with details on milestone assessments and communication of DAB recommendations to the community.

Likes: 6 Replies: 0

Likers: DevRose, Gonna.eth, Axel_T, Omarsin, FractalVisions, Harper

No replies yet.
brockelmore - No Role
Jan. 11, 2024, 11:52 a.m.

The Developer Advisory Board has agreed upon our internal operating procedures. We share these proc… The Developer Advisory Board has agreed upon our internal operating procedures. We share these procedures with the Optimism community to provide transparency on how decisions are made with regards to our mandate. To read more about our mandate, see the introduction here. In short, we, the board, will assess technical aspects of Delegate Mission Requests, Mission Applications, and completion of technical milestones. This document details the decision making process for those assessments. Members of the board can be reached in the Optimism discord in channel #developer-advisory-board under the Commissions & Councils tag Alternatively, you can reach the board at developeradvisoryboard@optimism.io. Internal Procedures The internal procedures in this document govern the activities of the Developer Advisory Board (DAB). The document sets forth the processes the DAB will follow in order to assess and approve Delegate Mission Requests, Mission Applications under Intent # 1 , and technical milestone completion. Apart from the strict mandate of assessment and approvals, the DAB aims to provide general technical advisory to the Grants Council. This will be on an “as able” basis, and may extend to Delegate Mission Requests generation, Mission Applications outside intent # 1 , and more. There are effectively 3 work periods for the DAB: Delegate Mission Request Assessment, Mission Application Assessment for voting cycle # 20 , and Mission Application Assessment for voting cycle # 22 . The Developer Advisory Board will have a meeting every 3 weeks. An agenda will be sent out prior to the call, and minutes will be published. Grants Council members are encouraged to join. Much of the internal board communication may occur on telegram. Delegate Mission Request Assessment Procedure Each board member is to review all Delegate Mission Requests (DMRs) under Intent # 1 . The ultimate goal is to come to consensus on technical viability, provide feedback, and approve or deny a DMR. DMR Assessment Cycle Procedure The Cycle Procedure is set forth in detail in sections that follow. The DMR Assessment Period will last approximately one month, ending on February 7 , 2024 During the DMR Assessment Period, the DAB will have one objective: approval or denial for each Delegate Mission Requests under Intent # 1 . Objective 1 - Approve or Deny each DMR The DAB will publish final approvals with justifications by the last day of the DMR Assessment Period. Assessment of a DMR under Intent # 1 should consider the following: Does this mission meaningfully progress the Optimism ecosystem towards technical decentralization? Is this mission technically feasible on a reasonable timeline? Are the success criteria indicative of actual success? Can the suggested solution be improved? Milestones: Will the milestones accurately track progress? Can they be gamed? How can the milestones be improved? Etc. A public rubric may be created to encapsulate these and other questions for future use by the Developer Advisory Board Communication intended for public and DMR proposer consumption should occur on the forum post containing the draft - correspondence with other board members can occur elsewhere A vote can occur either on the forum post or via internal board communication, but outcome and justification must be posted publicly on the forum post The outcome of the vote should be accompanied by breakdown of how many votes each option received e.g.: Approved: 2 Not Approved: 3 Abstained: 2 Mission Application Assessment Procedure For Mission Applications, the Developer Advisory Board will review and work with the Grants Council on the technical merits of the applications, as well as communicate with applicants to provide feedback. should strive to communicate with applicants to provide feedback. The Review & Feedback Period will last three weeks. The Review & Feedback Period will end: Voting Cycle 20 : March 27 , 2024 Voting Cycle 22 : May 8 , 2024 The Review & Feedback Period has three objectives: ( 1 ) Review; ( 2 ) Applicant feedback; ( 3 ) Grants Council Advising. Objective 1 - Review Each member is expected to be familiar with all applications to facilitate discussion No less than 3 members will review each application and be intimately familiar with it Board members may volunteer to be a reviewer, and if no, or too few, volunteers come forward, the board lead may assign members All members should know high-level details of each application Given the potential for wide-ranging technical intricacies, a rubric for technical feasibility may not be applicable. However, the following should be taken into consideration during review of a Mission Application: Light review of previous work Does the applicant display a history of work in the field? If the applicant is a company or team, review of team members may be required Apart from work in the specific field, what comparable fields has the applicant worked on? What have the outcomes of that work been? Proposed Solution review Does the proposed solution address the DMR? What parts of the stack are possible today and what parts need research and development? (e.g. extending EVM/op-geth/op-reth versus improvements to zero-knowledge proving time) Does the solution have any technical demerits, including but not limited to: Theoretically impossible Technical risk Missing design element High complexity, low maintainability Security and or mechanism flaw Antithetical to Intent # 1 (by design or accident) Does the solution have any technical merits, including but not limited to: Novel simplicity Improved expected performance Ease of integration Execution/Milestone Plan review Consider any points of development that you foresee as potentially troublesome Evaluate timelines - do they seem reasonable? Is the milestone plan missing parts of the solution? Miscellaneous Is there some other factor that makes this applicant more or less likely to succeed on a technical basis? Objective 2 - Applicant Feedback One member of the board will be the point of contact for an applicant to provide feedback Board members may volunteer to be the point of contact, and if no volunteers come forward, the board lead may assign someone Developer Advisory Board members are encouraged to engage with applicants to gain clarity on implementation details, previous work, etc. If there are technical demerits, communication with the applicant should occur to provide transparency both to the applicant and the wider Optimism ecosystem as to the reasoning behind the board’s recommendations Object 3 - Grants Council Advising Internally, board members will communicate about applications and come to consensus on application frontrunners and justifications In the case of unanimous agreement amongst reviewers of applications for a DMR, the reviewers should write a justification for their recommendation In case of contention, other members should go deeper into the applications and all members are to ranked-choice vote on their recommendation In the case where no consensus can be reached, the Lead will decide the recommendations and communicate that no strong consensus has been reached to the Grants Council Members should be in communication with the Grants Council to facilitate sharing of knowledge, answer questions, and provide their recommendations on Mission Applications A meeting is to be held between participating members of the Grants Council and the Developer Advisory Board in the last 3 days of the cycle where: Presentation of applicant frontrunners and justifications should be discussed DAB members should be prepared to answer questions on applications from Grants Council members In addition to this “final recommendation” meeting, ongoing communication during the voting period will occur. This communication can be used to facilitate additional advising from the DAB to the Grants Council for Mission Applications outside Intent # 1 . For Mission Applications outside of Intent # 1 , the Grants Council should proactively reach out if technical advisory is requested If any DAB member wishes to provide technical advisory of a non-Intent # 1 , they may reach out to the Grants Council Milestone Assessment Procedure Milestones for accepted Mission Applications require assessment as to their completion. This completion can determine whether the applicant receives payments or not. The Milestone Assessment Period has one objective: ( 1 ) Review work-product; Objective 1 - Review Work-product Prior to milestone-based disbursement At least 3 members of the board must review the work product and evaluate if the milestone has been reached If this is functionality benchmark: Does the provided work-product meet the criteria of the milestone? (Does the code run?) If this is a specification document: Does the specification meet the original goals? A “no” to either of the evaluation criteria above should be brought to the Board Lead and they will bring it to the Grants Council for further deliberation A “yes” should be communicated to signal the board’s approval Contention or questions around completion will be brought to the Grants Council for further deliberation Final Developer Advisory Board Communications A summary of the Developer Advisory Board’s work and recommendations will be posted on the forum after the Delegate Mission Request process and each Mission Application process. Delegate Mission Request refusals (if applicable), Application recommendations and justification summaries, should be expected to be part of this summary. As some work will be ad-hoc advisory, that work may not appear in this summary. DAB meeting minutes will also be linked in this post.

Likes: 6 Replies: 0

Likers: DevRose, Gonna.eth, Axel_T, Omarsin, FractalVisions, Harper

No replies yet.
brockelmore - No Role
Jan. 11, 2024, 4:52 p.m.

The Developer Advisory Board has agreed upon our internal operating procedures. We share these proc… The Developer Advisory Board has agreed upon our internal operating procedures. We share these procedures with the Optimism community to provide transparency on how decisions are made with regards to our mandate. To read more about our mandate, see the introduction here 1 . In short, we, the board, will assess technical aspects of Delegate Mission Requests, Mission Applications, and completion of technical milestones. This document details the decision making process for those assessments. Members of the board can be reached in the Optimism discord in channel #developer-advisory-board under the Commissions & Councils tag Alternatively, you can reach the board at developeradvisoryboard@optimism.io. Internal Procedures The internal procedures in this document govern the activities of the Developer Advisory Board (DAB). The document sets forth the processes the DAB will follow in order to assess and approve Delegate Mission Requests, Mission Applications under Intent # 1 , and technical milestone completion. Apart from the strict mandate of assessment and approvals, the DAB aims to provide general technical advisory to the Grants Council. This will be on an “as able” basis, and may extend to Delegate Mission Requests generation, Mission Applications outside intent # 1 , and more. There are effectively 3 work periods for the DAB: Delegate Mission Request Assessment, Mission Application Assessment for voting cycle # 20 , and Mission Application Assessment for voting cycle # 22 . The Developer Advisory Board will have a meeting every 3 weeks. An agenda will be sent out prior to the call, and minutes will be published. Grants Council members are encouraged to join. Much of the internal board communication may occur on telegram. Delegate Mission Request Assessment Procedure Each board member is to review all Delegate Mission Requests (DMRs) under Intent # 1 . The ultimate goal is to come to consensus on technical viability, provide feedback, and approve or deny a DMR. DMR Assessment Cycle Procedure The Cycle Procedure is set forth in detail in sections that follow. The DMR Assessment Period will last approximately one month, ending on February 7 , 2024 During the DMR Assessment Period, the DAB will have one objective: approval or denial for each Delegate Mission Requests under Intent # 1 . Objective 1 - Approve or Deny each DMR The DAB will publish final approvals with justifications by the last day of the DMR Assessment Period. Assessment of a DMR under Intent # 1 should consider the following: Does this mission meaningfully progress the Optimism ecosystem towards technical decentralization? Is this mission technically feasible on a reasonable timeline? Are the success criteria indicative of actual success? Can the suggested solution be improved? Milestones: Will the milestones accurately track progress? Can they be gamed? How can the milestones be improved? Etc. A public rubric may be created to encapsulate these and other questions for future use by the Developer Advisory Board Communication intended for public and DMR proposer consumption should occur on the forum post containing the draft - correspondence with other board members can occur elsewhere A vote can occur either on the forum post or via internal board communication, but outcome and justification must be posted publicly on the forum post The outcome of the vote should be accompanied by breakdown of how many votes each option received e.g.: Approved: 2 Not Approved: 3 Abstained: 2 Mission Application Assessment Procedure For Mission Applications, the Developer Advisory Board will review and work with the Grants Council on the technical merits of the applications, as well as communicate with applicants to provide feedback. should strive to communicate with applicants to provide feedback. The Review & Feedback Period will last three weeks. The Review & Feedback Period will end: Voting Cycle 20 : March 27 , 2024 Voting Cycle 22 : May 8 , 2024 The Review & Feedback Period has three objectives: ( 1 ) Review; ( 2 ) Applicant feedback; ( 3 ) Grants Council Advising. Objective 1 - Review Each member is expected to be familiar with all applications to facilitate discussion No less than 3 members will review each application and be intimately familiar with it Board members may volunteer to be a reviewer, and if no, or too few, volunteers come forward, the board lead may assign members All members should know high-level details of each application Given the potential for wide-ranging technical intricacies, a rubric for technical feasibility may not be applicable. However, the following should be taken into consideration during review of a Mission Application: Light review of previous work Does the applicant display a history of work in the field? If the applicant is a company or team, review of team members may be required Apart from work in the specific field, what comparable fields has the applicant worked on? What have the outcomes of that work been? Proposed Solution review Does the proposed solution address the DMR? What parts of the stack are possible today and what parts need research and development? (e.g. extending EVM/op-geth/op-reth versus improvements to zero-knowledge proving time) Does the solution have any technical demerits, including but not limited to: Theoretically impossible Technical risk Missing design element High complexity, low maintainability Security and or mechanism flaw Antithetical to Intent # 1 (by design or accident) Does the solution have any technical merits, including but not limited to: Novel simplicity Improved expected performance Ease of integration Execution/Milestone Plan review Consider any points of development that you foresee as potentially troublesome Evaluate timelines - do they seem reasonable? Is the milestone plan missing parts of the solution? Miscellaneous Is there some other factor that makes this applicant more or less likely to succeed on a technical basis? Objective 2 - Applicant Feedback One member of the board will be the point of contact for an applicant to provide feedback Board members may volunteer to be the point of contact, and if no volunteers come forward, the board lead may assign someone Developer Advisory Board members are encouraged to engage with applicants to gain clarity on implementation details, previous work, etc. If there are technical demerits, communication with the applicant should occur to provide transparency both to the applicant and the wider Optimism ecosystem as to the reasoning behind the board’s recommendations Object 3 - Grants Council Advising Internally, board members will communicate about applications and come to consensus on application frontrunners and justifications In the case of unanimous agreement amongst reviewers of applications for a DMR, the reviewers should write a justification for their recommendation In case of contention, other members should go deeper into the applications and all members are to ranked-choice vote on their recommendation In the case where no consensus can be reached, the Lead will decide the recommendations and communicate that no strong consensus has been reached to the Grants Council Members should be in communication with the Grants Council to facilitate sharing of knowledge, answer questions, and provide their recommendations on Mission Applications A meeting is to be held between participating members of the Grants Council and the Developer Advisory Board in the last 3 days of the cycle where: Presentation of applicant frontrunners and justifications should be discussed DAB members should be prepared to answer questions on applications from Grants Council members In addition to this “final recommendation” meeting, ongoing communication during the voting period will occur. This communication can be used to facilitate additional advising from the DAB to the Grants Council for Mission Applications outside Intent # 1 . For Mission Applications outside of Intent # 1 , the Grants Council should proactively reach out if technical advisory is requested If any DAB member wishes to provide technical advisory of a non-Intent # 1 , they may reach out to the Grants Council Milestone Assessment Procedure Milestones for accepted Mission Applications require assessment as to their completion. This completion can determine whether the applicant receives payments or not. The Milestone Assessment Period has one objective: ( 1 ) Review work-product; Objective 1 - Review Work-product Prior to milestone-based disbursement At least 3 members of the board must review the work product and evaluate if the milestone has been reached If this is functionality benchmark: Does the provided work-product meet the criteria of the milestone? (Does the code run?) If this is a specification document: Does the specification meet the original goals? A “no” to either of the evaluation criteria above should be brought to the Board Lead and they will bring it to the Grants Council for further deliberation A “yes” should be communicated to signal the board’s approval Contention or questions around completion will be brought to the Grants Council for further deliberation Final Developer Advisory Board Communications A summary of the Developer Advisory Board’s work and recommendations will be posted on the forum after the Delegate Mission Request process and each Mission Application process. Delegate Mission Request refusals (if applicable), Application recommendations and justification summaries, should be expected to be part of this summary. As some work will be ad-hoc advisory, that work may not appear in this summary. DAB meeting minutes will also be linked in this post.

Likes: 5 Replies: 0

Likers: devrose, gonna.eth, axel_t, omarsin, fractalvisions

No replies yet.