github.com/argoproj/argo-cd/v2@v2.10.5/docs/proposals/001-proposal-template.md (about)

     1  ---
     2  title: Neat-enhancement-idea
     3  authors:
     4    - "@sbose78" # Authors' github accounts here.
     5  sponsors:
     6    - TBD        # List all interested parties here.
     7  reviewers:
     8    - "@alexmt"
     9    - TBD
    10  approvers:
    11    - "@alexmt"
    12    - TBD
    13  
    14  creation-date: yyyy-mm-dd
    15  last-updated: yyyy-mm-dd
    16  ---
    17  
    18  # Neat Enhancement Idea
    19  
    20  This is the title of the enhancement. Keep it simple and descriptive. A good title can help
    21  communicate what the enhancement is and should be considered as part of any review.
    22  
    23  
    24  ## Open Questions [optional]
    25  
    26  This is where to call out areas of the design that require closure before deciding to implement the
    27  design.
    28  
    29  
    30  ## Summary
    31  
    32  The `Summary` is required for producing accurate user-focused documentation
    33  such as release notes or a development roadmap. It should be possible to collect this information
    34  before implementation begins in order to avoid requiring implementors to split their attention
    35  between writing release notes and implementing the feature itself. Before you get started with this document,
    36  please feel free to have a conversation on this with the maintainers/community on Github that would help
    37  drive a more organized thought process for the formal proposal here.
    38  
    39  ## Motivation
    40  
    41  This section is for explicitly listing the motivation, goals and non-goals of this proposal.
    42  Describe why the change is important and the benefits to users.
    43  
    44  ### Goals
    45  
    46  List the specific goals of the proposal and their measurable results. How will we know that this has succeeded?
    47  
    48  ### Non-Goals
    49  
    50  What is out of scope for this proposal? Listing non-goals helps to focus discussion and make
    51  progress.
    52  
    53  ## Proposal
    54  
    55  This is where we get down to details of what the proposal is about.
    56  
    57  ### Use cases
    58  
    59  Add a list of detailed use cases this enhancement intends to take care of.
    60  
    61  #### Use case 1:
    62  As a user, I would like to understand the drift. (This is an example)
    63  
    64  #### Use case 2:
    65  As a user, I would like to take an action on the deviation/drift. (This is an example)
    66  
    67  ### Implementation Details/Notes/Constraints [optional]
    68  
    69  What are the caveats to the implementation? What are some important details that didn't come across
    70  above. Go in to as much detail as necessary here. This might be a good place to talk about core
    71  concepts and how they relate.
    72  
    73  You may have a work-in-progress Pull Request to demonstrate the functioning of the enhancement you are proposing.
    74  
    75  ### Detailed examples
    76  
    77  ### Security Considerations
    78  
    79  * How does this proposal impact the security aspects of Argo CD workloads ?
    80  * Are there any unresolved follow-ups that need to be done to make the enhancement more robust ?
    81  
    82  ### Risks and Mitigations
    83  
    84  What are the risks of this proposal and how do we mitigate. Think broadly.
    85  
    86  For example, consider
    87  both security and how this will impact the larger Kubernetes ecosystem.
    88  
    89  Consider including folks that also work outside your immediate sub-project.
    90  
    91  
    92  ### Upgrade / Downgrade Strategy
    93  
    94  If applicable, how will the component be upgraded and downgraded? Make sure this is in the test
    95  plan.
    96  
    97  Consider the following in developing an upgrade/downgrade strategy for this enhancement:
    98  
    99  - What changes (in invocations, configurations, API use, etc.) is an existing cluster required to
   100    make on upgrade in order to keep previous behavior?
   101  - What changes (in invocations, configurations, API use, etc.) is an existing cluster required to
   102    make on upgrade in order to make use of the enhancement?
   103  
   104  ## Drawbacks
   105  
   106  The idea is to find the best form of an argument why this enhancement should _not_ be implemented.
   107  
   108  ## Alternatives
   109  
   110  Similar to the `Drawbacks` section the `Alternatives` section is used to highlight and record other
   111  possible approaches to delivering the value proposed by an enhancement.