Disambiguate "design-proposals" and accepted designs

[mikedanese]

This came up in a sig. Someone asked whether a merged doc in contributors/design-proposals/ was an accepted design or still a proposal.

• Is there documentation anywhere explaining that merged docs are accepted?
• Would contributors/designs/ be a better name for the contributors/design-proposals/? Are docs proposals when they are PRs and become designs after they merge?
• If not, then when should a design proposal graduate to design? After implementation? Should the doc move at that point?

[bgrant0607]

This is being discussed in SIG Architecture as we formalize the proposal process.

Related: #651

[grodrigues3]

@kubernetes/sig-architecture-feature-requests

[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

[bgrant0607]

/remove-lifecycle stale

[bgrant0607]

Almost all of these were written prior to implementation and so are "proposals" in that sense. A few were never implemented -- those should be marked, and possibly moved.

In general, we're trying to clarify this type of thing with the new KEP process.

[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.

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]

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.

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

[rhuss]

We have a similar question, especially for this accepted design proposal for service discovery by @KurtStam --> https://github.com/kubernetes/community/blob/master/contributors/design-proposals/network/service-discovery.md

This proposal introduces new annotations with a prefix "api.service.kubernetes.io/" (e.g. "api.service.kubernetes.io/description-path"). As this is an accepted design proposal (but not implemented, however there is very likely no implementation, just that spec), is it safe to assume that these annotations can be safely used in applications and tooling ?

That open the general question whether there is a comprehensive list of "official" and reservied annotations. Afaik there is none, the only pointers I found were https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints and the one mentioned within https://kubernetes.io/docs/concepts/services-networking/service.

[justaugustus]

/sig pm

[nikhita]

Someone asked whether a merged doc in contributors/design-proposals/ was an accepted design or still a proposal.

@justaugustus is this still relevant given that we have the KEP status field today?

[mrbobbytables]

Closing this as it is no longer relevant with the KEP process 👍
/close

[k8s-ci-robot]

@mrbobbytables: Closing this issue.

In response to this:

Closing this as it is no longer relevant with the KEP process 👍
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[justaugustus]

/remove-sig pm
/sig architecture
/area enhancements