docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add diogo and nathan as security maintainers. 

Updated my email.

Also retabbed the whole file... I am OCD.

Signed-off-by: Jessica Frazelle <princess@docker.com>
This commit is contained in:
Jessica Frazelle 2015-05-21 12:16:06 -07:00
parent 523d2f6a04
commit 7c6cab6345
1 changed files with 49 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

86
MAINTAINERS
View File

@ -296,7 +296,9 @@ made through a pull request.
[Org.Operators.security] [Org.Operators.security]
people = [ people = [
"erw" "erw",
"diogomonica",
"nathanmccauley"
] ]
[Org.Operators."monthly meetings"] [Org.Operators."monthly meetings"]
@ -327,13 +329,13 @@ made through a pull request.
# The community manager is responsible for serving the project community, including users, # The community manager is responsible for serving the project community, including users,
# contributors and partners. This involves: # contributors and partners. This involves:
# - facilitating communication between maintainers, contributors and users # - facilitating communication between maintainers, contributors and users
# - organizing contributor and maintainer events # - organizing contributor and maintainer events
# - helping new contributors get involved # - helping new contributors get involved
# - anything the project community needs to be successful # - anything the project community needs to be successful
# #
# The community manager is a point of contact for any contributor who has questions, concerns # The community manager is a point of contact for any contributor who has questions, concerns
# or feedback about project operations. # or feedback about project operations.
"Community Manager" = "theadactyl" "Community Manager" = "theadactyl"
[Org."Core maintainers"] [Org."Core maintainers"]
@ -382,43 +384,43 @@ made through a pull request.
# 1. Exposing a clear road map for improving their subsystem. # 1. Exposing a clear road map for improving their subsystem.
# 2. Deliver prompt feedback and decisions on pull requests affecting their subsystem. # 2. Deliver prompt feedback and decisions on pull requests affecting their subsystem.
# 3. Be available to anyone with questions, bug reports, criticism etc. # 3. Be available to anyone with questions, bug reports, criticism etc.
# on their component. This includes IRC, GitHub requests and the mailing # on their component. This includes IRC, GitHub requests and the mailing
# list. # list.
# 4. Make sure their subsystem respects the philosophy, design and # 4. Make sure their subsystem respects the philosophy, design and
# road map of the project. # road map of the project.
# #
# #### How to review patches to your subsystem # #### How to review patches to your subsystem
# #
# Accepting pull requests: # Accepting pull requests:
# #
# - If the pull request appears to be ready to merge, give it a `LGTM`, which # - If the pull request appears to be ready to merge, give it a `LGTM`, which
# stands for "Looks Good To Me". # stands for "Looks Good To Me".
# - If the pull request has some small problems that need to be changed, make # - If the pull request has some small problems that need to be changed, make
# a comment adressing the issues. # a comment adressing the issues.
# - If the changes needed to a PR are small, you can add a "LGTM once the # - If the changes needed to a PR are small, you can add a "LGTM once the
# following comments are adressed..." this will reduce needless back and # following comments are adressed..." this will reduce needless back and
# forth. # forth.
# - If the PR only needs a few changes before being merged, any MAINTAINER can # - If the PR only needs a few changes before being merged, any MAINTAINER can
# make a replacement PR that incorporates the existing commits and fixes the # make a replacement PR that incorporates the existing commits and fixes the
# problems before a fast track merge. # problems before a fast track merge.
# #
# Closing pull requests: # Closing pull requests:
# #
# - If a PR appears to be abandoned, after having attempted to contact the # - If a PR appears to be abandoned, after having attempted to contact the
# original contributor, then a replacement PR may be made. Once the # original contributor, then a replacement PR may be made. Once the
# replacement PR is made, any contributor may close the original one. # replacement PR is made, any contributor may close the original one.
# - If you are not sure if the pull request implements a good feature or you # - If you are not sure if the pull request implements a good feature or you
# do not understand the purpose of the PR, ask the contributor to provide # do not understand the purpose of the PR, ask the contributor to provide
# more documentation. If the contributor is not able to adequately explain # more documentation. If the contributor is not able to adequately explain
# the purpose of the PR, the PR may be closed by any MAINTAINER. # the purpose of the PR, the PR may be closed by any MAINTAINER.
# - If a MAINTAINER feels that the pull request is sufficiently architecturally # - If a MAINTAINER feels that the pull request is sufficiently architecturally
# flawed, or if the pull request needs significantly more design discussion # flawed, or if the pull request needs significantly more design discussion
# before being considered, the MAINTAINER should close the pull request with # before being considered, the MAINTAINER should close the pull request with
# a short explanation of what discussion still needs to be had. It is # a short explanation of what discussion still needs to be had. It is
# important not to leave such pull requests open, as this will waste both the # important not to leave such pull requests open, as this will waste both the
# MAINTAINER's time and the contributor's time. It is not good to string a # MAINTAINER's time and the contributor's time. It is not good to string a
# contributor on for weeks or months, having them make many changes to a PR # contributor on for weeks or months, having them make many changes to a PR
# that will eventually be rejected. # that will eventually be rejected.
[Org.Subsystems.Documentation] [Org.Subsystems.Documentation]
@ -544,6 +546,11 @@ made through a pull request.
Email = "crosbymichael@gmail.com" Email = "crosbymichael@gmail.com"
GitHub = "crosbymichael" GitHub = "crosbymichael"
[people.diogomonica]
Name = "Diogo Monica"
Email = "diogo@docker.com"
GitHub = "diogomonica"
[people.duglin] [people.duglin]
Name = "Doug Davis" Name = "Doug Davis"
Email = "dug@us.ibm.com" Email = "dug@us.ibm.com"
@ -591,7 +598,7 @@ made through a pull request.
[people.jfrazelle] [people.jfrazelle]
Name = "Jessie Frazelle" Name = "Jessie Frazelle"
Email = "jess@docker.com" Email = "j@docker.com"
GitHub = "jfrazelle" GitHub = "jfrazelle"
[people.jlhawn] [people.jlhawn]
@ -609,6 +616,11 @@ made through a pull request.
Email = "mary.anthony@docker.com" Email = "mary.anthony@docker.com"
GitHub = "moxiegirl" GitHub = "moxiegirl"
[people.nathanmccauley]
Name = "Nathan McCauley"
Email = "nathan.mccauley@docker.com"
GitHub = "nathanmccauley"
[people.runcom] [people.runcom]
Name = "Antonio Murdaca" Name = "Antonio Murdaca"
Email = "me@runcom.ninja" Email = "me@runcom.ninja"