😆(3/28/2024) Meeting Minutes

Recording: https://drive.google.com/file/d/1bsq4wTFpi6kbVxXs514RlEm4WNdoK6D3/view

Mar 28, 2024 | Open Source Committee (Intersect)


Recording: https://drive.google.com/file/d/1bsq4wTFpi6kbVxXs514RlEm4WNdoK6D3/view?usp=sharing

Transcript: https://docs.google.com/document/d/12_-vYj_3_eOIS3_KG7chhVrAs0K3mtOvR6jSo-Va5DI/edit?usp=sharing


Old Business:

  1. Nothing here.

New Business:

  1. Solidify updated goals form the Strategy TWG yesterday.

  2. Agree to high level action items to deliver these goals.

  3. High level review of the foundation framework form past conversations in March.

  4. Vote to ratify this initial strategy.

Discussion Point

Notes / Action Items

Actions: Responsible / Note

Update from Policy TWG

  1. Revised Goals:

    1. The group discussed the revised goals from the recent sessions.

    2. The aim is to finalize these goals and establish high-level action items for delivery.

  2. Foundation Framework Model:

    1. A high-level review of the foundation framework model was conducted.

    2. A vote on the format will be held, followed by drafting a delivery plan.

  3. Document Update:

    1. Bogdan Coman confirmed the update of the document with the latest metrics messages.

    2. The group reviewed the previous version of metrics for the first goals.

  4. Cardano Project Goals:

    1. By the end of 2024, all Cardano projects should have a transparent platform for their future, aligned with a general life cycle framework.

    2. Decisions on project progress, futures, mitigations, and postmortem actions will be based on this framework.

  5. Terminology Adjustments:

    1. Christian Taylor suggested replacing “General” with “Lifecycle Frameworks” for specific projects to better reflect the goals.

  6. Sustainability Focus:

    1. Michael Peyton Jones emphasized the importance of sustainability in the project lifecycle framework.

    2. The group agreed that sustainability should be a key goal.

  7. Incubation Integration:

    1. Christian Taylor proposed highlighting the connection between incubation and the lifecycle framework, as they are intrinsically linked.


  • Vote on the foundation framework model format.

  • Draft a delivery plan for the agreed-upon goals.

  • Update the document terminology to reflect the focus on specific project lifecycle frameworks.

  • Emphasize sustainability in the project goals.

  • Integrate incubation into the lifecycle framework discussion.


8. Clarity on Goals:

  • Michael Peyton Jones sought clarity on whether the focus was on ensuring sustainability or defining a clear project lifecycle.

  • The consensus was to aim for a clear definition within a lifecycle framework.

  1. Sustainability vs. Lifecycle Framework:

    • Bogdan Coman shared his perspective on sustainability, emphasizing a solid approach to the future of projects.

    • Christian Taylor expanded on this, noting that technical sustainability should include the future trajectory of projects within the lifecycle framework.

  2. Framework Criteria:

    • Discussion on what constitutes completion within the lifecycle framework.

    • Michael Peyton Jones questioned the necessity of a specific sentence, debating its relevance to the goals.

  3. Document Clarity:

    • Bogdan Coman argued for the clarity provided by the second sentence, linking it to the understanding of progress within the framework.


  • Clarify the primary goal between sustainability and a clear project lifecycle.

  • Define criteria for project completion within the lifecycle framework.

  • Review the necessity and clarity of sentences within the document to ensure they align with the group’s goals.


12. Lifecycle Framework Phrasing: - Michael Peyton Jones suggested rephrasing to clarify that all aspects will be captured according to the lifecycle framework. - The framework should address specific questions to ensure it meets the group’s standards.

  1. Open Source Committee’s Role:

    • Adam Dean inquired about the Open Source Committee’s (OSC) role in establishing the lifecycle framework.

    • Christian Taylor clarified that it is a collaborative effort with the Technical Steering Committee (TSC).

  2. Lifecycle Framework Development:

    • Under the TSC, a lifecycle framework will be developed by Q4 2024.

    • All Cardano projects are expected to have documentation detailing their progress, sustainability, risk mitigations, and post-mortem actions.

  3. Goal Definition:

    • Adam Dean sought a precise definition of the goal.

    • Bogdan Coman emphasized that the outcome would define the action and establish the project framework.

  • Refine the phrasing of the lifecycle framework to ensure clarity and alignment with goals.

  • Clarify the roles of the OSC and TSC in the development of the lifecycle framework.

  • Develop a comprehensive document for each Cardano project, detailing its lifecycle.


16. Partnership and Responsibility: - Christian Taylor noted that while the project is in an interim phase, the committee could lead the initiative by drafting and getting approval from the PST. - Michael Peyton Jones expressed a misunderstanding of the committee’s responsibility, which was clarified by Christian Taylor.

  1. Audit Process and Language Clarity:

    • Adam Dean suggested refining the language to clarify that decisions about each project’s future are part of the goal, not a subsequent step.

    • The goal’s success will be measured by the criteria of progress reports on future sustainability, risk mitigation, and post-mortem actions.

  2. Project Framework Criteria:

    • Michael Peyton Jones defined the criteria for what the project framework should contain.

    • The discussion focused on ensuring that every project has a clear path for its future by Q4.

  3. Document Accessibility:

    • Gheorghe Pacurar proposed sharing a link to the document for direct editing.

    • Bogdan Coman agreed to provide the link in the chat for accessibility.

  4. Deliverable Clarification:

    • Sandip Pandey sought clarification on the deliverable aspect of establishing the project lifecycle framework.

    • The discussion aimed to define what the documentation would entail and ensure it serves as a roadmap for the projects.


  • Draft and seek approval for the project framework in partnership with the PST.

  • Refine the audit process language to reflect decision-making as part of the goal.

  • Establish clear criteria for the project framework regarding sustainability and lifecycle.

  • Provide accessible documentation for collaborative editing and review.

  • Clarify the deliverable and documentation aspects of the project lifecycle framework.


21. Hyperledger Project Lifecycle: - Christian Taylor discussed producing a governing document similar to the Hyperledger Project Lifecycle. - The document will incorporate the Open Source Committee and Delivery Assurance functions, distinct from the existing technical steering committee structure.

  1. Deliverable Definition:

    • The deliverable is to develop a comprehensive lifecycle framework that existing projects can be fitted into.

  2. Lifecycle Framework Evaluation:

    • Bogdan Coman inquired about the evaluation process of projects according to the lifecycle framework.

    • Christian Taylor clarified that the audit process would categorize projects and suggest remediation steps to ensure their health within the framework.

  3. Metrics and Auditing:

    • Discussion on establishing metrics for auditing the projects.

    • Christian Taylor proposed that by the end of the year, 50% of the projects should be in the devised funding mode, with all projects audited.

Actions (Continued):

  • Develop a governing document that includes the Open Source Committee and Delivery Assurance functions.

  • Fit existing projects into the newly developed lifecycle framework.

  • Define the evaluation and auditing process within the lifecycle framework.

  • Establish metrics for project auditing and set a target for project funding mode by the end of the year.

25. Audit Scope and Precision: - Gheorghe Pacurar emphasized the need for explicit mention that the audit pertains to Intersect and Core Cardano projects, which are under the group’s control. - The possibility of rewording the audit scope in Q2 was discussed if more projects come on board.

  1. Communication Policy and Metrics:

    • The group considered whether to reference the communications policy directly in the metrics for clarity and to encourage reading the governance policy.

    • Christian Taylor suggested that stating 70% of projects will follow the communications part of the governance policy could provide more clarity.

  2. Project Participation and Community Engagement:

    • Concerns were raised about project participation rates and community engagement, particularly in light of scheduling issues with daylight savings.

    • The group discussed the practicality of setting a 70% target for project adherence to communication policies, considering the varying cadences of project meetings.


  • Explicitly define the audit scope to include only Intersect and Core Cardano projects currently under control.

  • Decide whether to incorporate direct references to the communications policy in the project metrics.

  • Address the challenges of project participation and community engagement, considering the impact of scheduling and daylight savings.

28. Governance Policy Implementation: - The group discussed stabilizing the governance policy and working with projects to help them implement it. - Monitoring the implementation progress of the governance policy was highlighted as a key action.

  1. Measurability and Tracking:

    • Adam Dean proposed using tools like Mirror board or Trello to track each project’s adherence to open communication channels and public meeting hosting.

    • The measurability of these actions will be possible once the governance policy is fully ratified.

  2. Communication Policy Integration:

    • The communication policy is to be integrated as part of the broader governance policy.

    • Adam Dean suggested that the communication policy could be highlighted as its own entity for the time being, with the flexibility to break it out separately later if needed.

  3. TSC Maturation and Policy Enactment:

    • Christian Taylor expressed approval for the term ‘stabilized’ in relation to the TSC’s maturation and its role in enacting more of the governance policy.

Actions (Continued):

  • Work with projects to stabilize and implement the governance policy.

  • Monitor the progress of governance policy implementation.

  • Utilize project management tools to track the adoption of open communication channels and public meetings.

  • Integrate the communication policy within the governance policy, with the potential to highlight it as a separate entity.

32. Policy Terminology: - The group agreed to change the term ‘communications’ to ‘governance’ to better align with the actions and the existing policy terminology.

  1. Project Support and Diversity:

    • The goal is for 50% of core Cardano projects to be supported by paid maintainers from at least two companies by the end of 2024.

    • There is an emphasis on prioritizing contracted maintainers from diverse organizations to ensure project diversity and sustained contributions.

  2. Definition of Core Projects:

    • Discussion on what constitutes a ‘core’ Cardano project, with the understanding that not all repositories are critical to the network’s immediate functioning.

    • Adam Dean highlighted the importance of maintaining projects that are crucial to the network’s stability.

  3. Ambitious Goals:

    • Christian Taylor expressed an ambitious goal of achieving 80% support for core projects, acknowledging the challenge but emphasizing the importance of the objective.

  4. Diverse Perspectives on Core Importance:

    • Sandip Pandey offered a different viewpoint, suggesting that any project heavily utilized by developers should be considered ‘core’, not just those directly related to network operation.


  • Update policy references from ‘communications’ to ‘governance’ in all relevant documents.

  • Identify and prioritize core Cardano projects that require maintenance support.

  • Set ambitious targets for project support while ensuring diversity among maintainers.

  • Engage in further discussion to define ‘core’ projects, considering both network-critical and developer-utilized repositories.

37. Criticality Assessment: - Adam Dean raised the question of how to audit and determine the criticality of various projects, such as Daedalus versus more widely used libraries like CSL. - The group discussed the need for a clear distinction between ‘core’ and ‘Cardano’ projects to prioritize maintenance efforts.

  1. Project Classification:

    • Michael Peyton Jones suggested focusing on ‘Cardano projects’ as a clear grouping for initial maintenance and support.

    • The group considered removing the term ‘core’ to avoid confusion and concentrate on the most crucial projects.

  2. Testing Process for Mission-Critical Projects:

    • Christian Taylor mentioned the necessity of a close partnership with the pilot to test the process of bringing in mission-critical projects.

    • A 90-day testing period was proposed to identify and include mission-critical aspects outside of the core Cardano projects under Intersect.

  3. Intersect Maintenance and Risk Identification:

    • Gheorghe Pacurar proposed using ‘intersect maintenance’ as a term and developing a process to identify critical or core risks.

    • Michael Peyton Jones agreed, noting the existence of a current classification that can be utilized in the short term.


  • Develop a process to audit and determine the criticality of various projects within the Cardano ecosystem.

  • Focus on supporting ‘Cardano projects’ as a primary group for maintenance and support.

  • Implement a 90-day testing process in partnership with the pilot to identify mission-critical projects.

  • Utilize ‘intersect maintenance’ as a term and establish a process for risk identification within the Cardano projects.

41. Project Classification and Funding: - The group discussed the classification of projects and the current focus on those maintained by Intersect. - Adam Dean noted the group is not yet ready to fund maintenance for non-Intersect maintained repositories.

  1. Policy Application and Expansion:

    • There was a consensus that existing policies need to be applied to current responsibilities before considering expansion to new projects.

  2. Terminology Consistency:

    • The discussion moved towards maintaining terminology consistency across documents.

    • Christian Taylor suggested that ‘core Cardano’ has come to mean everything under the Intersect umbrella, indicating a possible shift in terminology usage.

  3. Intersect Maintenance Classification:

    • Gheorghe Pacurar proposed using ‘intersect maintained’ as a consistent term across discussions.

    • The group agreed to adopt this formulation for clarity and consistency.


  • Maintain focus on Intersect maintained projects for funding and support.

  • Apply and stabilize existing policies before expanding responsibilities.

  • Ensure terminology consistency, particularly regarding the classification of ‘core Cardano’ projects.

  • Adopt ‘intersect maintained’ as a standard term for clarity in discussions and documentation.

45. Clarifying Project Terminology: - The group discussed the importance of clear terminology to prevent confusion within the community, especially regarding the term ‘core Cardano’. - It was suggested that an explanatory note be added to clarify that ‘core Cardano’ refers to projects maintained by Intersect.

  1. Intersect-Maintained Projects:

    • Adam Dean emphasized the clarity provided by consistently using ‘Intersect-maintained’ to describe the projects under discussion.

  2. Concerns Over Exclusivity in Maintenance Contracts:

    • There was a concern raised by Adam Dean about the perception of exclusivity in awarding maintenance contracts, based on a discussion from Kevin Hammond.

    • The group acknowledged the need to ensure that policies do not inadvertently create barriers for new contributors.

  3. Inclusivity in Contributor Recognition:

    • The discussion highlighted the importance of recognizing contributions from the broader community, not just those who have previously received funding.


  • Add a clarification note regarding the use of ‘core Cardano’ to denote Intersect-maintained projects.

  • Ensure the term ‘Intersect-maintained’ is used consistently across all communications to avoid ambiguity.

  • Address concerns over exclusivity in maintenance contracts and work towards inclusive policies that encourage broad community participation.

  • Recognize and facilitate contributions from all members of the community, regardless of their funding history.

49. Maintainer Pathway Clarification: - Michael Peyton Jones clarified that being a maintainer requires a history of contributions, not just paid work. - The group discussed the challenge of achieving the goal due to the small number of people currently in a position to become maintainers.

  1. Contributor to Maintainer Transition:

    • The transition from contributor to maintainer was identified as a necessary pipeline for project sustainability.

    • Adam Dean questioned the timing of seeking paid maintainers before establishing a clear contributor base.

  2. Goal Feasibility and Ambition:

    • The group debated the feasibility of the goal to have paid maintainers for 50% of the projects.

    • Christian Taylor advocated for the goal’s realism, given the number of repositories and the importance of establishing a clear maintainer pathway.


  • Clarify the pathway for contributors to transition into maintainers within the governance policy.

  • Assess the current base of contributors and strategize on expanding the pool of potential maintainers.

  • Set realistic yet ambitious goals for maintainer support across projects, aiming for at least 50% coverage.

  • Document and communicate the process for joining a project as a maintainer to the community.

52. Goal and Strategy Differentiation: - The group discussed the importance of distinguishing between goals and strategies. - Michael Peyton Jones suggested that goals should stand alone, with strategies outlined separately to describe how goals will be achieved.

  1. Action Items Clarification:

    • There was a consensus that action items should be clear steps derived from the strategy to achieve the stated goals.

  2. Strategy Integration:

    • Gheorghe Pacurar proposed integrating the strategy into the description of action items.

    • Christian Taylor agreed to label the second sentences as strategy to engage with the goal, followed by specific actions.


  • Clearly differentiate between goals and strategies in the documentation.

  • Label strategies appropriately and integrate them into the action items section.

  • Ensure that action items are specific, measurable steps that align with the overarching strategy.

The discussion continues with the group focusing on the distinction between goals and strategies. They agree that while strategies guide decision-making, they should remain adaptable. The conversation shifts to the practical aspects of implementing the strategy, such as conducting audits to identify potential companies and formalizing pathways to maintenance roles.

The group also delves into the definition of a project maintainer’s role within the governance policy. There’s a debate on whether having a clearly defined pathway to becoming a maintainer is beneficial or if it should be based on the trust and consensus of existing contributors. The concern is that strict criteria might lead to disputes if individuals meet the criteria but are not accepted as maintainers due to other factors.

Adam Dean raises a critical point about the process of selecting paid maintainers, emphasizing the need for a transparent and fair process that includes a clear job description and eligibility requirements.

The group seems to be working towards a consensus on how to approach these challenges, aiming to create a system that is both structured and flexible enough to accommodate the dynamics of community contribution and project maintenance.

55. Maintainer Role vs. Paid Position: - Michael Peyton Jones emphasized the distinction between the role of a maintainer and a paid position, suggesting that funding should support individuals already fulfilling the maintainer role.

  1. Contributor Path to Maintenance:

    • The group discussed the necessity of a clear path for contributors to elevate to maintainers, acknowledging that this might vary across projects.

  2. Qualifications for Funding:

    • It was agreed that qualifications for a maintainer must be met before a company can apply for funding to support that role.

  3. Clarifying Governance Policy:

    • Michael Peyton Jones highlighted the need for clarity in the governance policy, particularly regarding the privileges of paid maintainers.

  4. Action Item Prioritization:

    • Christian Taylor and Adam Dean discussed the prioritization of defining the maintainer pathway as a first step before engaging potential funding sources.

  5. List Structure for Actions:

    • The group debated the structure of the action items list, with a consensus forming around an unordered list to avoid implying priority.

  6. Eligibility for Maintainer Funding:

    • Sandip Pandey raised a question about the eligibility criteria for maintainer funding, considering employee turnover and the implications for companies versus individuals.


  • Ensure a clear distinction between the maintainer role and paid positions in project governance.

  • Develop a contributor path to maintenance that is adaptable to the specific needs of different projects.

  • Establish qualifications for maintainers to be eligible for funding.

  • Provide clarity in the governance policy regarding the privileges and responsibilities of paid maintainers.

  • Prioritize the definition of the maintainer pathway and review past contributions as initial steps.

  • Adopt an unordered list format for action items to avoid implying a sequence of steps.

  • Clarify eligibility criteria for maintainer funding, considering both individual contributors and company roles.

62. Role of Companies vs. Individuals: - Michael Peyton Jones reiterated that while companies may employ contributors, it is the individuals who actively contribute and should be recognized as such.

  1. Succession Planning for Maintainers:

    • Christian Taylor suggested a nomination process for new maintainers when current ones step down, ensuring continuity and capability.

  2. Contributor and Maintainer Distinction:

    • Adam Dean discussed the practical aspects of contribution and maintenance, noting that while companies may provide contributors, maintainers are chosen by consensus among existing contributors.

  3. Inclusion of Maintainer Definition:

    • Bogdan Coman questioned whether the definition of a maintainer’s role should be included in the document, to which Adam Dean responded that it is already defined in the governance policy.

  4. Governance Policy Revision:

    • The group considered revising the governance policy for additional clarification based on the ongoing discussion.

  5. Goal Timeframe:

    • Bogdan Coman and Christian Taylor discussed the timeframe for goals, acknowledging that while they are typically set for longer than a year, the current focus is on the upcoming eight months due to funding constraints.

  6. Security Framework Establishment:

    • The group agreed on the importance of establishing a security framework for all open-source projects related to core initiatives within the given timeframe.


  • Recognize individual contributors regardless of their company affiliation.

  • Implement a nomination and approval process for maintainer succession.

  • Clarify the distinction between contributors and maintainers in practice and policy.

  • Review and potentially revise the governance policy to ensure clarity on the maintainer’s role.

  • Set goals with a clear understanding of the available timeframe, focusing on immediate priorities.

69. Language Consistency: - Gheorghe Pacurar proposed using consistent language across all goals, specifically changing references to ‘Cardano projects’ for uniformity.

  1. Security Officer Role:

    • Adam Dean agreed with Michael Peyton Jones’ previous comment on Matrix that dedicated security officers for core projects are unnecessary due to the development of a security policy.

  2. Security Policy Development:

    • The group discussed the ongoing development of a security policy that would standardize practices across projects without the need for dedicated security officers.

  3. Global Security Scope:

    • Adam Dean suggested a global approach to security that assigns responsibilities on a case-by-case basis, rather than appointing individual security officers to each project.

  4. Policy Adherence:

    • Christian Taylor recommended simplifying the goal to state that a certain percentage of projects will adhere to the security framework, without specifying the inclusion of dedicated roles.


  • Standardize the language used to refer to ‘Cardano projects’ across all documentation.

  • Recognize the development of a security policy that will apply to all projects, negating the need for dedicated security officers.

  • Adopt a global approach to security, assigning responsibilities as needed based on project requirement

74. Finalizing Security Policy Language: - The group agreed on the final language for the security policy, emphasizing that at least 80% of projects should adhere to the standardized security policy.

  1. Security Issue Reporting Process:

    • A global reporting process for security issues was discussed, aiming for a standardized method applicable to all Intersect projects.

  2. Voting on Strategy:

    • The team prepared to vote on the overall strategy for the next year, with Christian Taylor ready to draft concrete delivery actions for the action items.

  3. Ratification and Documentation:

    • The strategy was ratified, and Christian Taylor proposed documenting it on GitBook as a PR in GitHub, inviting comments and revisions from the team.


  • Finalize the wording for the security policy to ensure clarity and adherence.

  • Develop a global security issue reporting process that is consistent across all projects.

  • Vote on the overall strategy and action items for the upcoming year.

  • Document the ratified strategy and make it available for team review and input.

Closing Remarks:

  • Christian Taylor expressed gratitude for the team’s efforts and discussed disseminating the ratified strategy across various channels.

  • The team agreed to credit Bogdan Coman with the authorship of the document.

  • There was a suggestion to adjust meeting cadences to twice a month to allow for more efficient use of time.

  • The meeting concluded with well-wishes for the holiday season, with several members exchanging greetings for Easter.


  • Distribute the finalized strategy document through all relevant channels.

  • Credit Bogdan Coman as the author of the document in official records.

  • Adjust the meeting schedule to twice a month for better efficiency.

  • Document the strategy on GitBook and GitHub for team review and input.

Final Actions

Meeting notes and action items:

Discussion Point

Notes / Action Items

Actions: Responsible / Note

Update from Policy TWG

Christian Taylor: There is nothing new.


Spontaneously announcements.

Sebastian Nagel:

  1. Sebastian nominated Daniel Firtts as a member of the Open-Source Committee instead of him.

  2. Sebastian Nagel announced his increased involvement with Intersect and established a higher working group, which will work closely with the executive steering and open source committees. Christian Taylor will continue to be involved in this process. They plan to discuss this further next week, with a representative from Intersect joining to help streamline the process. The relationship between the open source committee and the projects, the role of the working groups, and the technical aspects need to be clarified. A “working group” under the technical steering and open source committees is suggested. Marcin is a test case for this structure, particularly with the governance policy.

  3. Further exploration is needed, and two people associated with the technical steering and all intersect-related committees will be brought in. Daniel Firth, who is involved with Hydra and Horizon Haskell and is a strong proponent of GitLab, will be brought in to replace Sebastian. The decision was made official with a vote. Daniel is already in the Matrix Channel and will have the appointments on his calendar for next week. He will also be given access to Google Drive and Slack.


  1. Sebastian Nagel will increase his involvement with Intersect and establish a higher working group.

  2. Christian Taylor will continue to be involved in the process and support the open-source committee.

  3. A representative from Intersect will join the discussion next week to help streamline the process. This action is assigned to Christian Taylor.

  4. The relationship between the open source committee and the projects, the role of the working groups, and the technical aspects need to be clarified. This is Sebastian Nagel and Christian Taylor's collective responsibility.

  5. A working group, including the technical steering committee and the open source committee, is suggested to be set up. This is Sebastian Nagel and Christian Taylor's collective responsibility.

  6. Daniel Firth will be brought in to replace Sebastian. This action is assigned to Sebastian Nagel.

  7. Daniel Firth will have the appointments on his calendar for next week. This action is assigned to Sebastian Nagel.

  8. Daniel Firth will be given access to Google Drive and Slack. This action is assigned to Christian Taylor.

Update from Strategy TWG (Bogdan)

Bogdan Coman led the discussion on the strategic direction for the Cardano Community. The core values and actions were established around openness, legitimacy, citizenship, and quality sustainability. The vision is to enable the successful development and evolution of Cardano as a community-led, decentralized, open-source project, with no single entity dominating its open development.

Three critical strategic areas or pillars were identified for focus over the next two years: governance and decision-making, sustainability and funding models, and community engagement and collaboration. These pillars align with the community’s identity and target audience.

Nicholas Clarke expressed concerns about aligning these strategic areas with the work that needs to be done, particularly in enablement and the ongoing work on security policies. Bogdan Coman suggested that these concerns could be addressed when defining the objectives and actions, ensuring they capture the work already started.

There was an agreement to establish significant objectives and goals from the strategic pillars. These goals should be aligned with the strategic areas, prioritized, committed, and defined as SMART (Specific, measurable, attainable, realistic, timely). Bogdan Coman emphasized the importance of individual ownership of goals to ensure accountability and effectiveness. The first goal discussed was to create a self-sustaining economic model for the open source initiative that covers operational costs and funds growth and innovation, with a timeframe to be established.

Sebastian Nagel initiated a discussion on the subject of sustainability, questioning its application to the open source committee and the projects in Intersect. Bogdan Coman clarified that sustainability applies to anyone aligned with the strategy, which could include the Cardano open source.

Nicholas Clarke expressed concerns about the committee’s role in developing an economic model for financing, suggesting that the committee should focus on advising on specific topics related to open-source development. He proposed that the committee could advise on the need for funding to maintain continuity, such as the requirement for a certain number of paid contributors.

Christian Taylor added that while the TSC can decide on suppliers and write contracts, the committee can provide guidance and recommend suppliers for repos but cannot sign any contracts. Sebastian Nagel agreed with these points, suggesting that the open source committee should advise on diversifying maintainers to ensure sustainability. He proposed that at least two independent maintainers should be funded for each component.

Adam Dean questioned whether sustainability and funding models were within the scope of the committee’s work and suggested refocusing on something more relevant. Gheorghe-Aurel Pacurar shared a link to the board Bogdan was presenting for further feedback. Bogdan Coman encouraged everyone to provide feedback on the board to help refine the strategy.

Christian Taylor suggested focusing on sustainability in defining the community's path to becoming independent maintainers. He mentioned a separate call with Silona, where they discussed the need for Intersect's strategy to address the fact that they are no longer a founding entity-owned company and have diversified people working and maintaining the repos.

Bogdan Coman agreed that sustainability, not funding models, should be the focus, as it encompasses different aspects beyond money. Nicholas Clarke supported this view, emphasizing the importance of technical sustainability.

Sebastian Nagel proposed that to qualify as a component or a core developer, one must not work alone in a silo. He suggested that to be a maintainer, one must work with someone else to maintain a component.

Nicholas Clarke suggested replacing the self-sustainability goals with issues that provide guidance and policy on what resources are needed to maintain the development of the projects. He also proposed a second objective focusing on the resources necessary to maintain the core products outside any new feature development.

Bogdan Coman asked Nicholas to insert his proposal in a comment. He suggested establishing a sustainable project framework and creating a rigorous evaluation system to ensure a specific project survival rate over two years.

Sebastian Nagel found the idea of a survival rate attractive and cited the example of a library in the Cardano ecosystem where the most active maintainer is no longer involved. He suggested using this as a case study to understand what happens when a project loses its most active maintainer and test its strategies' effectiveness.

Christian Taylor suggested changing the term “project framework” to “project guidelines” to avoid interfering with project autonomy and to provide best practices. He also pointed out that out of 600 repositories, two called “delete repos” had been there since 2018.

Adam Dean highlighted the example of Lucid, a heavily adopted community library that became central to many developers. When the developer left, the library was no longer maintained, leading to three different teams creating their unique forks of the library. This case study underscores the importance of community-driven development.

Sebastian Nagel proposed that sustainability could also mean maintaining a reasonable level of fragmentation in the community. He suggested an objective to keep the number of forks for any project to a minimum and enable collaboration.

Christian Taylor proposed targeting Q4 2024 for measurable success, as Intersect is expected to receive funding again in October. He also mentioned the need to reevaluate short-term goals in two months towards the strategy.

Nicholas Clarke emphasized the need to distinguish between the core Cardano products and other things being pulled in, as they have different requirements. He suggested two sets of guidance: one for maintaining and sustaining the core products and another for community products and supporting tools. He also mentioned the need for a diversified maintainer list onboarding for contributors to each project.

Christian Taylor proposed diversifying the supplier list, maintaining a diversified list of contributors, and establishing an onboarding path for all projects. He suggested these actions could be broken down into actionable items with specific dates, such as having a project incubation process.

Bogdan Coman questioned whether these actions related to the four strategic areas already identified or if they were separate proposals. Christian clarified that while these actions spawn from the strategic areas, they are more specific to their current work.

Nicholas Clarke agreed that while these actions might not necessarily be goals, they are valuable and should be captured. He suggested that these actions could become goals as they identify concrete things that need to be done.

Christian Taylor proposed a goal to diversify the maintainer list for all projects by the end of 2024. Bogdan Coman agreed that returning to a certain level of diversification is a good goal.

Bogdan Coman cautioned against starting with actions and trying to fit them into goals. He suggested starting with what they want to achieve and then deciding on better actions.

The discussion then moved to operating the governance framework, intending to reach a certain percentage of decisions made with direct community involvement by a specific date. This goal aims to ensure transparency inclusivity, and empower long-term sustainability. The governance framework is published in Gitbook, and a document is in Google Docs. Sebastian Nagel questioned the feasibility of measuring and presenting decisions, given the difficulty of knowing the total number of decisions in the framework.

Adam Dean expressed concerns about setting a fixed increase in the number of developers as a goal, arguing that it could lead to unworthy candidates being chosen just to meet the goal. Christian Taylor suggested measuring the increase in contributions based on their current status and proposed a goal for governance and decision-making hours.

Nicholas Clarke agreed with Adam and Christian, suggesting an active contributor could be a better metric. He proposed setting a goal to have regular external, non-funded contributors to each core Cardano project by the end of the year, acknowledging that this goal could fail.

Christian Taylor highlighted the Bitergia analytics tool, which defines contributions by casual, regular, and core contributors. He suggested using this tool to measure the baseline and aim for a higher number. He Another proposal is to increase the merge ratio on open-source projects as another possible measurement.

Bogdan Coman mentioned a comment from Michael about cycle time as a potential goal. The team agreed to consider these proposals and refine the goals further.

Nicholas Clarke and Christian Taylor discussed the importance of metrics such as time for a PR to go through stages and time to resolve sustainability issues. They agreed that these metrics could answer the goal of essential sustainability of the core projects.

Bogdan Coman summarized the proposals and outlined the following steps: taking feedback and coming up with the next iteration for these goals. He noted the need for another session to discuss the new proposal due to time constraints.

Christian Taylor proposed updating the technical working group time to include everyone who can make it and working with Bogdan Coman to define these and get some actions as proposals. He also assigned homework for everyone to add comments and feedback and propose actions before Wednesday.

Marcin Szamotulski announced that he would be off the following week. Nicholas Clarke noted that many people would be away the next Friday due to a holiday. Christian Taylor suggested moving the call to Thursday so everyone can vote on the ratification.

The meeting concluded with welcomes to Daniel Firth and wishes for a good weekend.

Nicholas Clarke and Christian Taylor discussed the importance of metrics such as time for a PR to go through stages and time to resolve sustainability issues. They agreed that these metrics could answer the goal of essential sustainability of the core projects.

Bogdan Coman summarized the proposals and outlined the following steps: taking feedback and coming up with the next iteration for these goals. He noted the need for another session to discuss the new proposal due to time constraints.

Christian Taylor proposed updating the technical working group time to include everyone who can make it and working with Bogdan Coman to define these and get some actions as proposals. He also assigned homework for everyone to add comments and feedback and propose actions before Wednesday.

Marcin Szamotulski announced that he would be off the following week. Nicholas Clarke noted that many people would be away the next Friday due to a holiday. Christian Taylor suggested moving the call to Thursday so everyone can vote on the ratification.

The meeting concluded with welcomes to Daniel Firth and wishes for a good weekend.

Last updated