-
Notifications
You must be signed in to change notification settings - Fork 23
Reference governance files in the community repository #125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,61 +1,3 @@ | ||
| # Contributors' Guide | ||
|
|
||
| ## Getting started | ||
|
|
||
| Welcome to the Cloud Native AI Model Format Specification project! We are excited to have you contribute. Here are some steps to help you get started. | ||
|
|
||
| ## Setting up your local environment | ||
|
|
||
| * **Clone the repository**: | ||
|
|
||
| ```sh | ||
| git clone https://github.com/modelpack/model-spec.git | ||
| cd model-spec | ||
| ``` | ||
|
|
||
| * **Install dependencies**: Ensure you have [Go](https://go.dev/) installed, as the current spec implementation is written in Go. Follow the [official instructions to install Go](https://go.dev/doc/install). | ||
|
|
||
| ## Where to put changes | ||
|
|
||
| Right now, we have a simple directory structure: | ||
|
|
||
| * `docs`: All detailed documents about the model spec. | ||
| * `docs/img`: Any referenced images in the documents should be put here. | ||
| * `specs-go`: A Go implementation of the model specification. | ||
|
|
||
| ## Raise a pull request | ||
|
|
||
| * **Create a new branch**: | ||
|
|
||
| ```sh | ||
| git checkout -b your-branch-name | ||
| ``` | ||
|
|
||
| * **Make your changes and commit them**: | ||
|
|
||
| ```sh | ||
| git add . | ||
| git commit -s -m "Your descriptive commit message" | ||
| ``` | ||
|
|
||
| * **Push your changes to your fork**: | ||
|
|
||
| ```sh | ||
| git push your-fork-repo your-branch-name | ||
| ``` | ||
|
|
||
| * **Open a pull request**: Go to the GitHub repository, compare your branch, and submit a pull request with a detailed description of your changes. | ||
|
|
||
| ## Make sure pull request CI passes | ||
|
|
||
| Please check the CI status in your pull request and fix anything that fails. Here are some simple instructions to validate CI locally. | ||
|
|
||
| * **Install golangci-lint**: follow the [official installation guide](https://golangci-lint.run/welcome/install/#local-installation) to install golangci-lint. | ||
|
|
||
| * **Check for linting issues**: | ||
|
|
||
| ```sh | ||
| golangci-lint run --verbose | ||
| ``` | ||
|
|
||
| We appreciate your contributions and look forward to working with you! | ||
| Please refer to the project's [community contributors' guide](https://github.com/modelpack/community/blob/main/CONTRIBUTING.md) for guidelines on how to contribute to the project. | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,87 +1,3 @@ | ||
| # Project Governance | ||
|
|
||
| The ModelSpec project is dedicated to creating a universal, vendor-neutral standard for packaging, versioning, and running AI/ML projects that aligns with the OCI specification. The ModelSpec is especially important for organizations who are self-hosting models (open source, or self-built) and want to be able to use the tools and processes they've proven with containers, to manage their AI/ML project lifecycle. | ||
|
|
||
| This is not an implementation, it is the specification on which compliant implementations can be built. | ||
|
|
||
| This governance document explains how the project is run. | ||
|
|
||
| - [Values](#values) | ||
| - [Maintainers](#maintainers) | ||
| - [Becoming a Maintainer](#becoming-a-maintainer) | ||
| - [Meetings](#meetings) | ||
| - [Code of Conduct Enforcement](#code-of-conduct) | ||
| - [Modifications](#modifying-this-charter) | ||
|
|
||
| ## Values | ||
|
|
||
| The ModelSpec project leadership embraces the following values: | ||
|
|
||
| - **Openness**: Communication and decision-making happens in the open and is discoverable for future reference. As much as possible, all discussions and work take place in public forums and open repositories. | ||
|
|
||
| - **Fairness**: All stakeholders have the opportunity to provide feedback and submit contributions, which will be considered on their merits. | ||
|
|
||
| - **Community over Product or Company**: Sustaining and growing our community takes priority over shipping code or sponsors' organizational goals. Each contributor participates in the project as an individual. | ||
|
|
||
| - **Inclusivity**: We innovate through different perspectives and skill sets, which can only be accomplished in a welcoming and respectful environment. | ||
|
|
||
| - **Participation**: Responsibilities within the project are earned through participation, and there is a clear path up the contributor ladder into leadership positions. | ||
|
|
||
| ## Maintainers | ||
|
|
||
| ModelSpec maintainers have write access to the [project GitHub repository](https://github.com/modelpack/model-spec). They can merge patches and are expected to review large or critical patches personally. The current maintainers can be found in [MAINTAINERS.md](./MAINTAINERS.md). Maintainers collectively manage the project's resources and contributors. | ||
|
|
||
| This privilege is granted with some expectation of responsibility: maintainers are people who care about the ModelSpec project and want to help it grow and improve. A maintainer is not just someone who can make changes, but someone who has demonstrated good judgement and an ability to collaborate with the team, get the most knowledgeable people to review code and docs, contribute high-quality code, and follow through to fix issues (in code or tests). | ||
|
|
||
| A maintainer is a contributor to the project's success and a citizen helping the project succeed. | ||
|
|
||
| The collective team of all Maintainers is known as the **Maintainer Council**, which is the governing body for the project. | ||
|
|
||
| ### Becoming a Maintainer | ||
|
|
||
| To become a Maintainer you need to demonstrate the following: | ||
|
|
||
| - **Commitment to the project**: | ||
| - Participate actively and impactfully in discussions, contributions, code and documentation reviews `this will need quantifying eventually` | ||
| - Perform useful reviews for a significant number of non-trivial pull requests `this will need quantifying eventually` | ||
| - Contribute non-trivial pull requests and have them merged `this will need quantifying eventually` | ||
| - Ability to write quality code and/or documentation | ||
| - Ability to collaborate with the team | ||
| - Understanding of how the team works (policies, processes for testing and code review, etc) | ||
| - Understanding of the project's code base and coding and documentation style | ||
|
|
||
| A new Maintainer must be proposed by an existing maintainer by opening an issue with the title "New Maintainer Proposal". A 2/3 vote of existing Maintainers approves the application. Maintainers nominations will be evaluated without prejudice to employer or demographics. | ||
|
|
||
| Maintainers who are selected will be granted the necessary GitHub rights. | ||
|
|
||
| ### Removing a Maintainer | ||
|
|
||
| Maintainers may resign at any time if they feel that they will not be able to continue fulfilling their project duties. | ||
|
|
||
| Maintainers may also be removed after being inactive, failing to fulfill their Maintainer responsibilities, violating the [Code of Conduct](./code-of-conduct.md), or other reasons. Inactivity is defined as a period of very low or no activity in the project for a year or more, with no definite schedule to return to full Maintainer activity. | ||
|
|
||
| A Maintainer may be removed at any time by a 2/3 vote of the remaining maintainers. | ||
|
|
||
| Depending on the reason for removal, a Maintainer may be converted to **Emeritus** status. Emeritus Maintainers will still be consulted on some project matters and can be rapidly returned to Maintainer status if their availability changes. | ||
|
|
||
| ## Meetings | ||
|
|
||
| Time zones permitting, Maintainers are expected to participate in the ModelSpec office hours virtual meeting, which occurs bi-weekly on Thursday at 10:00ET. | ||
|
|
||
| ### ModelSpec Public Office Hours (bi-weekly) | ||
|
|
||
| **Every second Thursday @ 14:00 - 15:00** | ||
| **Time zone**: UTC | ||
| **Video call link**: [Zoom](https://us06web.zoom.us/j/89085916734?pwd=dBaeMvmg9SyWvWj5Caf2i1bNaCf2oJ.1) | ||
| **Meeting ID**: 890 8591 6734 | ||
| **Passcode**: 274899 | ||
|
|
||
| Maintainers may also have closed meetings in order to discuss sensitive matters or Code of Conduct violations. Such meetings should be scheduled by any Maintainer on receipt of a CoC report. All current Maintainers must be invited to such closed meetings, except for any Maintainer who is accused of a CoC violation. | ||
|
|
||
| ## Code of Conduct | ||
|
|
||
| Everything we do in the ModelSpec community is governed by our [Code of Conduct](./code-of-conduct.md). Violations by community members will be discussed and resolved by the Maintainers in their private Discord channel. If a Maintainer is directly involved in the report, the Maintainers will instead designate two Maintainers to resolve the issue. | ||
|
|
||
| ## Modifying this Charter | ||
|
|
||
| Changes to this Governance and its supporting documents may be approved by a 2/3 vote of the Maintainers. | ||
| Please refer to the project's [community governance file](https://github.com/modelpack/community/blob/main/GOVERNANCE.md) for details on the governance structure and decision-making processes. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The previous |
||
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -1,15 +1,3 @@ | ||||||
| # Maintainers | ||||||
|
|
||||||
| The current Maintainers for the project are | ||||||
|
|
||||||
| - aftersnow | ||||||
| - bergwolf | ||||||
| - bmicklea | ||||||
| - caozhuozi | ||||||
| - chlins | ||||||
| - gaius-qi | ||||||
| - gorkem | ||||||
| - raravena80 | ||||||
| - sabre1041 | ||||||
| - tarilabs | ||||||
| - wy65701436 | ||||||
| Please refer to [the project's community maintainers file](https://github.com/modelpack/community/blob/main/MAINTAINERS.md) for the list of maintainers and their roles. | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For consistency with the other updated documentation files (
Suggested change
|
||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change removes repository-specific contribution guidelines, such as environment setup (Go installation,
golangci-lint) and local CI validation steps. While centralizing documentation is a good goal, losing this specific information could make it harder for new contributors to get started on this repository. Please consider whether this information is present in the new community contributors' guide, or if it should be preserved here alongside the link to the general guide. For example, you could have a section for repository-specific setup instructions.