I wasn't sure how to fit this into a comment of the Google Doc, so instead I'm going to write it here.
I was reading what Dan wrote more carefully, and I thought it'd help to dissect multiple layers in it. - The charter lays out the mission of the CDF. This is what the CDF holds self-evident. This is controlled by the GB, and we the TOC start from here.
- There's high level technical values/traits/translation of CD that the TOC holds self-evident. This paints the picture of the practice our projects and their software should enable to users. "Security, reliability, velocity: Pick Three" and the following two bullet items that expands security and velocity maps to this part.
- Then there are what the TOC want in software that projects produce. Practicality, Maintainability, Portability, Platform/Stack agnostic sections fit in this layer. Extensibility would be in here as well
- Then there are what the TOC want in projects that produce those software. Governance section, what I suggested as a comment as "collaborations" fit in this layer. Openness, fairness belongs here as well.
Does this distinction make sense for others? If so, and if Dan is OK, I'm happy to reorganize the text accordingly.
I think this will help prospective projects understand what the CDF is looking for and how they need to evolve once they join. And that naturally leads to the acceptance criteria and project lifecycle conversations -- that is, we want projects that share the same technical interpretations of CD (#2), projects that are willing to go through the evolution to hit quality software that meets #3, and projects that are willing to evolve its governance to hit #4. The graduation criteria follows from #3 & #4.
That should also serve as a brake pedal for the values to become too numerous and onerous.
On Thu, Mar 21, 2019 at 8:05 AM Kohsuke Kawaguchi < kk@...> wrote: Yes, this is great! I've made one pass. I gotta leave the keyboard now, but I'll come back to this later for more.
On Thu, Mar 21, 2019 at 7:38 AM Andy Glover via Lists.Cd.Foundation <aglover=netflix.com@...> wrote:
This is great, thanks for putting this together, Dan!
-Andy
On Thu, Mar 21, 2019 at 7:30 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks Chris! I threw some initial ideas on principles/values, etc. down here. I started with some of the format from the CNCF documents.
On Fri, Mar 15, 2019 at 4:41 PM Chris Aniszczyk < caniszczyk@...> wrote: I'm happy to see this discussion going on and my advice would be to focus on two things:
There are good ideas to pull from CNCF and other communities out there, with an opportunity to put your own spin on it.
2) establish a project acceptance/lifecycle process:
I'd start there before worrying about landscapes or new projects, establishing a set of values and process the TOC and the community agrees on is critical. While this discussion is happening, the rest of the TOC will be filled out by the GB over the coming couple months (after the GB meets for the first time next month).
Those are my two cents :)
On Fri, Mar 15, 2019 at 11:01 AM Dan Lorenc via Lists.Cd.Foundation <dlorenc=google.com@...> wrote:
Thanks for sending this! Some thoughts inline, and I look forward to discussing more in person. On Fri, Mar 15, 2019 at 12:51 PM Kohsuke Kawaguchi < kk@...> wrote: I'm back to work from the hectic week that is OSLS. As everyone said it before, the launch went really well. Here are some thoughts that I'm starting to form that's relevant to what TOC might want to take on. - Several people who are behind some of the "CD" projects came up to me and showed their interest to bring their projects under the CDF. All of them are overlapping to some degree with some of the 4 projects that we already have. That by itself isn't a bad thing, but it did make me wonder how we'd approach them. I feel like the industry and vendors are watching what color this foundation will take in the next few months, and if we build a super market with 4 different kind of apples without any oranges, I don't know if that's the message we want to send.
This came up with me as well. I think we should try to understand the motivations these companies have for placing these projects in a foundation and make sure we have places/levels in place for the broad range of projects/motivations. For example, some companies seem to be motivated by: - getting a broader contributor base
- solving a large industry problem that can't be done in isolation
- marketing, other project support
- credibility of being in a foundation
We should prioritize establishing a set of areas where the appropriate type of collaboration can take place for each project. CNCF has sandbox, incubating, graduation, etc. to help. Other foundations have other types of "levels".
A sign of a healthy ecosystem would be projects both inside and outside the foundation interoperating and building on each other. We should also work to dispel any notions that projects must be in the CDF to interoperate with the CDF projects. A CDF landscape would be a big help here. I think Chris said these are pretty easy to setup.
- But another way to look at this is that the reasons those 4 different apples exist (in various different stages of maturity) is that devops teams needed to scratch their itches, and I'd think a part of the reason is that they weren't aware, or didn't feel comfortable joining other projects. I think we can solve those problems here, and that might encourage more collaboration and result in more consolidation, which I think is a better outcome.
Definitely, vendor-neutral owned projects can be much more welcoming to others. - From there, my mind went to "how do we solve that?" There are a lot of things we can do for sure, and some of those are already mentioned by people when we met. For example, putting people behind those projects together and sharing what problems they are trying to solve to each other would be a great step. Another one I thought is to set a bar or provide help to participating projects about transparency to the governance and/or the vision, which help other organized potential contributors to see if it's aligned with what they need, or they need to build something else. That kind of visibility feels like a sign of maturity anyway.
- Relevant to above visibility/transparency is that people wanted understand where the collaboration with Tekton and Jenkins are happening and what that means.
Right! I look forward to having these conversations in central, public discussions hosted by the CDF going forward. They've mostly been informal adhoc meetings so far.
- From the "4 different kind of apples without any oranges" thought, another place my head went is that it'd be great to recruit projects more proactively (or at least build relations with.) I think that requires drawing a mental map of the super market, that is the CD space.
- Finally, completely tangentially, I always thought there are lots of rooms for more API/interop focused small projects. I'm a big fan of Grafeas. Another example is the machine readable input/output to test frameworks --- there's the test report format that JUnit started but now used everywhere from nosetest to rspec, and that could really use a name and a schema.
A few other CDF members expressed interest in Grafeas as well. I'll follow up on this in the next couple of weeks. I think there's definitely a need for a CD-focused, secure metadata standard for interop. - Then I'd love to see a mechanism that allows CI/CD tool to specify a subset of tests to run and its order, for more frictionless parallelism and efficiency. It's all fairly trivial things but it takes putting the right group of people in the room to make happen!!
As you can see, random unorganized thoughts here. Love to hear other people's own thoughts.
-- Kohsuke Kawaguchi
--
--
Andrew Glover Director of Delivery Engineering Netflix, Inc.
--
Kohsuke Kawaguchi
|
