See https://github.com/dholbach/toc/blob/flux-graduation/proposals/graduation/flux.md for a more nicely readable representation of the doc in this branch.

@dholbach - we have April 19th's meeting available for this discussion, does this work for you?

Yes 😁

Fantastic, you are on the Public TOC Agenda

The TOC discussed in a public meeting on April 19th: next steps are that the TOC will review and come back with recommendations for the project, no sponsor has yet been determined.

I would recommend Flux engage Security TAG Security Pals program (which i already posted in the security tag channel to expect) for that multi-tenancy review. Multi-tenancy generally is a harder concept from a security perspective so definitely worthwhile and i can see such a review being mutually beneficial for the broader community in generating guidelines for multi-tenancy of cloud native projects.

@amye has posted the video from the call today here : https://www.youtube.com/channel/UCvqbFHwN-nwalWPjPUKpvTA

Some items from my notes are:

• finalizing steering/bootstrap and write down the governance structure and selection/election process would be good
• documenting the decision making process(es) especially around larger decisions like flagger would be better as it will make it easier/simpler for next time when things come up
• good to see diversity of maintainers for sure. would be good to build a pipeline/contributor-ladder to mentor the next set of folks (yep, it's hard!)
• cross check if items from incubation were already wrapped up
• please think about dependencies and risks

Just adding a note here about the progress we've already made on a contributor ladder / community onboarding that starts with the "community member" role and the process to become a "project member" which is the lowest contributing rung:

https://github.com/fluxcd/community/blob/main/community-roles.md

This is where we have described in as much detail as possible the steps required to become a maintainer and get write access to a project. I was involved in helping solidify this process as it was not as well-documented when I was first onboarded into the FluxCD org over one year ago.

The "Project Member" role was then created to help smooth the transition a bit from Zero-to-maintainer. 👍

Thanks for considering the Flux project's application!

In c373480 I sumarised the questions asked in here and gave some of our answers. We are going to respond to the rest in the next days.

Thanks for the feedback so far!

@dholbach thanks! if you have covered the following questions already great! if not please feel free to update. this is a consolidated feedback from the TOC fyi.

Feedback for Flux

Thanks for the great discussion in our TOC call with Flux folks looking to graduate. Here is a set of items for the Flux team to work through and then we can pick up the next step of finding a sponsor for Flux.

Major items:

• Flagger : What is the proposed plan for flagger going forward (other than integrating their docs into flux website)?
  • flagger has potential to become a project in its own right, is the intent to execute Flux governance over flagger for its duration?
• Sustaining contributions : We are glad to see a maintainers from different companies, but for most companies it is just one person. The TOC recommends Flux establish a Project Continuity and Growth plan that outlines community roles and paths to achieve those roles to both increase the levels of participations from already engaged organizations as well as draw additional active participants.
• Governance: Finalize steering or bootstrap governance and document the structure within the projects docs and repo that clearly explains the criteria, selection, and election process. We recommended engaging with Contributor Strategy TAG
• Multi-tenancy: Submit a Security Pals issue to Security TAG to request a Security Pal to assist in a multi-tenancy RFC review.

Minor items:

• Cross check if items from incubation were already wrapped up

@dholbach @tamao Just to set expectations and fully understanding your desire to move quickly, i am not sure a Kubecon EU timeline is realistic. it would not be good to rush the process. Let's concentrate on making progress for sure. thanks!

Re Flagger questions from #796 (comment)

Flagger : What is the proposed plan for flagger going forward (other than integrating their docs into flux website)?

Flagger was designed to work with Flux and it's a natural fit for the GitOps toolkit. This is already noted briefly in this PR under "Why is the Project ready to Graduate?" In short, the plan is to add GitOps Toolkit compatibility to Flagger. Here are some more links. See the top section under Flagger's Roadmap in its README, and was added by this PR in Oct 2020.

• flagger has potential to become a project in its own right, is the intent to execute Flux governance over flagger for its duration?

Flagger is intended to remain a sub-project of Flux. There are 133 contributors, 60 with more than one commit, but @stefanprodan has made 1300 commits. The closest 2nd is Takeshi Yoneda, who has made 50 commits, and is the only co-maintainer. Part of the reason for this move is that after Flagger is refactored on top of flux2 controllers, a wider group of existing maintainers can help support it in addition to Stefan.

@dims would it be helpful to add more of this explanation to this PR, or do you feel this is answered well?

@stefanprodan also said he is happy to follow up if there are any more detailed questions about Flagger.

@scottrigby I added your comment in 92fff3f and referenced discussions we started with TAG Contributor Strategy and TAG Security.

hey @scottrigby i will review in a day or so, feel free to update the PR itself to add any additional stuff in the meantime. (dealing with some 🔥 's)

@dholbach thanks for adding 4+ commits to the original to augment the case for graduation for Flux.

I love the direction of fluxcd/community#203 as well getting input from folks like @jberkus. Let's treat the Transform Oversight Committee item into a blocker and get the Governance processes documented and implemented. The other changes can go on in parallel but are not blockers in any way.

Please come back to us when the governance changes are merged/activated and folks are identified/seated according to the new governance processes.

Thanks so much for the reviews and feedback everyone - we feel privileged to be part of this great and collaborative community!

Multi-tenancy: Submit a Security Pals issue to Security TAG to request a Security Pal to assist in a multi-tenancy RFC review.

TAG Security leadership has met with Flux maintainers and this has been kick-started and is progress. Next steps are tracked here.

@lumjjb Thanks for confirming that things have gotten started. Just to be clear, this step is not a blocker and can continue in parallel. thanks!

In fluxcd/community#203 and fluxcd/community#207 we implemented the new Flux Governance. Thanks again for the help of @jberkus and TAG Contributor Strategy. We were able to adopt quite a few sections from the project template. 💖

For those of you who enjoy Governance docs, here is the summary of the top-level changes:

1. More clearly define contributor ladder
   • explicitly state that we invite non-code contributions (and received the first project member application primarily based on non-code contributions today)
   • lay out what we expect from new maintainers (define "significant and sustained contributions")
2. Put consensus-finding at the center of our governance (this has been our practice so far)
3. Define two overlapping sets of escalation points: core maintainers and org admins
   • core maintainers help with finding consensus, resolve CoC violations, remove inactive maintainers if necessary, etc
   • org admins have no decision making power, but access to buttons that e.g. create / delete repositories (in principle: security and availability reasons)
4. Break up Governance documentation into separate docs which can take more space to a) defining the roles in our community, b) the Governance doc itself (which explains the big picture + decision making) and c) process documentation that can serve as a "how to interact with the Flux community"
5. To avoid impasse situations we chose to go with a certain set of decisions that can have a deadline date defined by which a quorum of 2/3 is sufficient, but keep consensus as necessary requirement (so no veto votes). We expected Unanimity before, which can be hard if you have folks on longer holidays or other times of unavailability.

This new model is more realistic, fail-safe and very closely based on how we actually implemented decision making before.

If you are curious about any of the above, feel free to ask here, give me a ping on Slack or check out fluxcd/community#203 or https://fluxcd.io/governance/

https://github.com/dholbach/toc/compare/41da826a2465d07cd12aa45b8651abb683c376aa...flux-graduation are all the changes since the initial request - LMK if you want me to squash these commits.

@dholbach and flux team, thanks a ton for working on this set of asks from TOC. I am glad governance is sorted out and it reflects what you do in day-to-day basis. Let's treat that blocker as fixed and now we can find you a sponsor.

I'm happy to see the Flux governance is in better shape which unblocks this moving forward.

I'm willing to sponsor.

@mattfarina thanks a ton! first step is to update the DD document. For the last few DD docs, TOC members used threads in a public channel to work with the project folks for back and forth ( as well as the google doc comments etc to track TODO(s) etc. In parallel, the flux team can pick 3 end users of flux and set up interviews. (will talk to you async on the format of the interviews and what to gather etc - interviews are fully confidential of course! we do collect notes so that other TOC members can get an idea of how the interviews went )

The public voting period has started 🎉 https://lists.cncf.io/g/cncf-toc/topic/vote_flux_for_graduation/95047098