Initial setup

CONTRIBUTING.md

@@ -0,0 +1,154 @@
+# Contributing
+
+Contributions should be made via pull requests. Pull requests will be reviewed
+by one or more maintainers and merged when acceptable.
+
+The goal of the ModelPack project is to build a vendor-neutral, open source
+specification standard to package, distribute and run AI models in a cloud native
+environments.
+
+When developing features inside the ModelPack project, changes should be focused
+towards building general functionalities to help broader cloud native and AI ecosystem.
+Some features may be useful in specific scenarios, however, they may not be appropriate
+to be part of the ModelPack project.
+
+## Successful Changes
+
+We ask that before contributing, please make the effort to coordinate with the
+maintainers of the project before submitting large or high impact PRs. This
+will prevent you from doing extra work that may or may not be merged.
+
+PRs that are just submitted without any prior communication will likely be
+summarily closed.
+
+While pull requests are the methodology for submitting changes to code, changes
+are much more likely to be accepted if they are accompanied by additional
+engineering work. While we don't define this explicitly, most of these goals
+are accomplished through communication of the design goals and subsequent
+solutions. Often times, it helps to first state the problem before presenting
+solutions.
+
+Typically, the best methods of accomplishing this are to submit an issue,
+stating the problem. This issue can include a problem statement and a
+checklist with requirements. If solutions are proposed, alternatives should be
+listed and eliminated. Even if the criteria for elimination of a solution is
+frivolous, say so.
+
+Larger changes typically work best with design documents. These are focused
+on providing context to the design at the time the feature was conceived and can
+inform future documentation contributions.
+
+Make sure that new tests are added for bugs in order to catch regressions and tests
+with new features to exercise the new functionality that is added.
+
+## Commit Messages
+
+There are times for one line commit messages and this is not one of them.
+Commit messages should follow best practices, including explaining the context
+of the problem and how it was solved, including in caveats or follow up changes
+required. They should tell the story of the change and provide readers
+understanding of what led to it.
+
+If you're lost about what this even means, please see [How to Write a Git
+Commit Message](http://chris.beams.io/posts/git-commit/) for a start.
+
+In practice, the best approach to maintaining a nice commit message is to
+leverage a `git add -p` and `git commit --amend` to formulate a solid
+changeset. This allows one to piece together a change, as information becomes
+available.
+
+If you squash a series of commits, don't just submit that. Re-write the commit
+message, as if the series of commits was a single stroke of brilliance.
+
+That said, there is no requirement to have a single commit for a PR, as long as
+each commit tells the story. For example, if there is a feature that requires a
+package, it might make sense to have the package in a separate commit then have
+a subsequent commit that uses it.
+
+If there are multiple authors who worked together on a PR that needs to be squashed,
+please use `Co-authored-by` to indicate each person who contributed to the PR. This
+enables automated tools
+and [Github](https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors)
+to highlight everyone's role in the PR.
+
+Remember, you're telling part of the story with the commit message. Don't make
+your chapter weird.
+
+## Applying License Header to New Files
+
+If you submit a contribution that adds a new file, please add the license
+header.
+
+```console
+/*
+ *     Copyright 2025 The CNCF ModelPack Authors
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *      http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+```
+
+The above is an example license header we use in the ModelPack project.
+
+## Sign your work
+
+The sign-off is a simple line at the end of the explanation for the patch. Your
+signature certifies that you wrote the patch or otherwise have the right to pass
+it on as an open-source patch. The rules are pretty simple: if you can certify
+the below (from [developercertificate.org](http://developercertificate.org/)):
+
+```
+Developer Certificate of Origin
+Version 1.1
+
+Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
+660 York Street, Suite 102,
+San Francisco, CA 94110 USA
+
+Everyone is permitted to copy and distribute verbatim copies of this
+license document, but changing it is not allowed.
+
+Developer's Certificate of Origin 1.1
+
+By making a contribution to this project, I certify that:
+
+(a) The contribution was created in whole or in part by me and I
+    have the right to submit it under the open source license
+    indicated in the file; or
+
+(b) The contribution is based upon previous work that, to the best
+    of my knowledge, is covered under an appropriate open source
+    license and I have the right under that license to submit that
+    work with modifications, whether created in whole or in part
+    by me, under the same open source license (unless I am
+    permitted to submit under a different license), as indicated
+    in the file; or
+
+(c) The contribution was provided directly to me by some other
+    person who certified (a), (b) or (c) and I have not modified
+    it.
+
+(d) I understand and agree that this project and the contribution
+    are public and that a record of the contribution (including all
+    personal information I submit with it, including my sign-off) is
+    maintained indefinitely and may be redistributed consistent with
+    this project or the open source license(s) involved.
+```
+
+Then you just add a line to every git commit message:
+
+    Signed-off-by: Joe Smith <[email protected]>
+
+Use your real name (sorry, no pseudonyms or anonymous contributions.)
+
+If you set your `user.name` and `user.email` git configs, you can sign your
+commit automatically with `git commit -s`.

GOVERNANCE.md

@@ -0,0 +1,87 @@
+# Project Governance
+
+The ModelPack 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 ModelPack 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 ModelPack 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
+
+ModelPack 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 ModelPack 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 ModelPack office hours virtual meeting, which occurs bi-weekly on Thursday at 10:00ET.
+
+### ModelPack Public Office Hours (bi-weekly)
+
+**Every second Thursday @ 14:00 - 15:00**
+**Time zone**: UTC
+**Video call link**: [Zoom](https://zoom.us/j/99127808948?pwd=CggVIWsBPt1jUSbLaWCTcgaHpDB2tl.1)
+**Meeting ID**: 991 2780 8948
+**Passcode**: 644187
+
+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 ModelPack 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.

code-of-conduct.md

@@ -0,0 +1,3 @@
+# CNCF ModelPack Community Code of Conduct
+
+The CNCF ModelPack Specification project follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md).