github.com/GoogleContainerTools/skaffold/v2@v2.13.2/docs-v2/design_proposals/design-proposal-template.md (about)

     1  # Title
     2  
     3  * Author(s): \<your name\>
     4  * Design Shepherd: \<skaffold-core-team-member\>
     5  
     6      If you are already working with someone mention their name.
     7      If not, please leave this empty, it will be assigned to a core team member.
     8  * Date: \<date\>
     9  * Status: [Reviewed/Cancelled/Under implementation/Complete]
    10  
    11  Here is a brief explanation of the Statuses
    12  
    13  1. Reviewed: The proposal PR has been accepted, merged and ready for
    14     implementation.
    15  2. Under implementation: An accepted proposal is being implemented by actual work.
    16     Note: The design might change in this phase based on issues during
    17     implementation.
    18  3. Cancelled: During or before implementation the proposal was cancelled.
    19     It could be due to:
    20     * other features added which made the current design proposal obsolete.
    21     * No longer a priority.
    22  4. Complete: This feature/change is implemented.
    23  
    24  ## Background
    25  
    26  In this section, please mention and describe the new feature, redesign
    27  or refactor.
    28  
    29  Please provide a brief explanation for the following questions:
    30  
    31  1. Why is this required?
    32  2. If this is a redesign, what are the drawbacks of the current implementation?
    33  3. Is there any another workaround, and if so, what are its drawbacks?
    34  4. Mention related issues, if there are any.
    35  
    36  Here is an example snippet for a new feature:
    37  
    38  ___
    39  Currently, skaffold config supports `artifact.sync` as a way to sync files
    40  directly to pods. So far, artifact sync requires a specification of sync
    41  patterns like
    42  
    43  ```yaml
    44  sync:
    45    '*.js': app/
    46  ```
    47  
    48  This is error prone and unnecessarily hard to use, because the destination is
    49  already contained in the Dockerfile for docker build (see #1166, #1581).
    50  In addition, the syncing needs to handle special cases for globbing and often
    51  requires a long list of sync patterns (#1807).
    52  ___
    53  
    54  ## Design
    55  
    56  Please describe your solution. Please list any:
    57  
    58  * new config changes
    59  * interface changes
    60  * design assumptions
    61  
    62  For a new config change, please mention:
    63  
    64  * Is it backwards compatible? If not, what is the deprecation policy?
    65    Refer to the [Skaffold Deprecation Policy](http://skaffold.dev/docs/references/deprecation/).
    66    for details.
    67  
    68  ### Open Issues/Questions
    69  
    70  Please list any open questions here in the following format:
    71  
    72  **\<Question\>**
    73  
    74  Resolution: Please list the resolution if resolved during the design process or
    75  specify __Not Yet Resolved__
    76  
    77  ## Implementation plan
    78  As a team, we've noticed that larger PRs can go unreviewed for long periods of
    79  time. Small incremental changes get reviewed faster and are also easier for
    80  reviewers.
    81  
    82  For a new feature, list the major tasks required for the implementation. Given the example artifact sync proposal, some of the smaller tasks could be:
    83  ___
    84  
    85  1. Add new config key `infer` to `artifact.sync` and test schema validation.
    86  2. Add inference logic for docker and examples.
    87  3. Support both `infer` and user defined map with precedence rules implemented.
    88  4. Finally, support builder plugins to add sync patterns.
    89  
    90  ___
    91  
    92  
    93  ## Integration test plan
    94  
    95  Please describe what new test cases you are going to consider.