diff --git a/governance/assessments/projects/pixie/2024-09-27.md b/governance/assessments/projects/pixie/2024-09-27.md new file mode 100644 index 00000000..5a8e0ae0 --- /dev/null +++ b/governance/assessments/projects/pixie/2024-09-27.md @@ -0,0 +1,165 @@ +# Governance Review Pixie + +What follows is a governance review and assessment for the Pixie project at the *Incubation level*. +This review is carried out by members of the Governance Working Group of TAG Contributor Strategy. + +Projects may ask TAG Contributor Strategy for assistance in resolving any issues uncovered by the review. The TAG is available via our [slack channel](https://cloud-native.slack.com/archives/CT6CWS1JN), [email](https://lists.cncf.io/g/cncf-tag-contributor-strategy), [GitHub](https://github.com/cncf/tag-contributor-strategy), or by joining our working group meetings (listed on the [CNCF public calendar](https://www.cncf.io/calendar/)). + + +## Summary and Assessment + +Status: Mostly Satisfactory + + +### Executing the Assessment + +### Critical Items + +The following issues have been identified that need to be resolved before Incubation: + +- None for Incubation. The areas for improvement (below) would be critical if the project was applying for Graduation, and would need to be remedied + + +### Points of Excellence + +The following aspects of governance are exemplary, and can be referenced as examples for other projects to copy: + +- In the ReadMe, Project Purpose is really well laid out. A person can tell very quickly what Pixie does, what it will do for my project. The screenshots are awesome!  + + +### Areas for Improvement + +Over the next year, the project should work on the following issues to improve its governance; These are considered non-blocking for advancement to Incubating: + +#### Governance Board processes + +- Complete the Governance Board (GB) documentation, including responsibilities, ownership, and decision making.  Differentiate them  from those of maintainers, and make it clear how any conflict between board and maintainers will be resolved.  + +- The Governance Board lifecycle is incomplete  (the process to add/maintain/remove members). It's not clear where board members are listed. The Board’s decisions/actions/recommendations are not public (see governance description below). + +- Complete the GB Membership: an End User seat still needs to be filled, and Community Members seats should be occupied by people who have time to spend on the Pixie project. It is not clear how someone initiates becoming a GB member - who do they contact? + +#### Maintainer processes + +- Lifecycle is  incomplete. There is no policy documented for applying to be a maintainer (how do they register their interest?), voting-in, voting-out or requirements to remain a maintainer. + +- How are maintainer decisions made, is there a record of maintainer decisions? There is reference to a maintainer being removed if they fail to meet “principles of Pixie community” these principles need to be documented, and the criteria for measuring a maintainer against the principles + +- These details are important for conflict resolution, and to attract new leaders who may want clarity in responsibilities and processes, especially for dealing with issues that don’t have universal consensus. + +#### Other + +- Governance document change control. There is no formal policy for approving changes to the governance or other project documents. This process should be formally documented, since the contents of these documents affect the entire organization and every pixienaut. + +- Contributor ladder: The process for “how do I become a contributor/maintainer” needs to be documented, especially the initiation step. + +- Communication and Meetings: There needs to be a public record of meetings, communication, decisions, and provision for community to comment on initiatives. The CNCF slack channel inviter link 404’s. + +- Subprojects: Pixie demo and pixie-plugin are intended to recruit new community contributors. The ReadMe for each sub-project needs more clarity on how to contribute, how inclusion is decided, what the lifecycle is, and expectations for ongoing maintenance of the contributions. + +More details can be found in the [Findings Table](https://github.com/cncf/tag-contributor-strategy/blob/main/governance/reviews/template.md#Governance-Findings-Table) and the related sections below. + + +## Review + +### Governance Description + +Pixie is led by a Governing Board of two maintainers, two end users, and two community users. End users represent people who actively use Pixie. The community users are active members of the Pixie community, but do not have maintainer responsibilities.  There is also a team of five maintainers.  It is not clear how responsibilities are divided between the Board and the maintainers. + + +### Discoverability + +#### Governance Location + +All governance documents are  in the primary repo: +They are easy to find from the Github organization. + +#### Governance Discovery Completeness + +The Governing Board members are listed only at the bottom of a long web page, and not anywhere in the repos alongside the governance documentation, making them hard to find. + + +### Documentation Content + +The following table details the governance areas expected for a project. Coverage is indicated by Complete, Partial, Missing, and Unknown. + +- Complete - the content of the governance documentation is fully detailed and does not leave any question to the reader. + +- Partial - the content of the governance documentation is missing some information and would leave the reader with questions or some level of misunderstanding. + +- Missing - the documentation is absent, wholly undiscoverable, or woefully inadequate in meeting the objectives of that governance content. The reader cannot act on the content that is available. + +- Unknown - status cannot be assessed at this time + +| Governance Area | Coverage |Documents | Finding Notes +|:---|:---|:---|:---| +| Project Purpose | Complete | https\://github.com/pixie-io/pixie/blob/main/README.md | Nicely done. The first line of the readme explains what Pixie is and what a person would use it for | +| Maintainer List | Complete | https\://github.com/pixie-io/pixie/blob/main/MAINTAINERS | | +| Code of Conduct | Complete | https\://github.com/pixie-io/pixie/blob/main/CODE\_OF\_CONDUCT.md | Well done. Project links to CNCF CoC, this is the recommended approach for most projects | +| Contributor Guide | Partial | https\://github.com/pixie-io/pixie/blob/main/CONTRIBUTING.md | Most of the document is well written and easy for “pixienauts” to follow\.The Code contributions section is unclear on how to get started. A template or example to follow would be useful. For newbie contributors, this will lower the barrier to getting started https\://github.com/pixie-io/pixie/blob/main/CONTRIBUTING.md#code-contributions | +| Contributor Ladder | Partial | https\://github.com/pixie-io/pixie/blob/main/GOVERNANCE.md | The Contributors section needs to answer this question “I want to become a maintainer, what do I do? Email/slack someone?”. Recommend providing clear guidance for how to get started, and more generalized  overview of the process | +| Maintainer Lifecycle | Partial | https\://github.com/pixie-io/pixie/blob/main/GOVERNANCE.md#maintainers | Clarity needed for registering interest to become a maintainer, voting new maintainer in, voting them out, recording the decision | +| Decision-making | Partial | https\://github.com/pixie-io/pixie/blob/main/GOVERNANCE.md#decision-making-process | For someone who is not a maintainer, it is difficult to understand how/when/why/what  decisions the maintainer have made.As the project matures, we recommend formalizing + documenting this process | +| Code and Docs Ownership | Missing | | Project is not using a code ownership tool (such as Prow/Sheriff) for permissions management | +| Security Reporting and response | Complete | https\://github.com/pixie-io/pixie/blob/main/SECURITY.md | Well done! A very complete security response process.  The maintainers are the SRC. | +| Communication and Meetings | Partial | | It is not clear if there is a public record of meetings + communication, or how to join meetingsThe CNCF slack channel inviter link 404’s | + + +#### Sub-projects, plugins, and related + +The project includes the following sub-projects, plugins, and other notable divisions: + + +|Area |Ownership and Operation | Standing Bodies | Project Alignment | Notes +|:------------ |:--------------------------- |:------------------- |:--------------------- |:------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| pxapi.go | Complete | Complete | Complete | Readme makes it clear management is via parent project | +| Pixie demos | Missing | Missing | Missing | Its not clear who maintains the sub-project, how demos are added/removed, who makes decisions on the demo curation | +| docs.px.dev | Partial | Partial | Complete | Well done! A really good Readme for using, setting up, how-it-works documentation. Whats missing is sub-project contacts | +| pixie-plugin | Partial | Missing | complete | Another great readme for using/adding a plug in. Whats missing is sub-project contacts, who maintains the list, how decisions for including a plug in is made | + + +## Operation + +Reviewed PR:[ #1964](https://github.com/pixie-io/pixie/pull/1964): Merged. Documented OK. DCO OK. 1 Reviewer: Adequate. Two would be optimal + + +### Transparency and freshness + +The project and all sub-projects look fresh and well-maintained. The maintainers list appears current. What’s missing is a public record of decisions, issues, and community activity. The governance board is a good idea, but again there is no transparency for what the board is doing, or has done. + + +#### Governance Drift + +Governance Drift can occur when the executed and observable governance of a project deviates from the documented governance of the project + +Without the public record, we cannot determine if the project is complying to its own governance. The governance policies do enable governance drift - and this may be problematic as the project matures. For example: “The Pixie organization will never forcefully remove a current Maintainer, unless a maintainer fails to meet the principles of Pixie community, or adhere to the Code of Conduct.” There are two problems with this policy: The principles of the Pixie community are not defined in the document; and the process for forcefully removing a current maintainer (if they do violate principles of Pixie community or code of conduct) are not defined. + +#### Ownership + +The project's ownership evaluation did not leverage Sheriff, the CNCF GitHub permission auditing tool.  +We don’t see any obvious permission problems, but the project is not yet using Sheriff, Prow or a similar tool for enforcing permissions. + +### Maintainer List(s) + +The project's maintainer list(s) are current.  + +Checking the maintainer against PRs, for six months (to 1 Aug 2024): Zain Asgar does not appear to be contributing code to the project.  It is possible that his contributions are of a non-code variety.. + +Individuals on the maintainer list do appear to match the requirements of maintainership in accordance with the project's documented requirements. The maintainer affiliations (employers) reflect Balanced diversity. See the earlier recommendations on formalizing the  processes, so the project continues to meet the standard. + + +### Evolution + +Not considered + + +### Governance Findings Table + +| Finding Title | Importance | Description | Links | Notes & Impact +|:--|:--|:--|:--|:--| +| Governance board role unclear | Medium | Responsibilities + ownership + decision making are not differentiated from maintainers | | Potential conflict between board and maintainers | +| Governance board lifecycle incomplete | Medium | Process for adding/removing members not documented. Requirements for remaining a member of the board are not documented. Board’s decisions/actions/recommendations are not public | | No transparency for the board’s operation | +| Maintainer lifecycle incomplete | Medium | There is no policy for applying to be a maintainer, voting-in, voting-out or requirements to remain a maintainer | | Needed for the project as it matures, adds new people and may need to remove maintainers | +| Governance document change control | Medium | No policy for approving changes to the governance or other project documents | | No transparency or controls for governance changes | +| Contributor ladder incomplete | Medium | The process for “how do I become a contributor/maintainer” needs to be documented, especially the initiation step | | Barrier to community involvement | +