diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md deleted file mode 100644 index 92cc80c1b..000000000 --- a/CONTRIBUTING.md +++ /dev/null @@ -1,134 +0,0 @@ -# Contributing - -Contributions should be made via pull requests. Pull requests will be reviewed -by one or more maintainers and merged when acceptable. - -This project is in an early state, making the impact of contributions much -greater than at other stages. In this respect, it is important to consider any -changes or additions for their future impact more so than their current impact. - -## 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, similar to those found -in `design/`. 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. - -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. You can do so manually or use the `ltag` tool: - - -```console -$ go get github.com/kunalkushwaha/ltag -$ ltag -t ./script/validate/template -``` - -The above will add the appropriate license header to Go language source files, - Makefiles, Dockerfiles, and shell scripts. New templates will need to be added - if other kinds of files are added. Please consult the -documentation at https://github.com/kunalkushwaha/ltag - -## 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 - -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`. diff --git a/MAINTAINERS b/MAINTAINERS deleted file mode 100644 index 2cf002cd7..000000000 --- a/MAINTAINERS +++ /dev/null @@ -1,332 +0,0 @@ -# containerd project maintainers file -# -# This file describes who runs the containerd project and how. -# This is a living document - if you see something out of date or missing, -# speak up! -# -# It is structured to be consumable by both humans and programs. -# To extract its contents programmatically, use any TOML-compliant -# parser. - -[Rules] - - [Rules.maintainers] - - title = "What is a maintainer?" - - text = """ -There are different types of maintainers, with different responsibilities, but -all maintainers have 3 things in common: - -1) They share responsibility in the project's success. -2) They have made a long-term, recurring time investment to improve the project. -3) They spend that time doing whatever needs to be done, not necessarily what -is the most interesting or fun. - -Maintainers are often under-appreciated, because their work is harder to appreciate. -It's easy to appreciate a really cool and technically advanced feature. It's harder -to appreciate the absence of bugs, the slow but steady improvement in stability, -or the reliability of a release process. But those things distinguish a good -project from a great one. -""" - - [Rules.reviewer] - - title = "What is a reviewer?" - - text = """ -A reviewer is a core role within the project. -They share in reviewing issues and pull requests and their LGTM count towards the -required LGTM count to merge a code change into the project. - -Reviewers are part of the organization but do not have write access. -Becoming a reviewer is a core aspect in the journey to becoming a maintainer. -""" - - [Rules.adding-maintainers] - - title = "How are maintainers added?" - - text = """ -Maintainers are first and foremost contributors that have shown they are -committed to the long term success of a project. Contributors wanting to become -maintainers are expected to be deeply involved in contributing code, pull -request review, and triage of issues in the project for more than three months. - -Just contributing does not make you a maintainer, it is about building trust -with the current maintainers of the project and being a person that they can -depend on and trust to make decisions in the best interest of the project. - -Periodically, the existing maintainers curate a list of contributors that have -shown regular activity on the project over the prior months. From this list, -maintainer candidates are selected and proposed on the maintainers mailing list. - -After a candidate has been announced on the maintainers mailing list, the -existing maintainers are given five business days to discuss the candidate, -raise objections and cast their vote. Votes may take place on the mailing list -or via pull request comment. Candidates must be approved by at least 66% of the -current maintainers by adding their vote on the mailing list. The reviewer role -has the same process but only requires 33% of current maintainers. Only -maintainers of the repository that the candidate is proposed for are allowed to -vote. - -If a candidate is approved, a maintainer will contact the candidate to invite -the candidate to open a pull request that adds the contributor to the -MAINTAINERS file. The voting process may take place inside a pull request if a -maintainer has already discussed the candidacy with the candidate and a -maintainer is willing to be a sponsor by opening the pull request. The candidate -becomes a maintainer once the pull request is merged. -""" - - [Rules.adding-sub-projects] - - title = "How are sub projects added?" - - text = """ -Similar to adding maintainers, new sub projects can be added to containerd -GitHub organization as long as they adhere to the CNCF -[charter](https://www.cncf.io/about/charter/) and mission. After a project -proposal has been announced on a public forum (GitHub issue or mailing list), -the existing maintainers are given five business days to discuss the new -project, raise objections and cast their vote. Projects must be approved by at -least 66% of the current maintainers by adding their vote. - -If a project is approved, a maintainer will add the project to the containerd -GitHub organization, and make an announcement on a public forum. -""" - - [Rules.stepping-down-policy] - - title = "Stepping down policy" - - text = """ -Life priorities, interests, and passions can change. If you're a maintainer but -feel you must remove yourself from the list, inform other maintainers that you -intend to step down, and if possible, help find someone to pick up your work. -At the very least, ensure your work can be continued where you left off. - -After you've informed other maintainers, create a pull request to remove -yourself from the MAINTAINERS file. -""" - - [Rules.inactive-maintainers] - - title = "Removal of inactive maintainers" - - text = """ -Similar to the procedure for adding new maintainers, existing maintainers can -be removed from the list if they do not show significant activity on the -project. Periodically, the maintainers review the list of maintainers and their -activity over the last three months. - -If a maintainer has shown insufficient activity over this period, a neutral -person will contact the maintainer to ask if they want to continue being -a maintainer. If the maintainer decides to step down as a maintainer, they -open a pull request to be removed from the MAINTAINERS file. - -If the maintainer wants to remain a maintainer, but is unable to perform the -required duties they can be removed with a vote of at least 66% of -the current maintainers. An e-mail is sent to the -mailing list, inviting maintainers of the project to vote. The voting period is -five business days. Issues related to a maintainer's performance should be -discussed with them among the other maintainers so that they are not surprised -by a pull request removing them. -""" - - [Rules.decisions] - - title = "How are decisions made?" - - text = """ -Short answer: EVERYTHING IS A PULL REQUEST. - -containerd is an open-source project with an open design philosophy. This means -that the repository is the source of truth for EVERY aspect of the project, -including its philosophy, design, road map, and APIs. *If it's part of the -project, it's in the repo. If it's in the repo, it's part of the project.* - -As a result, all decisions can be expressed as changes to the repository. An -implementation change is a change to the source code. An API change is a change -to the API specification. A philosophy change is a change to the philosophy -manifesto, and so on. - -All decisions affecting containerd, big and small, follow the same 3 steps: - -* Step 1: Open a pull request. Anyone can do this. - -* Step 2: Discuss the pull request. Anyone can do this. - -* Step 3: Merge or refuse the pull request. Who does this depends on the nature -of the pull request and which areas of the project it affects. -""" - - [Rules.DCO] - - title = "Helping contributors with the DCO" - - text = """ -The [DCO or `Sign your work`]( -https://github.com/containerd/containerd/blob/master/CONTRIBUTING.md#sign-your-work) -requirement is not intended as a roadblock or speed bump. - -Some containerd contributors are not as familiar with `git`, or have used a web -based editor, and thus asking them to `git commit --amend -s` is not the best -way forward. - -In this case, maintainers can update the commits based on clause (c) of the DCO. -The most trivial way for a contributor to allow the maintainer to do this, is to -add a DCO signature in a pull requests's comment, or a maintainer can simply -note that the change is sufficiently trivial that it does not substantially -change the existing contribution - i.e., a spelling change. - -When you add someone's DCO, please also add your own to keep a log. -""" - - [Rules."no direct push"] - - title = "I'm a maintainer. Should I make pull requests too?" - - text = """ -Yes. Nobody should ever push to master directly. All changes should be -made through a pull request. -""" - - [Rules.tsc] - - title = "Conflict Resolution and technical disputes" - - text = """ -containerd defers to the [Technical Steering Committee](https://github.com/moby/tsc) for escalations and resolution on disputes for technical matters." - """ - - [Rules.meta] - - title = "How is this process changed?" - - text = "Just like everything else: by making a pull request :)" - -# Current project organization -[Org] - - [Org.Maintainers] - people = [ - "akihirosuda", - "crosbymichael", - "dqminh", - "dmcgowan", - "estesp", - "hqhq", - "jhowardmsft", - "mlaventure", - "stevvooe", - "abhi", - "dchen1107", - "Random-Liu", - "mikebrow", - "yujuhong", - ] - [Org.Reviewers] - people = [ - "dnephin", - "ehazlett", - "jessvalarezo", - "yanxuean", - "miaoyq", - ] - -[People] - - [people.akihirosuda] - Name = "Akihiro Suda" - Email = "suda.akihiro@lab.ntt.co.jp" - GitHub = "AkihiroSuda" - - [People.crosbymichael] - Name = "Michael Crosby" - Email = "crosbymichael@gmail.com" - GitHub = "crosbymichael" - - [People.dqminh] - Name = "Daniel, Dao Quang Minh" - Email = "dqminh89@gmail.com" - GitHub = "dqminh" - - [people.dmcgowan] - Name = "Derek McGowan" - Email = "derek@mcgstyle.net" - GitHub = "dmcgowan" - - [people.ehazlett] - Name = "Evan Hazlett" - Email = "ejhazlett@gmail.com" - Github = "ehazlett" - - [People.estesp] - Name = "Phil Estes" - Email = "estesp@gmail.com" - GitHub = "estesp" - - [People.hqhq] - Name = "Qiang Huang" - Email = "h.huangqiang@huawei.com" - GitHub = "hqhq" - - [People.jhowardmsft] - Name = "John Howard" - Email = "jhoward@microsoft.com" - GitHub = "jhowardmsft" - - [People.mlaventure] - Name = "Kenfe-Mickaël Laventure" - Email = "mickael.laventure@gmail.com" - GitHub = "mlaventure" - - [People.stevvooe] - Name = "Stephen Day" - Email = "stephen.day@docker.com" - GitHub = "stevvooe" - - [People.jessvalarezo] - Name = "Jessica Valarezo" - Email = "valarezo.jessica@gmail.com" - GitHub = "jessvalarezo" - - [People.dnephin] - Name = "Daniel Nephin" - Email = "dnephin@gmail.com" - GitHub = "dnephin" - - [people.abhi] - Name = "Abhinandan Prativadi" - Email = "aprativadi@gmail.com" - GitHub = "abhi" - - [people.dchen1107] - Name = "Dawn Chen" - Email = "dawnchen@google.com" - GitHub = "dchen1107" - - [people.Random-Liu] - Name = "Lantao Liu" - Email = "lantaol@google.com" - GitHub = "Random-Liu" - - [people.mikebrow] - Name = "Mike Brown" - Email = "brownwm@us.ibm.com" - GitHub = "mikebrow" - - [people.yujuhong] - Name = "Yu-Ju Hong" - Email = "yjhong@google.com" - GitHub = "yujuhong" - - [people.yanxuean] - Name = "Xuean Yan" - Email = "yan.xuean@zte.com.cn" - GitHub = "yanxuean" - - [people.miaoyq] - Name = "Yanqiang Miao" - Email = "miao.yanqiang@zte.com.cn" - GitHub = "miaoyq" diff --git a/README.md b/README.md index c4d9dffdb..2181873fc 100644 --- a/README.md +++ b/README.md @@ -236,3 +236,16 @@ The containerd codebase is released under the [Apache 2.0 license](LICENSE.code) The README.md file, and files in the "docs" folder are licensed under the Creative Commons Attribution 4.0 International License. You may obtain a copy of the license, titled CC-BY-4.0, at http://creativecommons.org/licenses/by/4.0/. + +## Project details + +**containerd** is the primary open source project within the broader containerd GitHub repository. +However, all projects within the repo have common maintainership, governance, and contributing +guidelines which are stored in a `project` repository commonly for all containerd projects. + +Please find all these core project documents, including the: + * [Project governance](https://github.com/containerd/project/blob/master/GOVERNANCE.md), + * [Maintainers](https://github.com/containerd/project/blob/master/MAINTAINERS), + * and [Contributing guidelines](https://github.com/containerd/project/blob/master/CONTRIBUTING.md) + +information in our [`containerd/project`](https://github.com/containerd/project) repository.