github.com/pdmccormick/importable-docker-buildx@v0.0.0-20240426161518-e47091289030/MAINTAINERS (about)

     1  # Buildx maintainers file
     2  #
     3  # This file describes the maintainer groups within the project.
     4  # More detail on Moby project governance is available in the
     5  # https://github.com/moby/moby/blob/master/project/GOVERNANCE.md file.
     6  #
     7  # It is structured to be consumable by both humans and programs.
     8  # To extract its contents programmatically, use any TOML-compliant
     9  # parser.
    10  #
    11  
    12  [Rules]
    13  
    14  		[Rules.maintainers]
    15  
    16  		title = "What is a maintainer?"
    17  
    18  		text = """
    19  There are different types of maintainers, with different
    20  responsibilities, but all maintainers have 3 things in common:
    21  
    22  1) They share responsibility in the project's success.
    23  2) They have made a long-term, recurring time investment to improve
    24     the project.
    25  3) They spend that time doing whatever needs to be done, not
    26     necessarily what is the most interesting or fun.
    27  
    28  Maintainers are often under-appreciated, because their work is harder
    29  to appreciate.  It's easy to appreciate a really cool and technically
    30  advanced feature. It's harder to appreciate the absence of bugs, the
    31  slow but steady improvement in stability, or the reliability of a
    32  release process. But those things distinguish a good project from a
    33  great one.
    34  """
    35  
    36  		[Rules.adding-maintainers]
    37  
    38  		title = "How are maintainers added?"
    39  
    40  		text = """
    41  Maintainers are first and foremost contributors that have shown they
    42  are committed to the long term success of a project. Contributors
    43  wanting to become maintainers are expected to be deeply involved in
    44  contributing code, pull request review, and triage of issues in the
    45  project for more than three months.
    46  
    47  Just contributing does not make you a maintainer, it is about building
    48  trust with the current maintainers of the project and being a person
    49  that they can depend on and trust to make decisions in the best
    50  interest of the project.
    51  
    52  Periodically, the existing maintainers curate a list of contributors
    53  that have shown regular activity on the project over the prior
    54  months. From this list, maintainer candidates are selected.
    55  
    56  After a candidate has been announced, the existing maintainers are
    57  given five business days to discuss the candidate, raise objections
    58  and cast their vote. Candidates must be approved by at least 66% of
    59  the current maintainers by adding their vote on the slack
    60  channel. Only maintainers of the repository that the candidate is
    61  proposed for are allowed to vote.
    62  
    63  If a candidate is approved, a maintainer will contact the candidate to
    64  invite the candidate to open a pull request that adds the contributor
    65  to the MAINTAINERS file. The candidate becomes a maintainer once the
    66  pull request is merged.
    67  """
    68  
    69  		[Rules.stepping-down-policy]
    70  
    71  		title = "Stepping down policy"
    72  
    73  		text = """
    74  Life priorities, interests, and passions can change. If you're a
    75  maintainer but feel you must remove yourself from the list, inform
    76  other maintainers that you intend to step down, and if possible, help
    77  find someone to pick up your work.  At the very least, ensure your
    78  work can be continued where you left off.
    79  
    80  After you've informed other maintainers, create a pull request to
    81  remove yourself from the MAINTAINERS file.
    82  """
    83  
    84  		[Rules.inactive-maintainers]
    85  
    86  		title = "Removal of inactive maintainers"
    87  
    88  		text = """
    89  Similar to the procedure for adding new maintainers, existing
    90  maintainers can be removed from the list if they do not show
    91  significant activity on the project. Periodically, the maintainers
    92  review the list of maintainers and their activity over the last three
    93  months.
    94  
    95  If a maintainer has shown insufficient activity over this period, a
    96  neutral person will contact the maintainer to ask if they want to
    97  continue being a maintainer. If the maintainer decides to step down as
    98  a maintainer, they open a pull request to be removed from the
    99  MAINTAINERS file.
   100  
   101  If the maintainer wants to remain a maintainer, but is unable to
   102  perform the required duties they can be removed with a vote of at
   103  least 66% of the current maintainers.  The voting period is five
   104  business days. Issues related to a maintainer's performance should be
   105  discussed with them among the other maintainers so that they are not
   106  surprised by a pull request removing them.
   107  """
   108  
   109  		[Rules.DCO]
   110  
   111  		title = "Helping contributors with the DCO"
   112  
   113  		text = """
   114  The [DCO or `Sign your work`](
   115  https://github.com/moby/buildkit/blob/master/CONTRIBUTING.md#sign-your-work)
   116  requirement is not intended as a roadblock or speed bump.
   117  
   118  Some BuildKit contributors are not as familiar with `git`, or have
   119  used a web based editor, and thus asking them to `git commit --amend
   120  -s` is not the best way forward.
   121  
   122  In this case, maintainers can update the commits based on clause (c)
   123  of the DCO.  The most trivial way for a contributor to allow the
   124  maintainer to do this, is to add a DCO signature in a pull requests's
   125  comment, or a maintainer can simply note that the change is
   126  sufficiently trivial that it does not substantially change the
   127  existing contribution - i.e., a spelling change.
   128  
   129  When you add someone's DCO, please also add your own to keep a log.
   130  """
   131  
   132  		[Rules."no direct push"]
   133  
   134  		title = "I'm a maintainer. Should I make pull requests too?"
   135  
   136  		text = """
   137  Yes. Nobody should ever push to master directly. All changes should be
   138  made through a pull request.
   139  """
   140  
   141  		[Rules.meta]
   142  
   143  		title = "How is this process changed?"
   144  
   145  		text = "Just like everything else: by making a pull request :)"
   146  
   147  
   148  [Org]
   149  
   150  	[Org.Maintainers]
   151  
   152  		people = [
   153  			"akihirosuda",
   154  			"crazy-max",
   155  			"jedevc",
   156  			"tiborvass",
   157  			"tonistiigi",
   158  		]
   159  
   160  	[Org.Curators]
   161  
   162  	# The curators help ensure that incoming issues and pull requests are properly triaged and
   163  	# that our various contribution and reviewing processes are respected. With their knowledge of
   164  	# the repository activity, they can also guide contributors to relevant material or
   165  	# discussions.
   166  	#
   167  	# They are neither code nor docs reviewers, so they are never expected to merge. They can
   168  	# however:
   169  	# - close an issue or pull request when it's an exact duplicate
   170  	# - close an issue or pull request when it's inappropriate or off-topic
   171  
   172  		people = [
   173  			"thajeztah",
   174  		]
   175  
   176  [people]
   177  
   178  # A reference list of all people associated with the project.
   179  # All other sections should refer to people by their canonical key
   180  # in the people section.
   181  
   182  	[people.akihirosuda]
   183  	Name = "Akihiro Suda"
   184  	Email = "akihiro.suda.cz@hco.ntt.co.jp"
   185  	GitHub = "AkihiroSuda"
   186  
   187  	[people.crazy-max]
   188  	Name = "Kevin Alvarez"
   189  	Email = "contact@crazymax.dev"
   190  	GitHub = "crazy-max"
   191  
   192  	[people.jedevc]
   193  	Name = "Justin Chadwell"
   194  	Email = "me@jedevc.com"
   195  	GitHub = "jedevc"
   196  
   197  	[people.thajeztah]
   198  	Name = "Sebastiaan van Stijn"
   199  	Email = "github@gone.nl"
   200  	GitHub = "thaJeztah"
   201  
   202  	[people.tiborvass]
   203  	Name = "Tibor Vass"
   204  	Email = "tibor@docker.com"
   205  	GitHub = "tiborvass"
   206  
   207  	[people.tonistiigi]
   208  	Name = "Tõnis Tiigi"
   209  	Email = "tonis@docker.com"
   210  	GitHub = "tonistiigi"