fluxcd / community Goto Github PK

Move the talks section from /toolkit and /flux to this repo.

With Flux v2 approaching GA, new users get confused of which examples to use.

I propose we update https://github.com/fluxcd/flux-get-started and https://github.com/fluxcd/flux-kustomize-example with:

In preparation of Flux v2 GA this repository with Flux v1 examples has been archived. The Flux v2 equivalent of what is shown here can be found at flux2-kustomize-helm-example.

And https://github.com/fluxcd/multi-tenancy with:

In preparation of Flux v2 GA this repository with Flux v1 examples has been archived. The Flux v2 equivalent of what is shown here can be found at flux2-multi-tenancy.

After the readme update, we could archive these repos.

It'd be nice to have stats for the fluxcd org somewhere - https://github.com/marketplace/actions/github-repo-stats looks like a nice solution.

Flagger Slack has moved from Weaveworks to CNCF. AFAICT it's updated in all the docs, we updated the subject in Weave Slack, etc. but due to Weave Slack being on the free plan, we can't set it to read-only. I assume the only option is to just archive it?

cf https://weave-community.slack.com/archives/CGLQLLH9Q/p1614175088001800

Flux maintainers who work at different orgs need a secure method for sharing account credentials. For example, for the cncf-flux Zoom account, social media accounts such as twitter #41 etc.

We are using keybase now, but per the list at https://www.cncf.io/services-for-projects/ 1password has a built-in two-factor auth option, which can help make shared accounts more secure. That’s not a requirement but 1password is appealing for this reason.

I had opened a CNCF Service Desk ticket to discuss this, and everyone is on board. I am applying for an open source account at https://github.com/1Password/1password-teams-open-source.

As part of #21 am I able to be added to ServiceDesk, to tag-team on things like #26 (comment) as needed?

I believe the current iteration of the governance says this is a decision for @fluxcd/oversight-committee

There is no swag in the CNCF store for flux :(

https://store.cncf.io/search?q=flux

GH Action to crawl

• API equivalent of https://github.com/orgs/fluxcd/teams/maintainers/members and create a file that can be read by everyone
• (maybe) all MAINTAINERS files across fluxcd and create overview of who maintains what
• also who's steering committee

Various community blog posts, podcasts, etc prefix "Flux" with "Weaveworks". It should not be that way, now that Flux is a vendor-neutral CNCF project. Example search.

This is easy to accidentally overlook, since there are places where it makes sense to refer to both in the same sentence. For example "talking with folks from Weaveworks about Flux" is accurate and ok. But it's easy to shorten titles for marketing purposes, and the more examples out there like this the easier it is for new posts to follow in that vein.

This issue is to help consolidate efforts to fix existing incorrect references out in the wild.

In a earlier version of the governance doc, there was talk of a Community team: 7ad2418#diff-b60c6a93e9f74ee52e71bf33781c2870b8395c8c5a34f00f61305343cb8d8447L151-L169

Essentially what was brought up as overarching umbrella would normally fall into categories such as community, comms, programme management, contributor experience.

It'd be good to sketch out what this team would like to do and how. It might make sense to

1. Find out who'd be interested in helping jump-start this team (comment on this issue or talk to @scottrigby and myself)
2. Write up a brief charter (and link from main README.md)
3. Gradually build out responsibilities of the group (as opposed to trying to do too many things at once from the beginning)

Private security list for reporting vulnerabilities, per https://github.com/fluxcd/community/blob/main/SECURITY.md

• Create https://twitter.com/fluxcd
• Appeal suspended account
• Add account credentials to fluxcd.community file share

Status

• Account is up: @fluxcd
• Logo, description, and website is added. No posts yet. We could also use a header image, maybe of a kubecon talk or something.

See issue history for previous status.

Hello there,

please indicate your support for a working group on GitOps within SIG App Delivery. Please comment if you are willing to join

cncf/tag-app-delivery#27

It's important to have an audit trail for decisions, especially those made over governance. I propose we figure out a way to log decisions in some reasonably verifiable way -- commits with signatures come to mind. Whatever is figured out should be explained in the governance doc.

Current list is https://github.com/cncf/foundation/blob/master/project-maintainers.csv#L375

GitHub Username

@makkes

Requirements

• I have reviewed the community membership guidelines in community-roles.md
• I have subscribed to the cncf-flux-dev e-mail list https://lists.cncf.io/g/cncf-flux-dev/join
• I am actively contributing to 1 or more fluxcd GitHub org repos (eg. Flux, Flagger)
• I have two sponsors that meet the sponsor requirements listed in the community membership guidelines
• I have spoken to my sponsors ahead of this application, and they have agreed to sponsor my application

Sponsors

• @relu
• @squaremo

List of contributions to the Flux project

• PRs reviewed / authored:
  • fluxcd/image-reflector-controller#153
  • fluxcd/helm-controller#294
  • fluxcd/flux2#1782
  • fluxcd/kustomize-controller#374
  • fluxcd/pkg#169
• Discussions involved in & Issues responded to
  • fluxcd/flux2#1775
  • fluxcd/kustomize-controller#432
  • fluxcd/flux2#1842
  • fluxcd/kustomize-controller#391
  • fluxcd/kustomize-controller#373
  • fluxcd/image-reflector-controller#148
  • I also regularly join the weekly meeting and support users in the #flux Slack channel as much as I can
• Flux subprojects I am involved with (Flagger, Flux, Controllers)
  • mainly kustomize-controller but also helm-controller and flux2.

I wanted to join a CNCF slack SIG Contributor Strategy meeting and just happened to notice that some projects use their lists.cncf.io group calendar, while others list on the CNCF Public Events calendar https://www.cncf.io/calendar/.

That SIG also has their events listed in their lists.cncf.io group calendar, but it's out of date. In the CNCF #sig-contributor-strategy channel I was told the CNCF Public Events calendar is the source of truth.

Because of that, and also for greater visibility to potential new contributors, perhaps we should request to list Flux events on the CNCF Public Events calendar as well.

Problem

We don't currently have a manageable way for end users to stay up to date about Flux events/meetings.

1. As a stop-gap, we had enabled a setting on the cncf-flux-dev calendar: Send Notice To Group When Event Happens (tagged with #cal-notice)
   • Good idea but in retrospect this has become more annoying than helpful. Since the meetings are recurring and the notice rarely changes, it's just more one more thing for users to ignore, and would likely not notice when recurring meeting details change.
2. Flux events were added to the shared CNCF calendar, which is a google cal for ALL CNCF PROJECT MEETINGS
   • Users may subscribe this calendar to their, but by doing so they subscribe to ALL CNCF project events, which floods the calendars of most users

Proposed solutions

• Now: Disable #cal-notice automated event reminders on cncf-flux-dev mailing list calendar
• Short term: Help users understand how to keep up to date with Flux meetings/events
  • Suggestion: add policy to f/community README Communication section. Example:

    Changes to the recurring Flux meetings will be announced in Slack, Twitter, and the cncf-flux-dev mailing list.

• Longer-term: Move events to CNCF Community groups

We should try to find popular guides, posts or pages which refer to Flux v1 and see if we can add a quick note at the top to refer to Flux v2.

1. What would be a good paragraph we can paste at the top of these?
2. What are popular pages we would like to see changed?

Need a good quality banner for flux youtube
2560 x 1140 pixels

In fluxcd/flux2#367 we sort of envisioned moving ALL docs to https://fluxcd.io.

While that's still a possibility it might make things more complicated and harder to understand for our users. We have been getting feedback that v1 vs v2 is a bit hard to grasp and having both set of docs on the same pages, might make the docs search hard to use.

Having distinctly differently looking sites for docs might not be so bad after all. I've been thinking about renaming docs.fluxcd.io (which hosts the docs for f/flux and f/helm-operator) to legacy.fluxcd.io to make things even clearer than just adding the maintenance mode warning at the top. This might just be hard to implement as we can't easily do redirects through readthedocs?

Any ideas about this? The goal of this enterprise would to make it even clearer to users which docs they're looking at, right now it's

• https://fluxcd.io/docs for newest Flux and
• https://docs.fluxcd.io for legacy Flux projects

Simple, right...?

Need

While Flux communication strives for transparency, there are instances where certain teams need a secure channel or communication on specific things. One example is for reviewing and addressing security reports privately before a fix is found and it can be publicly disclosed. Another is assessing Code of Conduct violation reports. Most other things should be communicated about in public.

Status

I have added a keybase team fluxcd, and invited flux maintainers. All maintainers should be welcome to join this. There are private sub-teams so far for flux.security and flux.oversight, and the correct people have been added to those.

Add CODE_OF_CONDUCT.md

Since Flux v2 our collection of repositories has been growing, and this will likely continue to happen.

To make the process of creating a repository more easy and aligned with what we have set out in our GOVERNANCE.md, we can create a template repository so that much of the manual labour we have to do now is automated, and the same for all repositories.

(Incomplete) list of things that should be included:

• LICENSE
• DCO
• CODE_OF_CONDUCT.md

AFAICS there was no objections?

cc @kingdonb @scottrigby

Google Meet stopped allowing to record, so let's move to CNCF Zoom infrastructure for our meetings. Date and times will stay the same.

@squaremo offered help testing and double-checking calendar settings.

To-do

• Schedule meetings
• Figure out https://lists.cncf.io/g/cncf-flux-dev/calendar vs https://www.cncf.io/calendar/ situation
• Announce on Slack(s)
• Announce on mailing list
• Update https://github.com/fluxcd/community instructions
• Update https://docs.google.com/document/d/1l_M0om0qUEN_NNiGgpqJ2tvsF2iioHkaARDeh6b70B0/edit

consolidate our branding information in one doc,

have our logos live in the community site

I've floated the idea in the most recent FluxCD community meeting of a new "Bug Scrub" meeting with a similar structure to SIG-CLI's meeting of the same name, either in one of the existing weekly meeting timeslots to replace an existing meeting on the calendar, or at a new time about once a month. RFC ❓

Edit: for visibility, the meeting is scheduled at Wednesday June 30 at 8:00 ET/12:00 UTC

https://github.com/kubernetes/community/blob/master/sig-cli/README.md#meetings – the goal would be to visit every issue in every repo, (or pick one repo for the first try) check labels and make a decision about whether there are any mis-applied or missing labels that could be updated on the issue; optionally make an assignment of the issue to whoever has volunteered to follow it up, and close issues that are stale or drive-by with no response for a while, or otherwise look like they can be closed.

The maintainers will of course be welcome at this meeting, but their presence should not be required every time thanks to #75; we only need one person with Triage role present at the meeting to enable us to make a difference in the queues, if there is one person in attendance who can update labels, great; more than one, (we can try divide and conquer as we maybe find out that it is impossible to visit all the issues in every repo in an hour.)

If the meeting time does not work for everyone, there would be nothing stopping us from having more than one Bug Scrub meeting every month, with different hosts in different time zones, but for now I am just proposing one monthly meeting, and looking for opinions about what timing would be good for interested volunteers. 👍 If anyone has been to sig-cli bug scrubs, love to hear how it works. (The SIG-CLI bug scrub meetings are recorded for posterity and we can review their specific implementation, or just try out our own and shoot from the hip, no need to make this research project harder than needed.)

This meeting idea is simply to address issue queue hygiene and clean it up quickly, this is not meant to be a full queue review or spend time responding to support requests other than to label them properly; but before #75 we could probably not have done Bug Scrub meetings effectively without a maintainer present. It is not a meeting to discuss the outcome or resolution of complex topics, we can spend 2-5 minutes maximum on each issue to have a chance at actually getting through all issues (even if there are multiple members present with the triage role, and if we took the approach of divide and conquer multi-threaded without actually talking about each issue, it will be hard to get through even 50% of open issues, I am sure of this!)

https://www.youtube.com/playlist?list=PLbx4FZ4kOKntmgJqaT-iJ8tn4xat150yL

Now that @scottrigby landed #13 we can refer to the governance doc from the main README.

The Flagger authors are requesting for Flagger to join the fluxcd org.

Flagger extends Flux functionality with progressive delivery strategies like Canary Releases, A/B Testing and Blue/Green and it was specifically designed for GitOps style delivery.

Since the inception of the GitOps Toolkit, it’s clear that fluxcd/ will become more of a family of GitOps related projects. The Flagger maintainers are looking forward to making use of the toolkit components and simplifying Flagger this way. Consolidating the code-bases and thinking in terms of a “Flux Family of Projects” and writing up the roadmap accordingly should benefit both communities as a whole.

Background information:

• Approval of Flagger maintainers (Stefan Prodan and Takeshi Yoneda)
• Approval from Weaveworks to transfer Flagger and its copyright to fluxcd org (and thus, CNCF)
• Upcoming roadmap for Flagger includes GitOps Toolkit integration
• License, dependencies and copyright review can be found here

We would like to present at one of the next Flux meetings and state our intent in more detail. We are looking forward to your questions and a good debate.

https://github.com/fluxcd/community/blob/main/GOVERNANCE.md#maintainers

I get a 404 for:
https://github.com/orgs/fluxcd/teams/maintainers
https://github.com/orgs/fluxcd/teams/oversight-committee

Clarify the Flux project's policy on pull request requirements for merging, including when and when not to squash commits.

1. From quick chat, my understanding is the current maintainer preference is for PR authors to squash commits into understandable units of work. This could include history of working through a problem if there is a possibility that the older work may need to be referenced for any reason.
2. GitHub provides enabling one or more merge methods per repo: https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/configuring-pull-request-merges
   • Currently only merge commits are allowed on this repo
   • We could enforce squashed commits always by enabling only that option
   • Or we could enable either, and set a loose policy for when a Maintainer chooses one or the other
   • IMO the one problematic thing about requiring users to squash their own PR branch and force-push is that GitHub review comments can lose context when commit SHAs change. But the GitHub squash merge option retains review comments as the fork branch itself is not changed, commits are only squashed during the merge operation

I found out today that I had to go to https://lists.cncf.io/g/cncf-flux-dev/calendar - then click the "subscribe to calendar" link at the very end, and copy the .ics link into my Google calendar (add calendar, by url).

The Oversight Committee was initially be comprised of Flux Maintainers who have steered the project prior to the initial Governance document https://github.com/fluxcd/community/blob/main/GOVERNANCE.md.

The aspiration is that no one company or organization should have oversight of the overall project, however that was not yet realistic at the initial stage. The goal is to broaden maintainership to include a wider range of organizations during CNCF incubation.

To aid in this goal, we aim to build out requirements for the Oversight Committee role during incubation.

See #75

We should have a CNCF mailing list group email for Flux security, which we can document as part of #2.

The Flux family of projects needs a good community landing page. Kind of a "you are here ➡⭐" map of projects, what goes on where and how to get involved.

Given we are wrapping up #1, and have already agreed on requiring a sign-off on commits, we should bring a check in place to enforce this. The easiest way of doing this is to make use of the Probot: DCO GitHub action, and require the status check to pass before merge.

High priority:

• fluxcd/toolkit
• fluxcd/source-controller
• fluxcd/kustomize-controller
• fluxcd/helm-controller
• fluxcd/notification-controller
• fluxcd/image-reflector-controller
• fluxcd/image-automation-controller
• fluxcd/community
• fluxcd/pkg

Repositories not listed here have lower priority, but must be taken care of.

• fluxcd/flux
• fluxcd/website

As part of #3 our main repositories will need a SECURITY.md file. I will create PRs for

• f/flux2
• f/helm-controller
• f/flagger
• f/image-automation-controller
• f/image-reflector-controller
• f/kustomize-controller
• f/source-controller
• f/notification-controller

Shall I do f/flux and f/helm-operator too?

This is an umbrella issue to track youtube migration

Other notes

• the channel primary owner is currently daniel
• we might need some gsuite or something that is paid for by CNCF, to have an account [email protected] to own things like youtube channel, docs, forms
  • this probs belongs to some wider issue regarding community/contributor infrastructure

https://bestpractices.coreinfrastructure.org/

As part of setting up Flux with a youtube channel, need to reupload all the meeting recordings

[ ] publish playlist
[ ] put it on front of channel

Hey Flux team,

please indicate your interest in joining a working group on GitOps.

You can find the CNCF SIG App Delivery issue here: cncf/tag-app-delivery#27

We are starting to have diverging docs on how to contribute to Flux projects:

• https://github.com/fluxcd/flux/blob/master/CONTRIBUTING.md
• https://github.com/fluxcd/community/blob/main/CONTRIBUTING.md
• https://github.com/fluxcd/flux/blob/master/docs/contributing/get-started-developing.md

Do we want to unify these docs and keep in the community repo?

I realise that it might make sense to first figure out how we can pull in community docs into the fluxcd.io website and display them prominently before we replace docs elsewhere?

This might be a good opportunity to point out teams, initiatives and activities across projects more easily and keep things up to date this way.

We use this youtube playlist to add all Flux dev meeting recordings. I gave the collaboration link (to add yourself) to all Flux maintainers, currently only @scottrigby accepted the invitation, but it looks like only I can add to it.

Maybe this is https://support.google.com/youtube/thread/16543628?hl=en in disguise...?

As part of fluxcd/website#452 and fluxcd/website#449 we need to give access to the Flux calendar to @kingdonb @mewzherder @staceypotter and maybe others who schedule Flux events, so we can use the calendar as the single source of truth.

@fluxcd/maintainers WDYT?

https://fluxcd.io/community/ says

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

It'd be good to have a centralised Dev guide for the Flux family of projects, explain CI and tooling, etc.