On the call yesterday, Dan asked me to send out my thoughts on double-blind reviewing.  My e-mail quickly turned into a blog entry:

  http://dtrace.org/blogs/bmc/2018/10/03/should-kubecon-be-double-blind/

Something that I probably didn't highlight well enough in there is Kathryn McKinley's excellent piece on double-blind review:

  http://www.cs.utexas.edu/users/mckinley/notes/blind.html

There are certainly lots of ways to attack this problem, but I view double-blind as an essential piece -- but probably not sufficient on its own.

         - Bryan

To add a bit of color on the Falco Sandbox proposal and presentation. 

I started with the proposal document first because I felt that the problem we were trying to solve may not necessarily be well understood if we only did a presentation. I also wanted to have any of the questions/requirements for a Sandbox project answered ahead of the presentation. That way any TOC members could be confident that we met the requirements and we weren't wasting anyone's time. If questions or confusion came up, I had the proposal document to refer people back to. Lastly, I wanted people to clearly understand where we were fitting in the Cloud Native ecosystem, and the value we were providing. I felt like that would be harder to get across in the presentation. Personally, I felt that these were the barriers that we needed to overcome to get the TOC sponsors required. 

From the proposal I built the presentation, which felt like it naturally came out of the proposal. Each section became a slide (or two), and we had a much more clear story to tell on the slides as it was right there in the document as well. The proposal document also gave us a much more clear story to tell when we presented to the TOC.  

I'm not sure if most projects present first then write the proposal, but if not, it might be useful to flip it around. 

Michael

On Tue, Oct 2, 2018 at 12:10 PM Chris Aniszczyk <caniszczyk@...> wrote:

I agree requiring the writing up front (instead of after the presentation) can be useful, here are some good examples imho:

Falco (sandbox)

https://github.com/cncf/toc/pull/157

https://github.com/cncf/toc/blob/a9099dbc47d981339277cf813b0f1a0f052e52a5/proposals/falco.adoc

Rook (sandbox->incubation)

https://github.com/cncf/toc/pull/139

https://github.com/jbw976/toc/blob/1f622935ae334271458beafcc8a36a9ce13603a3/reviews/incubation-rook.md

If we want a specific template happy to hear ideas, we can put it in the TOC repo.

On Tue, Oct 2, 2018 at 11:06 AM Camille Fournier <skamille@...> wrote:

Chris pointed out in chat that groups already are writing up docs for their proposals. However, the problem in my mind is that first we see a slide deck style presentation, then it is followed by a written doc.

I can't speak for Bob, but as someone who heavily adopted Amazon-style paper writing over presentations for much of my internal team, I far prefer reading thoroughly-written docs to watching slide shows. Right now, the details that we get in a lot of the proposals we vote on are not nearly as thorough as what we see in the presentations, and if we tried to replace the presentations with the proposal docs, we would not have much to go on. 

A typical design doc that I would review would have information like:

Summary

Project goals (possibly including user scenarios this is aimed at addressing)

Project non-goals

High-level design

Roadmap

There's no one exact way to write one, but if we want to move to a writing-driven review process at least for sandbox projects, we should agree on more questions we want answered as part of the doc and length recommendations (and possibly restrictions). I feel like this doc is going to be a hybrid product/tech design doc, so if there are any product managers who want to chime in with further suggestions I'm all ears.

C

--

Chris Aniszczyk (@cra) | +1-512-961-6719

I agree requiring the writing up front (instead of after the presentation) can be useful, here are some good examples imho:

Falco (sandbox)

https://github.com/cncf/toc/pull/157

https://github.com/cncf/toc/blob/a9099dbc47d981339277cf813b0f1a0f052e52a5/proposals/falco.adoc

Rook (sandbox->incubation)

https://github.com/cncf/toc/pull/139

https://github.com/jbw976/toc/blob/1f622935ae334271458beafcc8a36a9ce13603a3/reviews/incubation-rook.md

If we want a specific template happy to hear ideas, we can put it in the TOC repo.

On Tue, Oct 2, 2018 at 11:06 AM Camille Fournier <skamille@...> wrote:

Chris pointed out in chat that groups already are writing up docs for their proposals. However, the problem in my mind is that first we see a slide deck style presentation, then it is followed by a written doc.

I can't speak for Bob, but as someone who heavily adopted Amazon-style paper writing over presentations for much of my internal team, I far prefer reading thoroughly-written docs to watching slide shows. Right now, the details that we get in a lot of the proposals we vote on are not nearly as thorough as what we see in the presentations, and if we tried to replace the presentations with the proposal docs, we would not have much to go on. 

A typical design doc that I would review would have information like:

Summary

Project goals (possibly including user scenarios this is aimed at addressing)

Project non-goals

High-level design

Roadmap

There's no one exact way to write one, but if we want to move to a writing-driven review process at least for sandbox projects, we should agree on more questions we want answered as part of the doc and length recommendations (and possibly restrictions). I feel like this doc is going to be a hybrid product/tech design doc, so if there are any product managers who want to chime in with further suggestions I'm all ears.

C

--

Chris Aniszczyk (@cra) | +1-512-961-6719

Chris pointed out in chat that groups already are writing up docs for their proposals. However, the problem in my mind is that first we see a slide deck style presentation, then it is followed by a written doc.

I can't speak for Bob, but as someone who heavily adopted Amazon-style paper writing over presentations for much of my internal team, I far prefer reading thoroughly-written docs to watching slide shows. Right now, the details that we get in a lot of the proposals we vote on are not nearly as thorough as what we see in the presentations, and if we tried to replace the presentations with the proposal docs, we would not have much to go on. 

A typical design doc that I would review would have information like:

Summary

Project goals (possibly including user scenarios this is aimed at addressing)

Project non-goals

High-level design

Roadmap

There's no one exact way to write one, but if we want to move to a writing-driven review process at least for sandbox projects, we should agree on more questions we want answered as part of the doc and length recommendations (and possibly restrictions). I feel like this doc is going to be a hybrid product/tech design doc, so if there are any product managers who want to chime in with further suggestions I'm all ears.

C

Chris pointed out in chat that groups already are writing up docs for their proposals. However, the problem in my mind is that first we see a slide deck style presentation, then it is followed by a written doc.

I can't speak for Bob, but as someone who heavily adopted Amazon-style paper writing over presentations for much of my internal team, I far prefer reading thoroughly-written docs to watching slide shows. Right now, the details that we get in a lot of the proposals we vote on are not nearly as thorough as what we see in the presentations, and if we tried to replace the presentations with the proposal docs, we would not have much to go on. 

A typical design doc that I would review would have information like:

Summary

Project goals (possibly including user scenarios this is aimed at addressing)

Project non-goals

High-level design

Roadmap

There's no one exact way to write one, but if we want to move to a writing-driven review process at least for sandbox projects, we should agree on more questions we want answered as part of the doc and length recommendations (and possibly restrictions). I feel like this doc is going to be a hybrid product/tech design doc, so if there are any product managers who want to chime in with further suggestions I'm all ears.

C

Hi all

Apologies, there will be an updated Agenda tomorrow. Want to discuss some TOC business.  Will be asking project presentations to go on hold

Alexis

On Mon, 1 Oct 2018, 21:02 Chris Aniszczyk, <caniszczyk@...> wrote:

Here's the agenda deck for tomorrow: 

https://docs.google.com/presentation/d/1Xt1xNSN8_pGuDLl5H8xEYToFss7VoIm7GBG0e_HrsLc/edit?ts=5bae170b#slide=id.g25ca91f87f_0_0

We will be hearing from the keycloak project on top of welcoming Cheryl to the CNCF who will be working on ways to improve our end user ecosystem.

See everyone tomorrow!

--

Chris Aniszczyk (@cra) | +1-512-961-6719

Here's the agenda deck for tomorrow: 

https://docs.google.com/presentation/d/1Xt1xNSN8_pGuDLl5H8xEYToFss7VoIm7GBG0e_HrsLc/edit?ts=5bae170b#slide=id.g25ca91f87f_0_0

We will be hearing from the keycloak project on top of welcoming Cheryl to the CNCF who will be working on ways to improve our end user ecosystem.

See everyone tomorrow!

--

Chris Aniszczyk (@cra) | +1-512-961-6719

would like to remind TOC member to vote on WG proposition :)

On Thu, Sep 13, 2018 at 8:24 AM Sree Tummidi <stummidi@...> wrote:

+1 (non-binding)
Thanks,
Sree Tummidi

--

Zhipeng (Howard) Huang

Standard Engineer

IT Standard & Patent/IT Product Line

Huawei Technologies Co,. Ltd

Email: huangzhipeng@...

Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)

Research Assistant

Mobile Ad-Hoc Network Lab, Calit2

University of California, Irvine

Email: zhipengh@...

Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado

The etcd project is being proposed as an INCUBATION level CNCF project, sponsored by Brian Grant from the TOC: https://github.com/coreos/etcd

etcd is a consistent distributed key-value store, designed to hold small amounts of data that can fit entirely in memory and mainly used as a separate coordination service for other distributed systems like Kubernetes. It is used by a variety organizations and projects: https://github.com/coreos/etcd/blob/master/Documentation/production-users.md

Please vote (+1/0/-1) by replying to this thread; the full project proposal located here: https://github.com/cncf/toc/pull/143

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

--

Chris Aniszczyk (@cra) | +1-512-961-6719

+1 (non-binding)
Thanks,
Sree Tummidi

+1 non binding

---

From: cncf-toc@... <cncf-toc@...> on behalf of Ayrat Khayretdinov <akhayretdinov@...>
Sent: Monday, September 24, 2018 6:58:14 PM
To: Chris Aniszczyk
Cc: CNCF TOC
Subject: Re: [cncf-toc] [VOTE] etcd project proposal (incubation)

 

+1 non binding

On Tue, Aug 21, 2018, 10:57 Chris Aniszczyk <caniszczyk@linuxfoundation.org> wrote:

The etcd project is being proposed as an INCUBATION level CNCF project, sponsored by Brian Grant from the TOC: https://github.com/coreos/etcd

etcd is a consistent distributed key-value store, designed to hold small amounts of data that can fit entirely in memory and mainly used as a separate coordination service for other distributed systems like Kubernetes. It is used by a variety organizations and projects: https://github.com/coreos/etcd/blob/master/Documentation/production-users.md

Please vote (+1/0/-1) by replying to this thread; the full project proposal located here: https://github.com/cncf/toc/pull/143

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

--

Chris Aniszczyk (@cra) | +1-512-961-6719