Merge pull request #1838 from tejal29/add_design_doc_proposal

Adding a design proposal template and README.

docs/design_proposals/README.md

@@ -0,0 +1,35 @@
+# Design Proposal Process
+
+Hello Contributors!
+
+This document describes the process for proposing a new feature or making any
+large code changes to `skaffold`. By large we mean,  large in impact or large in
+size.
+
+Examples for large impact changes would be:
+
+1. Introduce templating, or
+2. Arbitrary command execution in certain places
+
+These could be small code changes but large in impact.
+
+Submitting a proposal before a pull request will likely reduce the back and
+forth between the contributor and the core team. A proposal also ensures that
+each new feature or a large change has a design review.
+
+For any new feature, config or large change, please add a design proposal document
+as described in [Design Proposal Template](./design-proposal-template.md).
+
+Once you create a PR with the proposal, one of the maintainers will be
+assigned as a design shepherd. The role of the design shepherd will be to make
+sure:
+
+1. The feature/change is aligned with the Skaffold roadmap and the team's general
+   philosophy for the tool and not a one off solution for a specific use case.
+2. The feature/change scope is well defined.
+3. When changing any existing feature, the implementation plan adheres to
+   [skaffold deprecation policy](./../../deprecation-policy.md).
+
+Once the proposal has been approved, we can move discussions to our bi-weekly
+meetings to address any open concerns,and to reach a final decision on whether
+or not to accept the feature or change.

docs/design_proposals/design-proposal-template.md

@@ -0,0 +1,96 @@
+# Title
+
+* Author(s): \<your name\>
+* Design Shepherd: \<skaffold-core-team-member\>
+
+    If you are already working with someone mention their name.
+    If not, please leave this empty, it will be assigned to a core team member.
+* Date: \<date\>
+* Status: [Reviewed/Cancelled/Under implementation/Complete]
+
+Here is a brief explanation of the Statuses
+
+1. Reviewed: The proposal PR has been accepted, merged and ready for
+   implementation.
+2. Under implementation: An accepted proposal is being implemented by actual work.
+   Note: The design might change in this phase based on issues during
+   implementation.
+3. Cancelled: During or before implementation the proposal was cancelled.
+   It could be due to:
+   * other features added which made the current design proposal obsolete.
+   * No longer a priority.
+4. Complete: This feature/change is implemented.
+
+## Background
+
+In this section, please mention and describe the new feature, redesign
+or refactor.
+
+Please provide a brief explanation for the following questions:
+
+1. Why is this required?
+2. If this is a redesign, what are the drawbacks of the current implementation?
+3. Is there any another workaround, and if so, what are its drawbacks?
+4. Mention related issues, if there are any.
+
+Here is an example snippet for a new feature:
+
+___
+Currently, skaffold config supports `artifact.sync` as a way to sync files
+directly to pods. So far, artifact sync requires a specification of sync
+patterns like
+
+```yaml
+sync:
+  '*.js': app/
+```
+
+This is error prone and unnecessarily hard to use, because the destination is
+already contained in the Dockerfile for docker build (see #1166, #1581).
+In addition, the syncing needs to handle special cases for globbing and often
+requires a long list of sync patterns (#1807).
+___
+
+## Design
+
+Please describe your solution. Please list any:
+
+* new config changes
+* interface changes
+* design assumptions
+
+For a new config change, please mention:
+
+* Is it backwards compatible? If not, what is the deprecation policy?
+  Refer to the [deprecation policy requirements.](./../../deprecation-policy.md#how-do-we-deprecate-things)
+  for details.
+
+### Open Issues/Question
+
+Please list any open questions here in the format.
+
+**\<Question\>**
+
+Resolution: Please list the resolution if resolved during the design process or
+specify __Not Yet Resolved__
+
+## Implementation plan
+As a team, we've noticed that larger PRs can go unreviewed for long periods of
+time. Small incremental changes get reviewed faster and are also easier for
+reviewers.
+
+For a design feature, list a summary of tasks breakdown for e.g.:
+For the example artifact sync proposal, some of the smaller tasks could be:
+___
+
+1. Add new config key `infer` to `artifact.sync` and test schema validation.
+2. Add inference logic for docker and examples.
+3. Support both `infer` and user defined map with precedence rules implemented.
+4. Finally, support builder plugins to add sync patterns.
+
+___
+
+
+## Integration test plan
+
+Please describe what new test cases you are going to consider.