Document how developers can do use case, design, pr

[chrislovecnm]

With folks that are first time contributors to kops we often recommend that you do:

1. Use cases in an issue
2. Design in a PR, and update docs to match the design
3. PR the code with test coverage

Since we are a smaller project the full design process that K8s utilizes, I believe is complete overkill. For really large changes to the code base I would like to see everyone do a quick design.

[chrislovecnm]

#906

^ a perfect example how to do what I am talking about! A little more design would be awesome. But documenting the process that was used in the above PR would be magical.

[chrislovecnm]

@vendrov - this is the process that I would recommend. If you want to work on SG then I would recommend an umbrella issue pulling in all of the use cases for SG improvements. Then follow the above steps

[chrislovecnm]

@thockin do we have a process for the smaller projects to do design work?

Use cases are around on-boarding new developers. How do we want them through a simple process to get them up to speed, and the other half is when we have a large PR the project has a simple design process.

The design process that core uses is awesome for core, but a tad heavy for a small project.

[chrislovecnm]

@vendrov once you have your head around the design. Please create a short markdown document and submit a PR. You can submit the PR using the new folder https://github.com/kubernetes/kops/tree/master/docs/design. You can look at https://github.com/kubernetes/kubernetes/tree/master/docs/design for examples.

The https://github.com/kubernetes/kubernetes/blob/master/docs/design/admission_control.md is bigger that what we need, but a good example to start.

[chrislovecnm]

cc @kubernetes/sig-contributor-experience-misc do we have an example that other smaller projects are using? Do you want us to use the community repository for design docs as well?

[chrislovecnm]

cc: @scottmwebber

[thockin]

We don't have any defined process other than the main process, afaik. I'm OK with the idea of lighter-weight process for smaller repos, but I don't want to see 20 different processes for 20 different repos.

[chrislovecnm]

@thockin happy to do a POC for the org. We actually may have some assistance from @scottmwebber on the PM side of the house. So let us see if we can get something cool done, which can be shared by multiple repos.

[krisnova]

@chrislovecnm @ScottWebber @thockin

I added this snippet to the main README over the break https://github.com/kubernetes/kops#features-1

It's not an inclusive doc by any means, but it's a starting point. We probably ought to get it into it's own file, and add the pointer in the main README.

Regardless, the important fact I wanted to mention around this was the concept of having different types of work. We already know we have bugs and features and the workflow will inherently be different for those (with some common themes).

TLDR;

There isn't just 1 type of work flow, and we should be respectful of that.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close