Recording: https://drive.google.com/file/d/12pJTzZt3O7rsGxMObB1rrFDje_3ZJMzo/view?usp=sharing
Last updated
Agenda for OSC tomorrow: Old Business:
Update from Policy TWG (Marcin or CT)
Update from Strategy TWG (Sandip, Gheorge)
New Business:
Strategy Discusssion (Bogdan)
Discussion Point
Notes / Action Items
Responsible
Update from OS Policy TWG
Marcin provided an update on policy changes over the past week. The team is preparing for next week's inaugural network working group meeting. Discussions will focus on organizing the team and identifying suitable buildings for our operations.
Note
Update from OS Strategy
Bogdan’s Introduction:
Acknowledges feedback from Michael, Nick, and Sandeep.
Approach to handling comments:
Initially responded directly to each comment.
Proposes discussing all comments collectively.
Asks for agreement on this approach.
Feedback Focus:
Content (mission, vision, etc.) rather than the general framework.
Emphasizes the need to lock down the foundational model before populating it.
Foundational Model:
Requests feedback on the foundational model.
Aim for a strong agreement before moving to content.
Open-Source Strategy Document:
Extended version of last week’s presentation.
17 pages but easy to read.
George’s Proposal:
Review Time:
Agrees to give colleagues 15 minutes to read the document.
Amazon Approach:
Michael suggested private reading followed by discussion.
Silona’s Recommendation:
Suggests starting review from page 11.
Focus tends to be on content beyond that point.
No discrepancies in the framework.
Bogdan’s Clarification:
Asks whether the first or second page is being used.
Silona’s Question:
Clarify whether the strategy document is for all of Intersect or the OC committee.
Bogdan’s Response:
It’s about open source in general within the Cardano world.
Silona’s Perspective:
Scope and Precision:
Warns against overly broad statements.
Advocates for manageable scopes to avoid accidental political issues.
Balancing openness with practicality.
Change Management:
Proposes a clear path for contributors to become maintainers.
Importance of community buy-in and validation.
Acknowledges insular behaviors in the crypto community.
Encourages cautious language to avoid negative perceptions.
Christian’s Feedback:
Content Origins:
Acknowledges that some of the content was from original drafts when the committee was established.
Highlights that these contents may not accurately reflect the current direction.
Proposes refining and debating the content.
Terminology and Refinement:
Appreciates Silona’s emphasis on terminology.
Agrees that refining and discussing the content is crucial.
Bogdan’s Feedback:
Executive Summary:
Views the first page as an executive summary, which is the most appealing part.
Suggests challenging and adjusting the foundational model.
Raises the possibility of omitting the mission and vision if they don’t align with the open-source initiative.
Silona’s Example:
IEEE Case Study:
When working with IEEE, Silona broke down their mission, vision, purpose, core values, goals, and strategic plan.
IEEE is a massive organization with 420,000 people worldwide.
Within IEEE are sub-decisions and subgroups, such as the portion of the standards (with about 26,000 people).
Silona’s approach:
Harvested information from all three groups: IEEE, IEEE standards, and OS open.
Combined the mission, vision, etc., to create a cohesive view.
Result: Clear understanding of how each level fits together.
Suggestion for Cardano and Intersect:
Consider a similar approach.
Articulate overarching mission and vision statements for each level (Cardano, Intersect, OSC).
Avoid dictating without consulting the broader community.
Consider distinguishing between “Cardano” and “Core Cardano” to clarify openness and support mechanisms.
Bogdan’s Perspective:
Cardano Strategy vs. Our Strategy:
Acknowledges that our strategy is different from Cardano’s strategy.
Our strategy emerges from Cardano’s strategy or core Cardano strategy.
Recognizes that we depend on upstream strategies at the Cardano and Intersect levels.
Seeks clarity on whether these strategies are acceptable or if references exist.
Advocates for a top-down approach where what’s on top defines what’s below.
Christian’s Input:
Reading Timing:
Proposes starting the reading in 10 minutes.
Assumes one minute per page for context.
Acknowledges the focus on the framework itself.
Initiates a timer for the reading.
Update on Workflow
George’s Update:
Working on four key points:
Delivery of the OSPO Governance Model and Structure
Delivery of OSPO and OS Strategy and Policies
Establishment of Functional Reporting Areas for Delivery Assurance
Running the GitHub Audit
First Point: Governance Structure:
Definitions of entities introduced in the OSPO governance model.
Added a glossary with definitions for terms used in the document.
Ensuring a common understanding across all documents.
The document is editable by anyone.
No stress regarding changes.
Structure Documents:
Prepared two documents related to the structure (including diagrams).
Available for the first review next week.
Functional Reporting Areas:
We create the first draft of the document about the functional reporting areas for delivery assurance.
We’ll distribute the links via channels for feedback.
Notes
OS Strategy Doc feedback:
Participant colleagues spent 10 minutes reading the document. They gave their feedback.
Sebastian’s Feedback:
Strategy Building and Scope:
Acknowledges the helpfulness of the document for anyone needing to build a strategy.
Questions the intended scope:
Is it for open-source, Nextstream, Intersect, or anyone/individual projects?
Suggests harnessing it into a guide on how to build a strategy.
Asks whether everyone from a project committee should create their strategy.
Values and Principles:
Resonates with Michael’s comments about aiming high and capturing values.
Encourages revisiting and amending existing values and principles.
Advocates for continuity rather than creating a parallel world.
Scope Clarification:
Asks if the strategy aims to “rule the world” or if there’s a specific scope.
Requests more concrete details.
Silona’s Feedback:
Scope and Parallelism:
Warns against overlapping and parallelism across committees.
Highlights the need to engage with other committees.
Advocates for clear communication and coordination.
Suggests engaging with the civics workshop and ecosystem discussions.
Encourages defining scope to avoid overreaching.
Action Item:
Silona’s Suggestion:
Engage with other committees (such as the civics workshop and ecosystem discussions).
Define scope to avoid overreaching.
Coordinate and communicate effectively across committees.
Silona will annotate documents to facilitate collaboration.
Christian’s Proposal:
Delivery Assurance Function:
Drafting the difference between the vision committee, technical steering, and open source.
Aims to clarify remits and initiate discussions with relevant committees.
Acknowledges that the TSC cannot handle everything.
Vision committee still needs definition.
Open source committee is currently advisory but should transition to decision-making status.
Silona’s Feedback to change from advisory to decisional:
Scope and Decision-Making:
Advocates for transparency about decision-making groups.
Clarifies the roles of steering committees, advisory groups, working groups, and task forces.
Highlights the variability in understanding based on committee names.
Encourages defining scope to avoid assumptions.
Sebastian’s Feedback:
Committee Role and Advisory Status:
Acknowledges that the open source committee is currently advisory.
Questions whether the committee’s role is more than advisory.
Highlights the need to ensure quality and maintain standards.
Notes tied to technical steering and funding areas.
Advocates for clarity on the committee’s purpose and interconnections.
Starting Point and Concrete Practices:
Supports starting with concrete practices and governance processes.
Encourages defining a clear strategy for the next five years.
Raises whether Intersect should have a strategy beyond the committee or program office.
Christian’s Explanation:
Committee Purpose:
The open source committee’s primary purpose is to develop a strategy for making Cardano open source.
Historically, Cardano development has been mostly contracted private development or center company contributions to the code.
The goal is to build a larger base for people to contribute and own Cardano.
The strategy aims to improve Cardano’s current status as an open-source project.
Decision-Making Status:
The committee’s transition from advisory to decision-making depends on political considerations.
The balance between writing policies and ratifying them plays a role.
The relationship with the technical steering committee (TSC) is also a factor.
Open Source Practices:
Proposes setting up basic open source practices based on how Intersect operates.
Decentralization and Hosting Platforms:
Sebastian emphasizes that GitHub is not inherently decentralized.
It’s acceptable for projects to live on platforms like GitLab or other SVN-based systems as long as they adhere to open-source principles and our values.
The goal is to challenge the status quo and explore alternatives.
Security Concerns:
Silona highlights GitLab’s commitment to openness.
GitHub’s security shortcomings include reliance on SHA-1 and verifiability issues.
We must handle CI/CD securely to prevent malicious code insertions.
Centralization and Findability:
Silona emphasizes the importance of centralizing information.
GitLab’s approach of having one handbook to rule them all works well (https://handbook.gitlab.com/ ).
While we aspire to be decentralized, having a central space is crucial.
Cross-linkages ensure findability, and GitBook serves as a central repository.
Everything will be posted under the open-source committee folder, including links to meeting notes, chat logs, and documents.
The concept of a universal “read me” accessible on our website is proposed.
GitLab Pages:
Silona favors GitLab over GitHub due to GitLab Pages, which simplifies publishing diverse content.
GitLab’s streamlined approach keeps things in sync more easily.
Communication channel update
Marcin: Michael has created multiple metrics-related channels. These channels aim to facilitate open communication with developers. The challenge lies in transitioning from our non-public communication style to this more transparent approach.
Christian’s Update:
Christian will update the communication channel.
Efforts to publicize updates:
Intersect Newsletter: The update will be featured in the newsletter.
Discord Slack Channel: The channel will transition to the announcements-only mode for the committee.
Matrix: The committee will explore using Matrix as the primary communication channel.
Silona’s Perspective:
Open-Source Norms:
Silona suggests following open-source norms for transparency.
Readme.md: All relevant information should be listed in the readme.md for different project components.
GitHub Repo for OSC: Create a dedicated GitHub repository for OSC (Open Source Committee).
Markdown Format: Use markdown for consistency.
Transparency: Avoid locking information behind Google Docs.
Quality Audience: Developers familiar with GitLab or GitHub will find it accessible.
Conflict Resolution: By adopting open-source practices, conflicts can be minimized.
IOG vs. Intersect Channels:
Silona emphasizes avoiding an IOG-dominated perception.
Suggest using “Intersect” rather than “IOG” for channels.
Warns against locking information within a single company.
Proposes a clear path for contributors to become maintainers.
Marcin’s Idea:
Intermediate Approach:
Marcin proposes an intermediate solution.
Separate Channel for Network:
Create a separate channel tied to actual people with commit rights.
Still open but governed by maintainers or Intersect.
Balances openness and privacy.
Challenge:
Moving to fully open channels is difficult for some, especially senior developers.
Concern that people may organize private discussions regardless.
Suggest a gradual transition.
George’s Proposal:
George suggests a two-step movement and transition.
Step 1: Apply the chosen approach (private or public).
Measurement: Evaluate effectiveness.
Step 2: Move to public if the solution proves functional.
Nicholas’s Input:
Internal vs. External Channels:
Existing notion of internal and external channels within IOG Slack.
Suggestion:
Keep internal channels but move IOG public channels to be truly public.
Less intimidating for developers.
Internal development channels can still coexist.
Notes
Communication Channel Update:
Christian will handle the communication channel update.
Efforts include featuring updates in the Intersect newsletter, transitioning the Discord Slack channel to announcements-only mode, and exploring Matrix as the primary communication channel.
Silona’s Perspective:
Suggests following open-source norms for transparency.
Proposes listing relevant information in the readme.md for different project components.
Advocates for a clear path from contributor to maintainer status.
Marcin’s Idea:
Proposes an intermediate approach:
Create a separate channel tied to actual people with commit rights.
Balances openness and privacy.
Acknowledges the challenge of moving to fully open channels.
George’s Proposal:
Suggests a two-step movement and transition:
Step 1: Apply the chosen approach (private or public).
Measure effectiveness.
Step 2: Move to public if the solution proves functional.
Nicholas’s Input:
Suggests keeping internal channels but making IOG public channels truly public.
Less intimidating for developers.
Internal development channels can coexist.
Actions
