github.com/argoproj/argo-cd/v3@v3.2.1/docs/developer-guide/code-contributions.md (about)

     1  # Submitting code contributions to Argo CD
     2  
     3  ## Preface
     4  
     5  The Argo CD project continuously grows, both in terms of features and community size. It gets adopted by more and more organisations which entrust Argo CD to handle their critical production workloads. Thus, we need to take great care with any changes that affect compatibility, performance, scalability, stability and security of Argo CD. For this reason, every new feature or larger enhancement must be properly designed and discussed before it gets accepted into the code base.
     6  
     7  We do welcome and encourage everyone to participate in the Argo CD project, but please understand that we can't accept each and every contribution from the community, for various reasons.
     8  
     9  If you want to submit code for a great new feature or enhancement, we kindly ask you to take a look at the
    10  enhancement process outlined below before you start to write code or submit a PR. This will ensure that your idea is well aligned with the project's strategy and technical requirements, and it will help greatly in getting your code merged into our code base.
    11  
    12  Before submitting code for a new feature (and also, to some extent, for more complex bug fixes) please
    13  [raise an Enhancement Proposal or Bug Issue](https://github.com/argoproj/argo-cd/issues/new/choose)
    14  first.
    15  
    16  _Please_ do not spend too much time on larger features or refactorings before the corresponding enhancement has been triaged. This may save everyone some amount of frustration and time, as the enhancement proposal might be rejected, and the code would never get merged. However, sometimes it's helpful to have some PoC code along with a proposal.
    17  
    18  We will do our best to triage incoming enhancement proposals quickly, with one of the following outcomes:
    19  
    20  * Accepted
    21  * Rejected
    22  * Proposal requires a design document to be further discussed
    23  
    24  Depending on how many enhancement proposals we receive at given times, it may take some time until we can look at yours.
    25  
    26  Also, please make sure you have read our
    27  [Toolchain Guide](toolchain-guide.md)
    28  to understand our toolchain and our continuous integration processes. It contains some invaluable information to get started with the complex code base that makes up Argo CD.
    29  
    30  ## Quick start
    31  
    32  If you want a quick start contributing to Argo CD, take a look at issues that are labeled with
    33  [help wanted](https://github.com/argoproj/argo-cd/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22)
    34  or
    35  [good first issue](https://github.com/argoproj/argo-cd/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22).
    36  
    37  These are issues that were already triaged and accepted.
    38  
    39  If the issue is already attached to next
    40  [version milestone](https://github.com/argoproj/argo-cd/milestones),
    41  we have decided to also dedicate some of our time on reviews to PRs received for these issues.
    42  
    43  We encourage our community to pick up issues that are labeled in this way *and* are attached to the next version's milestone, with a promise for them to get a proper review with the clear intention for the incoming PRs to get merged.
    44  
    45  ## Triage process
    46  
    47  ### Overview
    48  
    49  Our triage process for enhancements proposals ensures that we take a look at all incoming enhancements to determine whether we will accept code submissions to implement them.
    50  
    51  The process works as follows:
    52  
    53  * New Enhancement Proposals raised on our GitHub issue tracker are moved to the _Incoming_ column of the project's board. These are the proposals that are in the queue for triage.
    54  * The _Active_ column holds the issues that are currently being triaged, or will be triaged next.
    55  * The _Accepted_ column holds the issues that have been triaged and are considered good to be implemented (e.g. the project agreed that the feature would be great to have)
    56  * The _Declined_ column holds the issues that were rejected during triage. The issue will be updated with information about why the proposal has been rejected.
    57  * The _Needs discussion_ column holds the issues that were found to require additional information, or even a design document, during triage.
    58  
    59  ### Triage cadence
    60  
    61  Triage of enhancement proposals is performed transparently, offline using issue comments and online in our weekly contributor's meeting. _Everyone_ is invited to participate in triaging, the process is not limited to participation only by maintainers.
    62  
    63  Usually, we will triage enhancement proposals in a First-In-First-Out order, which mean that oldest proposals will be triaged first.
    64  
    65  We aim to triage at least 10 proposals a week. Depending on our available time, we may be triaging a higher or lower number of proposals in any given week.
    66  
    67  ## Proposal states
    68  
    69  ### Accepted proposals
    70  
    71  When a proposal is considered _Accepted_, it was decided that this enhancement would be valuable to the community at large and fits into the overall strategic roadmap of the project.
    72  
    73  Implementation of the issue may be started, either by the proposal's creator or another community member (including maintainers of the project).
    74  
    75  The issue should be refined enough by now to contain any concerns and guidelines to be taken into consideration during implementation.
    76  
    77  ### Declined proposals
    78  
    79  We don't decline proposals lightly, and we will do our best to give a proper reasoning why we think that the proposal does not fit with the future of the project. Reasons for declining proposals may be - amongst others - that the change would be breaking for many, or that it does not meet the strategic direction of the project. Usually, discussion will be facilitated with the enhancement's creator before declining a proposal.
    80  
    81  Once a proposal is in _Declined_ state it's unlikely that we will accept code contributions for its implementation.
    82  
    83  ### Proposals that need discussion
    84  
    85  Sometimes, we can't completely understand a proposal from its GitHub issue and require more information on the original intent or on more details about the implementation. If we are confronted with such an issue during the triage, we move this issue to the _Needs discussion_ column to indicate that we expect the issue's creator to supply more information on their idea. We may ask you to provide this information, either by adding that information to the issue itself or by joining one of our
    86  [regular contributor's meeting](#regular-contributor-meeting)
    87  to discuss the proposal with us.
    88  
    89  Also, issues that we find to require a more formal design document will be moved to this column.
    90  
    91  ## Design documents
    92  
    93  For some enhancement proposals (especially those that will change behavior of Argo CD substantially, are attached with some caveats or where upgrade/downgrade paths are not clear), a more formal design document will be required in order to fully discuss and understand the enhancement in the broader community. This requirement is usually determined during triage. If you submitted an enhancement proposal, we may ask you to provide this more formal write down, along with some concerns or topics that need to be addressed.
    94  
    95  Design documents are usually submitted as PR and use [this template](https://github.com/argoproj/argo-cd/blob/master/docs/proposals/001-proposal-template.md) as a guide what kind of information we're looking for. Discussion will take place in the review process. When a design document gets merged, we consider it as approved and code can be written and submitted to implement this specific design.
    96  
    97  ## Regular contributor meeting
    98  
    99  Our community regularly meets virtually to discuss issues, ideas and enhancements around Argo CD. We do invite you to join this virtual meetings if you want to bring up certain things (including your enhancement proposals), participate in our triaging or just want to get to know other contributors.
   100  
   101  The current cadence of our meetings is weekly, every Thursday at 8:15AM Pacific Time ([click here to check in your current timezone][1]). We use Zoom to conduct these meetings.
   102  
   103  * [Agenda document (Google Docs, includes Zoom link)](https://docs.google.com/document/d/1xkoFkVviB70YBzSEa4bDnu-rUZ1sIFtwKKG1Uw8XsY8)
   104  
   105  If you want to discuss something, we kindly ask you to put your item on the
   106  [agenda](https://docs.google.com/document/d/1xkoFkVviB70YBzSEa4bDnu-rUZ1sIFtwKKG1Uw8XsY8)
   107  for one of the upcoming meetings so that we can plan in the time for discussing it.
   108  
   109  [1]: https://www.timebie.com/std/pacific.php?q=081500