Organize Design Proposals Folder

[grodrigues3]

The design proposals folder is getting a little out of hand, and we could do a few things to help improve it.

• In lieu of sig subdirs, create functional area subdirs with clear ownership
• Create OWNERS files in those subdirs
• Disambiguate proposals from accepted changes as tracked by Disambiguate "design-proposals" and accepted designs #914

[smarterclayton]

We talked about organization of design proposals on sig-arch and I had the todo of a structure proposal. I'm leery of per sig because we have many cross cutting proposals, but functional area is probably the best choice since we lack any other clear structure for team ownership.

I do think approval process for a proposal has a higher bar than code, since they touch on expansion of "what is kubernetes". I'd argue for fewer approvers or a model that requires several confirmations. We've described proposals in the same way others describe RFC, and that is not a "single yea" system.

[grodrigues3]

I do think approval process for a proposal has a higher bar than code, since they touch on expansion of "what is kubernetes". I'd argue for fewer approvers or a model that requires several confirmations.

@smarterclayton that makes total sense. Do you think we need automation for this (requires some thought) or can we rely on consensus (e.g. several confirmations) or existing leadership to resolve these disputes?

Functional area makes sense. What do you think about splitting out approved designs and proposals?

[grodrigues3]

@kubernetes/sig-architecture-feature-requests

[smarterclayton]

Up until now we haven't merged proposals that aren't approved. So we may not need approved yet, but I could see how that might be desirable. Possibly instead of sub folders, we could require better naming. We could also have a deprecated / out of date proposals dir, although that can also be managed by naming. I think we don't know yet what the approval process will be officially, but unofficially it is "you convince all the major stakeholders you're going to impact that their concerns have addressed, you get a consensus on the change to architecture from the people who usually complain about top level architecture, and then you get merged when the affected sig reviewers sign off". I suspect for proposals we don't quite want automation yet for merging, but we do want automation for nagging and identifying impacted parties and prettying it up into docs.

…

On Wed, Aug 16, 2017 at 1:23 PM, grodrigues3 ***@***.***> wrote: @kubernetes/sig-architecture-feature-requests <https://github.com/orgs/kubernetes/teams/sig-architecture-feature-requests> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#918 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABG_p5elfN4WkgfxVpNe4noqNAoSio2uks5sYyV0gaJpZM4O4Oxy> .

[bgrant0607]

Related: #651