aboutsummaryrefslogtreecommitdiff
path: root/vendor/github.com/docker/distribution/MAINTAINERS
diff options
context:
space:
mode:
Diffstat (limited to 'vendor/github.com/docker/distribution/MAINTAINERS')
-rw-r--r--vendor/github.com/docker/distribution/MAINTAINERS243
1 files changed, 0 insertions, 243 deletions
diff --git a/vendor/github.com/docker/distribution/MAINTAINERS b/vendor/github.com/docker/distribution/MAINTAINERS
deleted file mode 100644
index 3183620c5..000000000
--- a/vendor/github.com/docker/distribution/MAINTAINERS
+++ /dev/null
@@ -1,243 +0,0 @@
-# Distribution maintainers file
-#
-# This file describes who runs the docker/distribution 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. Candidates must be approved by at least 66% of the current maintainers by adding their vote on the mailing
-list. 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 candidate becomes a maintainer once the pull request is
-merged.
-"""
-
- [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.
-
-distribution 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 distribution, 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/moby/moby/blob/master/CONTRIBUTING.md#sign-your-work)
-requirement is not intended as a roadblock or speed bump.
-
-Some distribution 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 = """
-distribution 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 = [
- "dmcgowan",
- "dmp42",
- "stevvooe",
- ]
- [Org.Reviewers]
- people = [
- "manishtomar",
- "caervs",
- "davidswu",
- "RobbKistler"
- ]
-
-[people]
-
-# A reference list of all people associated with the project.
-# All other sections should refer to people by their canonical key
-# in the people section.
-
- # ADD YOURSELF HERE IN ALPHABETICAL ORDER
-
- [people.caervs]
- Name = "Ryan Abrams"
- Email = "rdabrams@gmail.com"
- GitHub = "caervs"
-
- [people.davidswu]
- Name = "David Wu"
- Email = "dwu7401@gmail.com"
- GitHub = "davidswu"
-
- [people.dmcgowan]
- Name = "Derek McGowan"
- Email = "derek@mcgstyle.net"
- GitHub = "dmcgowan"
-
- [people.dmp42]
- Name = "Olivier Gambier"
- Email = "olivier@docker.com"
- GitHub = "dmp42"
-
- [people.manishtomar]
- Name = "Manish Tomar"
- Email = "manish.tomar@docker.com"
- GitHub = "manishtomar"
-
- [people.RobbKistler]
- Name = "Robb Kistler"
- Email = "robb.kistler@docker.com"
- GitHub = "RobbKistler"
-
- [people.stevvooe]
- Name = "Stephen Day"
- Email = "stephen.day@docker.com"
- GitHub = "stevvooe"