CDF TOC Principles statement #2

kohsuke · 2019-03-29T22:47:44Z

Based on the original google doc version with some changes.

To see the edits since the Google Doc version, see the diff past the initial commit.

It seems to me that a round of feedbacks have come and quieted down, and if that continues, we can vote and approve this in the next TOC meeting.

This version is based on https://docs.google.com/document/d/1s1vF0bEvlKk7bgra2-456eNU_uknZQ8l3HMc797ApJo/edit as of this writing. Signed-off-by: Kohsuke Kawaguchi <[email protected]>

My comment to the original doc seems to have earned some support, so I'm adding it here. Signed-off-by: Kohsuke Kawaguchi <[email protected]>

Signed-off-by: Kohsuke Kawaguchi <[email protected]>

LinuxSuRen · 2019-03-30T04:36:39Z

Adding a refer this document in the file README.md might be helpful.

michaelneale · 2019-03-31T23:40:00Z

I like it!

stmcginnis

Looks like a great start to me.

aglover · 2019-04-01T13:58:17Z

LGTM, thanks for putting this together @kohsuke!

rtyler

Overall looking good to me, thanks @kohsuke

rtyler · 2019-04-01T13:52:48Z

PRINCIPLES.md

+## Technical Vision of CD
+Security, reliability, velocity: Pick Three!  The TOC “believes in the power of Continuous Delivery to empower developers and teams and to produce high quality software more rapidly,” because the continuous delivery practice should result in strict improvements across all three dimensions for developers. They should not have to choose between moving fast and not breaking things.
+
+**Security**: Software has eaten the world. Vulnerabilities everywhere can have outsized impact on end users. Delivery is one of the first and most important places to inject and enforce best practices around security. We need to respect this opportunity and drive the industry forward to provide better, more secure software for everyone.


Security: Software has eaten the world.

This assertion seems a awkward and out of place here. The overall point, that software is increasingly involved in our day to day lives, would be better made in the preamble of this section as I think all three dimensions could/should speak to that.

I've moved that one sound bite up and padded some text in the hope that it'll flow better.

rtyler · 2019-04-01T14:01:19Z

PRINCIPLES.md

+**Overall ecosystem fit**: CD is a broad space and no "one tool" can solve everything for everyone. Projects should fit into the broader ecosystem - whether through plugin-style extensibility,  explicit interface exposure/usage, or something else.
+
+## Communities That Produce Such Software
+In order to “foster and sustain the ecosystem of open-source, vendor neutral projects through collaborations and interoperability,” the TOC values these characteristics in the communities that produce the projects, and we seek communities that share these values:


I would suggest one other criteria, but I'm not entirely sure how to word it. Of course this is just my opinion so the TOC should feel welcome to ignore it 😸 )

"Heterogeneous" perhaps? I hesitate to use "diversity" as the common understanding of what that means in teh tech industry isn't quite what I am suggesting.

Basically the communities which should/would succeed and thrive in the CD space, and CDF at large, would be those who are comprised of various skillsets of people, from different specialties in the software delivery process.

For example, a community is greatly improved by the presence of Systems Administrators/Operators, Developers, Designers, Test Automation folks, writers, and advocates. Compared to a community which is largely/entirely just sysadmins, or developers.

I think I get where you are going. It's the idea that more inputs make things better. the closest in the existing text is "listen to other projects and people with different thoughts," so I'll expand that part a little bit further.

rtyler · 2019-04-01T14:01:34Z

PRINCIPLES.md

+## Greater Whole
+The whole should be greater than the sum of all parts. A successful CDF should provide be a single place to look for best practices, guidance and documentation as well as tooling and projects. Customers looking to improve their delivery practices should have to look no further than the resources provided by the CDF, regardless of their software stack, platform or industry.
+
+**Benefits**: The CDF should not be a "grab-bag" of projects, and projects do not need to be hosted in the CDF to interoperate with projects that are in the CDF. Projects in the CDF should either provide a unique benefit to the CDF or uniquely benefit from being in it.


As per suggestion from cdfoundation#2 (comment) Signed-off-by: Kohsuke Kawaguchi <[email protected]>

... the best I can. Signed-off-by: Kohsuke Kawaguchi <[email protected]>

kohsuke · 2019-04-02T16:56:34Z

I've incorporated the feedback from @rtyler and @LinuxSuRen

dlorenc · 2019-04-03T13:41:17Z

Looks great to me!

rpaik · 2019-04-04T15:40:59Z

PRINCIPLES.md

+## Greater Whole
+The whole should be greater than the sum of all parts. A successful CDF should provide be a single place to look for best practices, guidance and documentation as well as tooling and projects. Customers looking to improve their delivery practices should have to look no further than the resources provided by the CDF, regardless of their software stack, platform or industry.
+
+**Benefits**: The CDF should not be a "grab-bag" of projects, and projects do not need to be hosted in the CDF to interoperate with projects that are in the CDF. Projects in the CDF should either provide a unique benefit to the CDF or uniquely benefit from being in it.


I missed the first TOC meeting, so apologies if I'm missing some context. Will the project acceptance process be a separate document? From the Google doc, it looked like it was a separate section in the Principles document so I wasn't sure.

Regardless, would it make sense to make some reference to it in this document? For example, there could be a sentence at the end of Benefits that says, "new project proposals to CDF will be evaluated according to criteria outlined in (insert link here for Project Proposal Process doc/section)"

Yes, it's a separate document being worked on in #3.
When it gets merged we'll add a reference.

fdegir

Thanks a lot for kicking this off. I put some comments inline and also a more general/cosmetic comment here. There are some inconsistencies between how CD is talked about throughout the document.

Continuous Delivery
Continuous delivery
CD
continuous delivery

It might be better to stick to one.

fdegir · 2019-04-05T22:23:57Z

PRINCIPLES.md

+# CDF TOC Principles
+
+## What We're Looking For
+We are looking for high-quality projects that improve the general practice of "continuous delivery" for all software development. We want to drive the modernization of continuous delivery, but make this available to everyone.


I think it would be beneficial to mention CI as well since some communities have been successfully establishing new CI/CD practices. Apart from that, some organizations might be at the start of their CI/CD journey and explicitly stating the fact that continuous delivery itself might not solve all their challenges alone could be useful for them to set their strategy.

Something like

"We are looking for high-quality projects that improve the general practice of "continuous delivery" that is built by leveraging "continuous integration" principles and best practices for all software development.

The idea that I internalized from your feedback is that it's worthwhile for some audience to call out that 'CD' that we refer here encompasses a lot. I've modified the text accordingly.

fdegir · 2019-04-05T22:29:20Z

PRINCIPLES.md

+1. believes in the power of Continuous Delivery to empower developers and teams and to produce high quality software more rapidly;
+believes in the open source solutions collectively addressing the whole software delivery lifecycle;
+1. fosters and sustains the ecosystem of open-source, vendor neutral projects through collaborations and interoperability; and
+1. advocates this idea and encourages collaborations among practitioners to share and improve their practices.


why not establishing new practices as a goal as well?

This text is a verbatim copy of the CDF mission, so I won't modify it here.

I think "improve their practices" includes what I think you are referring to. As people's practices improve, some will be inevitably pushing the state of the art forward.

fdegir · 2019-04-05T22:34:09Z

PRINCIPLES.md

+
+**Security**: Vulnerabilities everywhere can have outsized impact on end users. Delivery is one of the first and most important places to inject and enforce best practices around security. We need to respect this opportunity and drive the industry forward to provide better, more secure software for everyone.
+
+**Velocity**: Continuous delivery practices have been known to improve the velocity of software development for a long time. Helping users adopt these practices, and helping projects further increase velocity will help the industry deliver more value to users faster.


more value and perhaps new services to end users.

i am not a business person but highlighting that one of the things CD helps achieving is the ability to bring new services to end users much faster than before. this could help realize the importance of CD to decision makers.

I think "more value" does cover new services/products/apps. To me it's intentional that we talk broadly about all kind of software here, not just webapps.

fdegir · 2019-04-05T22:41:42Z

PRINCIPLES.md

+## Software That Enables Such CD
+To help “practitioners to share and improve their practices,” the TOC upholds these values, and we seek projects that share them:
+
+**Pragmatic**: The most important attribute of a project is how useful it is to actual customers. Purity in design and implementation comes second to solving real-world problems for real users.


why just customers? wouldn't it make sense to be inclusive and state that the projects that helps others such as individual developers, open source communities, and the customers, striving to make things even better for everyone?

or the "customer" reference here implicitly include the communities and individual developers as well?

I think @fdegir makes a good point. We already have the word "users" in the sentence so maybe replace the word customers with users?

I can see how "customer' might make some people think about $$$. I changed as per the suggestion.

fdegir · 2019-04-05T22:47:51Z

PRINCIPLES.md

+**Fairness**: A community that seeks to avoid undue influence, bad behaviours, and/or “pay-to-play” decision-making.
+
+## Greater Whole
+The whole should be greater than the sum of all parts. A successful CDF should provide be a single place to look for best practices, guidance and documentation as well as tooling and projects. Customers looking to improve their delivery practices should have to look no further than the resources provided by the CDF, regardless of their software stack, platform or industry.


I really think avoiding words like "customers" would help make CDF a true community and not an entity that sees others as only customers.

Point taken.

The document already uses 'end users' to refer to the users of the applications, and 'practitioners' to refer to people who develop those apps, so I consolidated to those two words.

Signed-off-by: Kohsuke Kawaguchi <[email protected]>

The idea that I internalized is that it's worthwhile for some audience to call out that 'CD' that we refer here encompasses a lot. See: cdfoundation#2 (comment) Signed-off-by: Kohsuke Kawaguchi <[email protected]>

@fdegir

@fdegir and @rpaik wrote that "customers" evoke $$$ to some people. The document already uses 'end users' to refer to the users of the applications, and 'practitioners' to refer to people who develop those apps, so I consolidated to those two words.

caniszczyk · 2019-04-19T19:01:47Z

everyone happy with this version, enough for us to formally vote on this?

demobox · 2019-04-22T13:19:34Z

PRINCIPLES.md

+Copied from [the charter document](https://github.com/cdfoundation/charter/blob/master/CHARTER.md) as the starting point:
+
+1. believes in the power of Continuous Delivery to empower developers and teams and to produce high quality software more rapidly;
+believes in the open source solutions collectively addressing the whole software delivery lifecycle;


[minor] "believes in open source" (i.e. no "the")?

I trust that your edit is correct, but this text was copied verbatim from the GB charter document, so I don't think I should edit it just here. I will open a PR in the upstream to be applied next time the charter gets edited.

PRINCIPLES.md

Signed-off-by: Kohsuke Kawaguchi <[email protected]>

caniszczyk · 2019-04-23T15:44:09Z

I kicked a vote off here: https://lists.cd.foundation/g/cdf-toc/message/39

kohsuke · 2019-04-23T15:44:51Z

Oops, you beat me to it!

dlorenc · 2019-04-23T18:25:27Z

Looks like the vote is complete. Should we merge?

Vote: https://lists.cd.foundation/g/cdf-toc/message/39 Signed-off-by: Kohsuke Kawaguchi <[email protected]>

caniszczyk · 2019-04-29T15:24:58Z

just for reference, binding +1 votes:

kk: https://lists.cd.foundation/g/cdf-toc/message/42
dan: https://lists.cd.foundation/g/cdf-toc/message/44
andy: https://lists.cd.foundation/g/cdf-toc/message/45
james: https://lists.cd.foundation/g/cdf-toc/message/47

updating from master

kohsuke added 3 commits March 29, 2019 15:34

Added the initial version.

4480fff

This version is based on https://docs.google.com/document/d/1s1vF0bEvlKk7bgra2-456eNU_uknZQ8l3HMc797ApJo/edit as of this writing. Signed-off-by: Kohsuke Kawaguchi <[email protected]>

Added 'collaboration' as a value

1fd8844

My comment to the original doc seems to have earned some support, so I'm adding it here. Signed-off-by: Kohsuke Kawaguchi <[email protected]>

Adding the record of approvals

594d940

Signed-off-by: Kohsuke Kawaguchi <[email protected]>

stmcginnis reviewed Apr 1, 2019

View reviewed changes

rtyler reviewed Apr 1, 2019

View reviewed changes

kohsuke added 2 commits April 2, 2019 09:41

Added a reference from README

dae4fd0

As per suggestion from cdfoundation#2 (comment) Signed-off-by: Kohsuke Kawaguchi <[email protected]>

Incorporated feedback from Tyler.

05c4651

... the best I can. Signed-off-by: Kohsuke Kawaguchi <[email protected]>

rpaik reviewed Apr 4, 2019

View reviewed changes

fdegir reviewed Apr 5, 2019

View reviewed changes

kohsuke added 3 commits April 9, 2019 17:27

Refer to CD as "Continuous Delivery" consistently

843b5a4

Signed-off-by: Kohsuke Kawaguchi <[email protected]>

Incorporated @fdegir's feedback to call out CI.

4a78c37

The idea that I internalized is that it's worthwhile for some audience to call out that 'CD' that we refer here encompasses a lot. See: cdfoundation#2 (comment) Signed-off-by: Kohsuke Kawaguchi <[email protected]>

demobox reviewed Apr 22, 2019

View reviewed changes

PRINCIPLES.md Outdated Show resolved Hide resolved

kohsuke and others added 2 commits April 23, 2019 08:32

Minor edit as suggested by @demobox

dd15d32

Signed-off-by: Kohsuke Kawaguchi <[email protected]>

Add a version v1.0

0786fd4

Recording the result of binding votes

1b0172d

Vote: https://lists.cd.foundation/g/cdf-toc/message/39 Signed-off-by: Kohsuke Kawaguchi <[email protected]>

kohsuke merged commit ce81926 into cdfoundation:master Apr 23, 2019

tequilarista added a commit that referenced this pull request Nov 7, 2019

Merge pull request #2 from cdfoundation/master

53afde9

updating from master

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

CDF TOC Principles statement #2

CDF TOC Principles statement #2

kohsuke commented Mar 29, 2019

LinuxSuRen commented Mar 30, 2019 •

edited

Loading

michaelneale commented Mar 31, 2019

stmcginnis left a comment

aglover commented Apr 1, 2019

rtyler left a comment

rtyler Apr 1, 2019

kohsuke Apr 2, 2019

rtyler Apr 1, 2019

kohsuke Apr 2, 2019

rtyler Apr 1, 2019

kohsuke commented Apr 2, 2019 •

edited

Loading

dlorenc commented Apr 3, 2019

rpaik Apr 4, 2019

kohsuke Apr 9, 2019

fdegir left a comment

fdegir Apr 5, 2019

kohsuke Apr 9, 2019

fdegir Apr 5, 2019

kohsuke Apr 9, 2019

fdegir Apr 5, 2019

kohsuke Apr 9, 2019

fdegir Apr 5, 2019

rpaik Apr 5, 2019

kohsuke Apr 9, 2019

fdegir Apr 5, 2019

kohsuke Apr 9, 2019

caniszczyk commented Apr 19, 2019

demobox Apr 22, 2019

kohsuke Apr 23, 2019

caniszczyk commented Apr 23, 2019

kohsuke commented Apr 23, 2019

dlorenc commented Apr 23, 2019

caniszczyk commented Apr 29, 2019 •

edited

Loading


		Security: Vulnerabilities everywhere can have outsized impact on end users. Delivery is one of the first and most important places to inject and enforce best practices around security. We need to respect this opportunity and drive the industry forward to provide better, more secure software for everyone.

		Velocity: Continuous delivery practices have been known to improve the velocity of software development for a long time. Helping users adopt these practices, and helping projects further increase velocity will help the industry deliver more value to users faster.

CDF TOC Principles statement #2

CDF TOC Principles statement #2

Conversation

kohsuke commented Mar 29, 2019

LinuxSuRen commented Mar 30, 2019 • edited Loading

michaelneale commented Mar 31, 2019

stmcginnis left a comment

Choose a reason for hiding this comment

aglover commented Apr 1, 2019

rtyler left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kohsuke commented Apr 2, 2019 • edited Loading

dlorenc commented Apr 3, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fdegir left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

caniszczyk commented Apr 19, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

caniszczyk commented Apr 23, 2019

kohsuke commented Apr 23, 2019

dlorenc commented Apr 23, 2019

caniszczyk commented Apr 29, 2019 • edited Loading

LinuxSuRen commented Mar 30, 2019 •

edited

Loading

kohsuke commented Apr 2, 2019 •

edited

Loading

caniszczyk commented Apr 29, 2019 •

edited

Loading