development process formalization

58 views
Skip to first unread message

Brian Grant

unread,
Aug 4, 2017, 11:22:36 AM8/4/17
to kubernetes-si...@googlegroups.com, Caleb Miles, Phillip Wittrock, Jago Macleod, Tim Hockin
Starting with a narrow recipient list, but we can loop in SIG PM, SIG Release, SIG Contributor Experience, the full Bootstrap Committee, and others once we have a complete proposal.

We have 150-200 monthly active contributors, thousands of commits per release, ~50 tracked features per release, and >25 SIGs. We don't currently have enough structure in our development processes to support that scale. We've struggled with effort/feature tracking and vetting, and release-note generation.

We've discussed formalizing the proposal and API review processes for a long time. The current cargo-cult, informal processes are unclear to many contributors and many proposals languish indefinitely, sometimes blocking work and sometimes not -- neither outcome is good.

Related existing processes:
Existing work in this area:
These are good starts. Perhaps we can unify and expand them.

What problems I'd expect an end-to-end development process to solve:
  • Tracking and Status: It should be possible to determine what significant work is in flight, what is expected for the next release, what changes are approved or not approved, which efforts have been abandoned
  • Produce accurate, high-quality release notes: https://github.com/kubernetes/community/issues/484
  • Clear OARP, from OWNERS, and the SIG, and maybe Champion/Sponsor model
  • Clear development lifecycle: discuss in SIG meeting, draft proposal, review, approve, work, test, document, merge)
  • There should be a clear way to say "no" and "not in this release"
  • Clear communication requirements: @kubernetes/sig-foo-proposals, @kubernetes/sig-foo-api-reviews, kubernetes-dev-announce, etc.
  • Escalation process, ability to call for design review meeting
  • API change control and architectural review, especially for new APIs
  • Appropriate contents of a proposal: APIs, backward compatibility, deviation from conventions, design, requirements, motivation / use cases, user experience, costs/risks -- the API proposal template and RFC process have some good ideas
  • Identify the repo, fork, or branch where the code will be developed (if not kubernetes/master)
Anything missing from that list? I'd like for us to make progress on this before 1.9.

Ihor Dvoretskyi

unread,
Aug 4, 2017, 11:30:15 AM8/4/17
to Brian Grant, kubernetes-si...@googlegroups.com, Caleb Miles, Phillip Wittrock, Jago Macleod, Tim Hockin
Agree on the process formalizing importance.

On behalf of SIG-PM, we are going to work on the formalizing the definitions of "stabilization" and "feature" releases, aka "tick-tock" model. I'd like these formal criteria to be also included in this initiative.

> I'd like for us to make progress on this before 1.9.

Yes. I'd like us to set a formal deadline before 1.9 iteration will start - to work in a formal way since the beginning.

Thanks

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-sig-architecture@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAKCBhs6YQquNU4W0WQkpQRFzgox0MmbzQiY0Ydgg3pS6ZM06Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Joe Beda

unread,
Aug 5, 2017, 4:58:34 PM8/5/17
to Ihor Dvoretskyi, Brian Grant, kubernetes-si...@googlegroups.com, Caleb Miles, Phillip Wittrock, Jago Macleod, Tim Hockin
I think that this is a great list. Thanks for putting it together, Brian.

I'd love to see a way to break this down into more bite sized chunks.  There is a lot here and coming up with an omnibus process is a bit overwhelming.

One way I've been thinking about this is splitting out "what" we want to do with the "how and when".

I'm a fan of the Python PEP process, for instance.  The interesting thing there is that the process for figuring out what the right thing to do is staged differently from the tracking where and how it happens.  Right now our process is muddled and the design often happens concurrently with the implementation.  This means that we have things hitting late in the cycle where the "what" isn't even well communicated or understood.  For the sake of argument, let's call this a "Proposal".  Proposals will stretch over multiple versions and will evolve as we get an understanding.  This is a great place to have API review vs. having it happen during implementation.

In addition, when tracking the "how and when" we should be able to break that down into bite sized chunks that are either all in or out for a release.  If we have a Proposal that is being implemented over 3 versions from alpha to beta to GA, we should break that down into the work that is being done in a release.  For the sake of this argument, let's call this a "Release Effort".  A Release Effort might be something like "Bring part X of Proposal 123 to Beta".

Proposals seem to be in the wheelhouse of something like SIG-architecture. That group insures consistency and direction for the project as a whole over multiple versions. The list of Proposals will, in effect, create a forward looking roadmap.  Release Efforts seem like a project planning tool and probably belong with SIG-Release.  They also line up well with the release note process.

(Terms are obviously strawmen but I think do capture the intent).

Joe

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.
To post to this group, send email to kubernetes-si...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAKCBhs6YQquNU4W0WQkpQRFzgox0MmbzQiY0Ydgg3pS6ZM06Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.
To post to this group, send email to kubernetes-si...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CA%2BhxP0vYJxh1TVAzHMaF6HYUP%2BrT5%3D%3Dr8uN0AdW8zQGRDjd9HA%40mail.gmail.com.

Brian Grant

unread,
Aug 7, 2017, 11:10:33 AM8/7/17
to Joe Beda, Ihor Dvoretskyi, kubernetes-si...@googlegroups.com, Caleb Miles, Phillip Wittrock, Jago Macleod, Tim Hockin
On Sat, Aug 5, 2017 at 1:58 PM, Joe Beda <j...@heptio.com> wrote:
I think that this is a great list. Thanks for putting it together, Brian.

I'd love to see a way to break this down into more bite sized chunks.  There is a lot here and coming up with an omnibus process is a bit overwhelming.

Breaking it down is a good idea, so long as we understand what problem(s) each chunk is trying to solve and how they'll fit together. 

In this case, since separate work is already underway for effort tracking (features repo) and release-notes generation, I'd like to focus on just the design-proposal process and contents. Right now, we are lacking:
  • A clear proposal lifecycle: what to do, and in what order
  • A template, with required/suggested contents
  • A process/mechanism for determining the specific reviewers and approvers
  • Communication requirements/procedure, to ensure there is an opportunity for feedback by non-reviewer/approver participants
  • A process for determining whether to accept the proposal
  • A deadline for making a decision
  • Clear status/closure: accepted, rejected
  • SIG ownership
 

One way I've been thinking about this is splitting out "what" we want to do with the "how and when".

I'm a fan of the Python PEP process, for instance.  The interesting thing there is that the process for figuring out what the right thing to do is staged differently from the tracking where and how it happens.  Right now our process is muddled and the design often happens concurrently with the implementation.  This means that we have things hitting late in the cycle where the "what" isn't even well communicated or understood.  For the sake of argument, let's call this a "Proposal".  Proposals will stretch over multiple versions and will evolve as we get an understanding.  This is a great place to have API review vs. having it happen during implementation.

In addition, when tracking the "how and when" we should be able to break that down into bite sized chunks that are either all in or out for a release.  If we have a Proposal that is being implemented over 3 versions from alpha to beta to GA, we should break that down into the work that is being done in a release.  For the sake of this argument, let's call this a "Release Effort".  A Release Effort might be something like "Bring part X of Proposal 123 to Beta".

Proposals seem to be in the wheelhouse of something like SIG-architecture. That group insures consistency and direction for the project as a whole over multiple versions. The list of Proposals will, in effect, create a forward looking roadmap.  Release Efforts seem like a project planning tool and probably belong with SIG-Release.  They also line up well with the release note process.

(Terms are obviously strawmen but I think do capture the intent).

Joe

On Fri, Aug 4, 2017 at 8:30 AM Ihor Dvoretskyi <ihor.dv...@gmail.com> wrote:
Agree on the process formalizing importance.

On behalf of SIG-PM, we are going to work on the formalizing the definitions of "stabilization" and "feature" releases, aka "tick-tock" model. I'd like these formal criteria to be also included in this initiative.

> I'd like for us to make progress on this before 1.9.

Yes. I'd like us to set a formal deadline before 1.9 iteration will start - to work in a formal way since the beginning.

Thanks
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsubs...@googlegroups.com.
To post to this group, send email to kubernetes-sig-architecture@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsubs...@googlegroups.com.
To post to this group, send email to kubernetes-sig-architecture@googlegroups.com.

Joe Beda

unread,
Aug 7, 2017, 12:19:08 PM8/7/17
to Brian Grant, Ihor Dvoretskyi, kubernetes-si...@googlegroups.com, Caleb Miles, Phillip Wittrock, Jago Macleod, Tim Hockin
+1 to all of this. Also some clear ways to list proposals with current status.

This will help the release and effort stuff focus too helpfully. I'll add it to my personal list to put together a strawman. If someone else has time to get started go for it.

Joe
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.
To post to this group, send email to kubernetes-si...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.
To post to this group, send email to kubernetes-si...@googlegroups.com.

Brian Grant

unread,
Aug 7, 2017, 1:24:49 PM8/7/17
to Joe Beda, Ihor Dvoretskyi, kubernetes-si...@googlegroups.com, Caleb Miles, Phillip Wittrock, Jago Macleod, Tim Hockin
On Mon, Aug 7, 2017 at 9:18 AM, Joe Beda <j...@heptio.com> wrote:
+1 to all of this. Also some clear ways to list proposals with current status.

This will help the release and effort stuff focus too helpfully. I'll add it to my personal list to put together a strawman. If someone else has time to get started go for it.

Help would be appreciated.

Caleb created a draft based on Rust's RFC process: https://gist.github.com/calebamiles/66386dfe9e00d90b5f1c621bd2899dbf

In particular, this section could be turned into a template:

I'd like to hold off on the release-oriented mechanics part of that proposal for now, and add the other critical parts of the process from my list that are missing.

One idea on reviewer/approver assignment: The proposal could list the key parts of the code it would touch. Then we could draw reviewers and approvers from OWNERS. 

I don't think that's sufficient for making a go/no-go decision, however. We could use this case as a model for how decision-making should work on the project. 

Desirable properties:
  • Involve the most-informed technical people (OWNERS)
  • Don't give everyone who comments on a proposal veto power
  • By default, discussion and review should start with SIGs (for decentralization, accountability). 
  • We need to resolve the disconnect between code organization (OWNERS) and people organization (SIGs), and create a clear set of stakeholders and authority structure. For example, who can decide who the approver(s) should be if multiple eligible people want that role?
  • Use (modified) lazy consensus when there are multiple deciders
  • Escalation above the SIG level should be an exceptional case

 

Joe

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-sig-architecture@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-sig-architecture@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-sig-architecture@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAEAFPYJmHWt7FSVBMf_txOaHVkXnkRbZ%3DVopqAtK%3DSHs1kh%2Brw%40mail.gmail.com.

Brian Grant

unread,
Aug 17, 2017, 5:21:53 PM8/17/17
to Joe Beda, Ihor Dvoretskyi, kubernetes-sig-architecture, Caleb Miles, Phillip Wittrock, Jago Macleod, Tim Hockin, Paul Morie
Is anyone working on an initial draft of the proposal process, as we discussed in the last meeting? I haven't seen one, but I don't want to duplicate effort.


 

Joe

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsubs...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsubs...@googlegroups.com.

To post to this group, send email to kubernetes-sig-architecture@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsubs...@googlegroups.com.

To post to this group, send email to kubernetes-sig-architecture@googlegroups.com.

Joe Beda

unread,
Aug 17, 2017, 5:24:28 PM8/17/17
to Brian Grant, Ihor Dvoretskyi, kubernetes-sig-architecture, Caleb Miles, Phillip Wittrock, Jago Macleod, Tim Hockin, Paul Morie
I haven't seen it yet either.  I know Caleb has thoughts and I'd love to help craft it too.  If I wasn't headed out on vacation I'd volunteer to get started.

Joe


 

Joe

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.
To post to this group, send email to kubernetes-si...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.
To post to this group, send email to kubernetes-si...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.
To post to this group, send email to kubernetes-si...@googlegroups.com.

Caleb Miles

unread,
Aug 22, 2017, 11:03:16 PM8/22/17
to Joe Beda, Brian Grant, Ihor Dvoretskyi, kubernetes-sig-architecture, Phillip Wittrock, Jago Macleod, Tim Hockin, Paul Morie
I put my thoughts in a PR against the community repo [1] since it was crickets on my first draft. I also posted to kubernetes-dev [2] about the proposal. Your comments are certainly desired.



 

Joe

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-sig-architecture@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-sig-architecture@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-sig-architecture@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages