Feature repo and SIG PM should track "efforts", not "features"

[idvoretskyi]

From @countspongebob on April 11, 2017 21:39

Creating this issue per the SIG PM discussion today. Linking this issue to Ihor's proposed feature lifecycle doc and the governance PM discussion as requested during the call.

Linking to governance umbrella seems sensible, as the Seven need to ensure they either define or define who will own the overall change control process.

Draft feature lifecycle doc is here. (Note that this proposal would also rename this to a "effort submission process".

Use of the word "feature" implies that that some new API call or new functional behavior of kubernetes is scope of the repo or the PM SIG. This also starts to beg the question "what is a feature".

Proposing that the scope is instead a chunk of work of sufficiently large or significant scope that it should tracked and visible across the entire community with the following guidelines:

Your proposed work might belong in the "effort repo" if:

• It's a feature that would show up in blog
• It's something that would end up in the release notes
• If it crosses SIG boundaries
• If it affects a lot of developers
• If it affects a lot of users

Checklists, review, and timing of all significant chunks of work (whether features or not) demand the same level of rigor and process.

Proposing feature repo should be renamed and SIG PM scope clarified.

-Bob

Copied from original issue: kubernetes/enhancements#247

[bgrant0607]

The existing guidelines are any change that:

• a blog post would be written about after its release (ex. minikube, StatefulSets, rkt container runtime)
• requires multiple parties/SIGs/owners participating to complete (ex. GPU scheduling [API, Core, & Node], StatefulSets [Storage & API])
• needs significant effort or changes Kubernetes in a significant way (ex. something that would take 10 person-weeks to implement, introduce or redesign a system component, or introduces API changes)
• impacts the UX or operation of Kubernetes substatially such that engineers using Kubernetes will need retraining
• users will notice and come to rely on

Any API or CLI change should be tracked.

I'm inclined to say that anything that requires a proposal should be tracked.

[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

[countspongebob]

Closing, especially in light of various process improvements. Looking forward to see how we manage the KEP process in this regard.

/close

[justaugustus]

/remove-lifecycle rotten

[justaugustus]

/remove-sig pm
/sig architecture
/area enhancements