sigs.k8s.io/gateway-api@v1.0.0/site-src/contributing/contributor-ladder.md (about)

     1  # Contributor Ladder
     2  
     3  Within the Kubernetes community, the concept of a contributor ladder has been
     4  developed to define how individuals can earn formal roles within the project.
     5  The Gateway API contributor ladder largely follows the [roles defined by the
     6  broader Kubernetes
     7  community](https://github.com/kubernetes/community/blob/master/community-membership.md),
     8  though there are some aspects that are unique to this community.
     9  
    10  ## Goals
    11  
    12  We hope that this doc will provide an initial step towards the following goals:
    13  
    14  * Ensure the long term health of the Gateway API community
    15  * Encourage new contributors to work towards formal roles and responsibilities
    16    in the project
    17  * Clearly define the path towards leadership roles
    18  * Develop a strong leadership pipeline so we have great candidates to fill
    19    project leadership roles
    20  
    21  
    22  ## Scope
    23  
    24  The following repositories are covered by this doc:
    25  
    26  * [kubernetes-sigs/gateway-api](https://github.com/kubernetes-sigs/gateway-api)
    27  * [kubernetes-sigs/ingress2gateway](https://github.com/kubernetes-sigs/ingress2gateway)
    28  * kubernetes-sigs/blixt (once migration is complete)
    29  
    30  Within each of these projects, there are opportunities to become an approver or
    31  reviewer for either the entire project, or a subset of that project. For
    32  example, you could become a reviewer or approver focused on just docs, GEPs, API
    33  changes, or conformance tests.
    34  
    35  ## General Guidelines
    36  
    37  ### 1. Everyone is welcome
    38  
    39  We appreciate all contributions. You don’t need to have a formal role in the project to make or review pull requests, and help with issues or discussions. Accepting a formal role within the project is entirely optional.
    40  
    41  ### 2. These roles require continued contributions
    42  
    43  Applying for one of the roles defined above should only be done if you intend to
    44  continue to contribute at a level that would merit that role. If for any reason
    45  you are unable to continue in one of the roles above, please resign. Members
    46  with an extended period away from the project with no activity will be removed
    47  from the Kubernetes GitHub Organizations and will be required to go through the
    48  org membership process again after re-familiarizing themselves with the current
    49  state.
    50  
    51  ### 3. Don’t merge without consensus
    52  
    53  If you have reason to believe that a change may be contentious, please wait for
    54  additional perspectives from others before merging any PRs. Even if you have
    55  access to merge a PR, it doesn’t mean you should. Although we can’t have PRs
    56  blocked indefinitely, we need to make sure everyone has had a chance to present
    57  their perspective.
    58  
    59  ### 4. Start a discussion
    60  
    61  If you’re interested in working towards one of these roles, please reach out to
    62  a Gateway API maintainer on Slack.
    63  
    64  ## Contributor Ladder
    65  
    66  The Gateway API contributor ladder has the following steps:
    67  
    68  1. Member
    69  2. Reviewer
    70  3. Approver
    71  4. Maintainer
    72  
    73  This is also a GAMMA-specific leadership role that does not fit as cleanly on
    74  this ladder. All of these roles will be defined in more detail below.
    75  
    76  ## Member, Reviewer, and Approver
    77  
    78  The first steps on the contributor ladder are already [clearly defined in the
    79  upstream Kubernetes
    80  Community](https://github.com/kubernetes/community/blob/master/community-membership.md#community-membership).
    81  Gateway API follows those guidelines along with the rest of the Kubernetes
    82  community. Within Gateway API, there are a variety of areas one can become a
    83  reviewer or approver, this includes:
    84  
    85  * Conformance
    86  * Documentation
    87  * GEPs
    88  * Webhook Validation
    89  
    90  ## Maintainers and GAMMA Leads
    91  
    92  The final steps on the contributor ladder represent large overall leadership
    93  roles within the project as a whole. The spaces available for these roles are
    94  limited (generally 3-4 people in each role is ideal). Wherever possible, we try
    95  to ensure that different companies are represented in these roles.
    96  
    97  ### Maintainers
    98  
    99  Gateway API Maintainers are known as [Subproject
   100  Owners](https://github.com/kubernetes/community/blob/master/community-membership.md#subproject-owner)
   101  within the Kubernetes community. To become a Gateway API Maintainer, the most
   102  important things we expect are:
   103  
   104  * Long term, sustained contributions to Gateway API for at least 6 months
   105  * Deep understanding of technical goals and direction of the project
   106  * Successfully authored and led significant enhancement proposals
   107  * Approver for at least 3 months
   108  * Ability to lead community meetings
   109  
   110  In addition to all of the expectations described above, we expect maintainers to
   111  set the technical direction and goals for the project. This role is critical to
   112  the health of the project, maintainers should mentor new approvers and
   113  reviewers, and ensure that there are healthy processes in place for discussion
   114  and decision making. Finally, maintainers are ultimately responsible for
   115  releasing new versions of the API.
   116  
   117  ## GAMMA Leads
   118  
   119  The concept of GAMMA Leads does not have a perfect parallel on the upstream
   120  Kubernetes community ladder. They are essentially Subproject Owners, but for the
   121  GAMMA initiative, which is a major initiative within Gateway API.
   122  
   123  To become a GAMMA lead, the most important thing we expect are:
   124  
   125  * Significant experience with Service Mesh implementation(s)
   126  * Deep understanding of technical goals and direction of the project
   127  * Long term, sustained contributions to the GAMMA initiative for at least 6 months
   128  * Ability to lead community meetings
   129  
   130  In addition to all of the expectations described above, we expect GAMMA Leads to
   131  set the technical direction and goals for the GAMMA initiative. They should
   132  ensure that there are healthy processes in place for discussion and decision
   133  making and that the release goals and milestones are clearly defined.