Add small pr guidelines

[tejal29]

Fixes #2812

Description
I this PR, add guidelines for keeping PRs small,

1. for config changes
2. Big feature requests.

User facing changes

1. DEVELOPMENT.md links to writing small prs.

Next PRs.

• How to keep your PRs small when Addressing bug fixes.
  Explain how one should address only one bug in a PR.

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

• [ n/a] Includes unit tests
• [n/a ] Mentions any output changes.
• [ X ] Adds documentation as needed: user docs, YAML reference, CLI reference.
• [ n/a ] Adds integration tests if needed.

See the contribution guide for more details.

Double check this list of stuff that's easy to miss:

• If you are adding a example to the examples dir, please copy them to integration/examples
• Every new example added in integration/examples dir, should be tested in integration test

Reviewer Notes

• The code flow looks good.
• Unit test added.
• User facing changes look good.

Release Notes

Describe any user facing changes here so maintainer can include it in the release notes, or delete this block.

Examples of user facing changes:
- Skaffold config changes like
  e.g. "Add buildArgs to `Kustomize` deployer skaffold config."
- Bug fixes
  e.g. "Improve skaffold init behaviour when tags are used in manifests"
- Any changes in skaffold behavior
  e.g. "Artiface cachine is turned on by default."

[codecov]

Codecov Report

Merging #2977 into master will increase coverage by 0.12%.
The diff coverage is n/a.

Impacted Files	Coverage Δ
pkg/skaffold/schema/versions.go	70.83% <0%> (-3.53%)	⬇️
pkg/skaffold/deploy/kubectl/visitor.go	93.75% <0%> (-0.37%)	⬇️
cmd/skaffold/app/cmd/cmd.go	68% <0%> (-0.26%)	⬇️
pkg/skaffold/kubernetes/context/context.go	100% <0%> (ø)	⬆️
pkg/skaffold/runner/runner.go	0% <0%> (ø)	⬆️
pkg/skaffold/server/endpoints.go	0% <0%> (ø)	⬆️
pkg/skaffold/schema/profiles.go	88.43% <0%> (+0.05%)	⬆️
pkg/skaffold/schema/defaults/defaults.go	91.08% <0%> (+0.05%)	⬆️
pkg/skaffold/event/event.go	92.21% <0%> (+0.19%)	⬆️
pkg/skaffold/runner/dev.go	67.96% <0%> (+0.31%)	⬆️
... and 5 more

[balopat]

This looks great, added grammar nits - plus I would add one more section somewhere :

Implementing the full functionality sometimes makes a lot of sense, so that you can get feedback regarding the design while implementing it, also, the maintainers can try it out and test it, get a feel for it. We can mark these "massive" PRs "prototype PR" or "master PR" that will broken down into smaller PRs that can refer back to the master PR. If you keep the master PR rebased as the smaller pieces get merged, finally the master PR can be merged as well. See for example #2917.

WDYT?

[tejal29]

Implementing the full functionality sometimes makes a lot of sense, so that you can get feedback regarding the design while implementing it

We would want to encourage sending a design proposal for feedback on design or large changes. Having a design proposal does help to think about breaking down in smaller PRs since we have a section for it.
I thought i personally spent a lot of time rebasing my master PR i had for #2750 and just abandoned it. Nick also did the same thing with #2911

With that said, i do understand scenarios like this #2978
Do you think #2978, #2917, #2911 all could be an example of having a proposal?

I feel it might send conflicting messages but open for discussion.

addressed review comments as we discussed.