🥹(02/23/24) Meeting Minutes

Recording: https://drive.google.com/file/d/17wfy5HIr4Mczk6fVnJ9XSFTeigUtsxjl/view?usp=sharing

Old Business:

1. Update from (Governance) Policy TWG (MS or CT)

2. Update from Strategy TWG (SP, GP)

3. Update on Workflow for OSO (GP)

4. Update on Project Incubation Policy (CT)

New Business:

1. Security Policy / Comms Policy (MPJ)

2. Sustainability Policy TWG (Nich / MPJ)

3. Govtool Decentralization Strategy (Lorenzo)

4. Strategy Testing Criteria (Gheorghe / CT) - moved for the next week.

Discussion Point	Notes / Action Items	Responsible
The Governance Policy Technical Working Group	We know when the Networking Group will start the Networking Working Group. [e-mail] will contact [e-mail] to check if this is well for him to join. [e-mail] agree, it will also be published somewhere. [e-mail] will publish it and announce the people who will join it.	Note. [e-mail] [e-mail]
Project Incubation Policy	Progress: Significant headway has been made on the incubation policy draft. Work continues to refine the structure and details. Model Shift: Transition from the Hyperledger Linux Foundation model to a framework inspired by the Cloud Native Computing Foundation (CNCF). Draft Deck: An initial high-level goal deck was created as a starting point for extensive discussion and revision ([link to the deck if available]). Focus Areas: Graduation Criteria: Project goals and phases outlined. Project Intake: Inspired by CNCF, focus on project alignment and documentation. Collaboration: Defining roles and responsibilities (Intersect, community, TSC, OSC) Next Steps Detail Key Areas: Policy alignment, due diligence, TSC/OSC involvement, review process, and support services. Stakeholder Group: Formation of a group to draft and amend policy. Community Feedback: Publish draft for review. Refinement and Adoption: Incorporate feedback, with TSC involvement, and vote for adoption. Key Discussion Point: Refinement of the "builder developer operator" nomenclature.	Note. Michael Peyton Jones 6:11 PM The eclipse foundation one is also sparse but reasonable: https://www.eclipse.org/projects/dev_process/#6_2_Project_Lifecycle Christian Taylor 6:11 PM https://docs.google.com/presentation/d/1_KdAmhuBKYhWi3Om7Yl5rjlHxQef1TFirvfnIMR-VPs/edit#slide=id.g2668e30288b_0_0 Sebastian Nagel 6:14 PM It's too ambiguous IMO * the names Adam Dean 6:22 PM Larva, Pupa, Butterfly? Michael Peyton Jones 6:22 PM Sandbox, Incubating, Mature Alex Seregin 6:22 PM dandelion) Nicholas Clarke 6:22 PM Squirtle, Wartortle, Blastoise? Michael Peyton Jones 6:22 PM (mix of CNCF and eclipse) Sebastian Nagel 6:23 PM Sandbox, Incubating, and Mature are already much better Daniel Eduardo Mosquera Pava 6:24 PM Thank you. Sebastian Nagel 6:24 PM Mature: e.g cardano-node? Incubating: e.g., Aiken? Hydra? Sandbox: e.g., cardinal? (I feel already more at home with these names)
	Key Points: Criteria for Entry: There was a debate between a case-by-case committee approach and defining explicit project criteria. Michael suggested alignment with existing committees (TSC, Vision) and potentially aligning with their priorities. Graduation Criteria: An annual review process similar to CNCF was suggested to manage project lifecycles and prevent "dead projects." Phases and Maturity: Discussion centered on defining project phases (building, developing, operating) and corresponding maturity levels. Terminology: "Builder, Developer, Operator" was deemed unclear and will need refinement. Additional Discussion: Sustainability Policy: Nick proposed a policy for ensuring core project components are sustained, potentially through dedicated maintainers. Knowledge Transfer: Christian and Adam emphasized the importance of knowledge transfer during transitions and explicitly included it in supplier contracts.	Note
	Actions: Refine Key Areas: Detail policy alignment, due diligence, committee involvement, review process, and support services. Form a Stakeholder Working Group: Nick, Bastion, Adam, and Michael to collaborate on drafting and amending the policy. Community Feedback: Publish the draft for community review. Refine and Adopt: Incorporate feedback, involve TSC if needed, and vote for adoption.	SWG (created at action 2). [e-mail] [e-mail] SWG (created at action 2).
	Next Steps: Refine and finalize the project incubation policy based on the discussion points. Develop and implement a sustainability policy for core projects. Implement processes for knowledge transfer within the organization.	[e-mail] SWG was created at action 2. SWG was created at action 2 with other involved WGs.
Govtool Decentralization Strategy (Lorenzo)	GovTool and Decentralized Governance Introduction Lorenzo leads the GovTool product team within Intersect, seeking feedback on their decentralization strategy. GovTool allows the community to test governance features (delegation, registration, voting, analysis) in a user-friendly interface. Decentralization Goals Move from centralized to open, collaborative development and decision-making for GovTool. Empower users to determine future needs, design, priorities, value propositions, and fixes. GovTool Pillars Delegation Voting Proposal discussion Governor's actions and outcomes Formation of a constitutional committee Key Message GovTool provides the tools (SanchoNet), but the community needs to take ownership to drive its decentralization and ongoing evolution.	Note
	Q&A Q: What does "outsourced" mean under the different GovTool pillars? A: Initially, pillars like delegation and voting were outsourced to specific builders through a tender process. Newer pillars are being developed through grants. The long-term goal is ongoing, open development. Decentralization Strategy Goal: Transition GovTool from a centralized model to community ownership, ensuring users know they can contribute, maintain, and drive the tool's evolution. Approach: Establish working groups to structure the decentralization process across the entire software development lifecycle. Key Challenges Finding maintainers: Identifying core maintainers and creating a process for community members to become core contributors. (Adam) Balancing decentralization with the need for decisions: How to distribute decision-making authority within the decentralized model. (Michael) Lorenzo's Proposal Working Groups: Form working groups with different potential stakeholders (builders, Intersect team, community members) to manage specific parts of the development process. Measures of Success: Each pillar is owned and maintained by community builders Open processes exist for anyone to contribute (bug fixes, bounties, etc.) Next Steps Lorenzo’s working group will define these processes further.
	Summary Lorenzo was presenting a plan (via a Miro board - https://miro.com/app/board/uXjVNpW9zG8=/?moveToWidget=3458764580080744526&cot=14 ; password: intersect) to the participants (the members of the open-source committee) on how to decentralize a product development process for governance tools. The discussion delves into budgeting, potential working groups or committees, and how open-source principles would be applied to this process. Key Points and Issues: Scope: There's a lack of clarity about the precise scope of decentralization (does it refer to product development only or broader project decision-making?). Process Efficiency: Some express concern that the proposed model, with multiple working groups, might be too bureaucratic and inefficient for a single open-source project. Budget: There are questions about who controls the budget for the decentralized governance tools working group and how that budget would be allocated. Governance Model: Questions remain about whether this is genuinely a governance decentralization or is more focused on project management and execution. Comparison to Cardano: The project aims to follow a governance structure similar to the Cardano project. Overall Questions and Considerations: How can the process balance decentralization with efficient decision-making? It's a core challenge of decentralized open-source governance. Who ultimately has decision-making authority in this proposed model? How will this structure scale effectively as the project grows? Is the Cardano governance structure appropriate, considering the project's specifics?	Note