[tracking] Preparation for Falco Graduation

[leogr]

Motivation

We recently discussed the future of Falco, and we think it is in good shape and ready to try for CNCF graduation again. However, before submitting the graduation proposal again, some preparation is required. This issue aims to track the progress of this process.

Refs

• relevant community calls: 2022-06-29, 2022-07-06

Action items

We will add action items as they come and constantly update this issue with their progress.

• Review of the maintainer list
  • [tracking] cleanup inactive maintainers evolution#157
• Getting in touch with Tag Security leads
  • Email sent
  • Response: A new audit is reccomended
• Requesting a new security audit

[jasondellaluce]

Just opened another tracking issue for the maintainer list review

[leodido]

Please help me understand how the fact that in the TODO list for graduation the first (and only) point is about deliberately removing maintainers (without contacting them and respecting the GOVERNANCE) helps with one of the main concerns

the vendor independence of the Falco project

that were raised during the proposal for graduation last year.

Ref:
cncf/toc#641 (comment)

[leogr]

Please help me understand how the fact that in the TODO list for graduation the first (and only) point is about deliberately removing maintainers (without contacting them and respecting the GOVERNANCE) helps with one of the main concerns

the vendor independence of the Falco project

that were raised during the proposal for graduation last year.

Ref: cncf/toc#641 (comment)

Hey Leo,

I understand this issue can be confusing. It's still a work in progress and I have not found the time to complete it. Sorry.

I tried to clarify how and why we are reviewing the maintainer list in falcosecurity/evolution#157. I hope that will help to understand that the process fully respects our governance.

The concern regarding vendor independence is, however, unrelated to this. The SIG-Security raised that concern because the libs and drivers' codebase transition from the origin organization to Falcosecurity was not fully completed. Your comment in that PR (ref cncf/toc#641 (comment) ) explains precisely that. (You perfectly know the hard work we did together to address that issue 🤗 ). The roadmap you indicated in that comment is now achieved.

The only point still open is regarding the security audit. In this regard, I recently contacted the Security TAG lead asking for advice. They definitively confirmed that it makes sense to request an additional security audit. And we are working on that.

I'm sorry again if this issue was confusing. I'll do my best to update this issue as soon as possible. And thank you for raising your concerns, it helped to clarify.

[leodido]

Keep it short.

How does removing external maintainers - without discussing their involvement with them, one by one - help with vendor independence?

[leogr]

Keep it short.

How does removing external maintainers - without discussing their involvement with them, one by one - help with vendor independence?

Hey @leodido

I've tried my best to make it short 👇

1. We are proposing to remove inactive maintainers on a per repo basis;

2. We are discussing their involvement publicly (so including them) via issues and PRs;

3. Removing inactive maintainers neither helps nor hinders vendor independence.

N.B.

• there are no external or internal maintainers; the process includes all maintainers from any organization; for example, I got removed from here;
• the process fully respects the governance; please double-check the Project inactivity section.

[leodido]

Hey @leodido

I've tried my best to make it short 👇

1. We are proposing to remove **inactive** maintainers on a per repo basis;

2. We are discussing their involvement publicly (so including them) via issues and PRs;

3. Removing **inactive** maintainers neither helps nor hinders vendor independence.

How the fact that I will not be able anymore to review and/or approve a pull request does not hinder vendor independence?

How the fact that only maintainers from a single company will keep being maintainers does not hinder vendor independence?

N.B.

* there are no external or internal maintainers; the process includes all maintainers from any organization; for example, I got removed from [here](https://github.com/falcosecurity/falcosidekick-ui/pull/56/files);

Indeed there are. In the sense of afferent to the company with the majority of the maintainers or not. Let's not play games.

* the process fully respects the governance; please double-check the [Project inactivity](https://github.com/falcosecurity/.github/blob/master/GOVERNANCE.md#project-inactivity) section.

I believe you should double-check that again, tbh.

Quoting from the GOVERNANCE:

they will be contacted to ask whether they want to continue being a maintainer

The message you sent on a shared Slack channel (which I saw only today because I have a backlog of hundreds of them) doesn't mean you directly contacted me (it didn't either contain a tag to ping me) to discuss my involvement. That message didn't contain a list of candidates for removal, either. It got 0 replies. I got 0 pings from you or other maintainers ensuring I was aware of that message and process.

Even starting the process of removal itself is NOT something that's up to only you to decide.

You should have followed the GOVERNANCE and contacted me to ask whether I wanted to continue being a maintainer or not (as per GOVERNANCE).

[leogr]

How the fact that I will not be able anymore to review and/or approve a pull request does not hinder vendor independence?

How the fact that only maintainers from a single company will keep being maintainers does not hinder vendor independence?

Maintainers inactive (like you in most projects) for more than six months are irrelevant since they are not approving PRs nor performing any maintainers duties. So you are not helping with vendor independence.

Active maintainers from the diverse company will remain (including you on the projects you're a bit active), and we are working hard to onboard new and active maintainers from various organizations (that's the real way to address the issue, IMO).

As I explained in falcosecurity/evolution#157, we opened those PRs to open the discussions; indeed, most of the PRs are not yet merged. Active maintainers of each repo have to decide, as per our governance 👇

In case the maintainer on the other hand wants to continue with the role but can't perform maintainer duties, other maintainers will open a vote to discuss the removal by following the next section process.

If you want to continue maintaining those projects, please go on each relevant PR and explain that you will continue to perform your duties, then I guess nobody will remove you from the approvers. I would be delighted to continue working for you.

You should have followed the GOVERNANCE and contacted me to ask whether I wanted to continue being a maintainer or not (as per GOVERNANCE).

Honestly, I found this unfair. You are pretending the process has been concluded yet, but it is not. I agree that there could be a better way to indicate these GitHub issues/PRs are discussions, not decisions. However, we are all acting friendly and discussing publicly, and most of the active maintainers are waiting to hear everyone's opinion before updating the OWNERS files.

For the projects that concern me, I will contact the interested parties directly in the removal PRs, before eventually proceeding to a vote. And I'd like to keep as many maintainers as possible, including you (that have always served the Falco project diligently).

[leodido]

So you are not helping with vendor independence.

I could have helped with vendor independence since I am an independent maintainer, instead.
Now I will not be able to eventually approve or reject a PR, because of your unilateral decision.

Active maintainers from the diverse company will remain (including you on the projects you're a bit active),

I guess that with the sentence "a bit" you mean maintaining and releasing driverkit alone for a whole year in my spare time, right?

and we are working hard to onboard new and active maintainers from various organizations (that's the real way to address the issue, IMO).

Like the new driverkit maintainer that I onboarded less than 1 month ago?
That's hard work too and it involved a few calls, a ton of conversations and time, etc.

Now I will be unable to do that for all the other Falco projects, because of your unilateral decision.

Just FYI, recently, I was working with people (ofc cannot name names now, but I can 100% prove it to you) to let them become contributors and (very likely) maintainers of the Falco projects.
I have to stop this onboarding process now, sadly.
I'd say that yes it's the real way to address the issue, right? 🎯

As I explained in #2115 (comment), we opened those PRs to open the discussions; indeed, most of the PRs are not yet merged. Active maintainers of each repo have to decide, as per our governance 👇

One last time.
The decision to start such a process should not be only your call or only the call of a subgroup of maintainers.
You could have scheduled a "Falco Maintainers Circle" call, as I did for the last CVEs. Or find other direct means of contact.
And all the maintainers together would have discussed whether to start this process or not, inform us you all wanted to reapply for graduation (like I did 1+ year ago informing everyone, also external maintainers), whether this process was needed or not for graduation, how to revamp involvements, keep track of each other, even judge each other...

Instead, you didn't contact me (or other ex-maintainers) about the decision of starting this process but you did contact me over Slack about 1 month ago when you wanted to become a driverkit maintainer. Funny, isn't it?

In case the maintainer on the other hand wants to continue with the role but can't perform maintainer duties, other maintainers will open a vote to discuss the removal by following the next section process.

Don't bother.

If you want to continue maintaining those projects, please go on each relevant PR and explain that you will continue to perform your duties, then I guess nobody will remove you from the approvers. I would be delighted to continue working for you.

I would love to to be honest. Because of how much I love this project. I'm sure you know it's way more than "a bit".
But I cannot anymore. It's obvious now it is not a time problem, it is an alignment and vision one.

Honestly, I found this unfair. You are pretending the process has been concluded yet, but it is not. I agree that there could be a better way to indicate these GitHub issues/PRs are discussions, not decisions.
However, we are all acting friendly and discussing publicly, and most of the active maintainers are waiting to hear everyone's opinion before updating the OWNERS files.

This process was presented as a point needed for graduation (see this issue). Out of the blue, more than 20 pull requests were opened without previous discussion between all of us the maintainers.

Doesn't feel friendly, and to be honest neither totally correct.

For the projects that concern me, I will contact the interested parties directly in the removal PRs, before eventually proceeding to a vote. And I'd like to keep as many maintainers as possible, including you (that have always served the Falco project diligently).

Don't bother, I'll spare you a vote.

We have an irreconcilable conflict about how an OSS project and OSS maintainership should be carried on.
For this reason, and for staying true to myself, I have to step down.

Feel free to put me as emeritus.

[leogr]

Hey @leodido,

Frankly, I don't like the tone of this conversation: it just seems more of a personal attack. I apologize if I have hurt you in any way. Actually, I'd love to discuss our differences of opinion in a friendly way, but I don't think flooding with comments on this GH issue is a good idea. So, I'm going to share my thoughts once again and then stop insisting.

First, in no way someone who is inactive can help the project.

Second, this is no (unilateral) decision:

1. We discussed this during community calls
2. I sent a private message on the maintainers circle slack channel
3. All the PRs that have been opened are meant to be the actual place for the discussion to happen.
4. Reviewing maintainers' activity is part of our governance and is a per-repo process. The fact that you'll be moved to emeritus status for the repos you have been inactive on won't prevent you from continuing helping on the ones on which you actually kept being active.

Third, I'm afraid I have to disagree with you on how to contact maintainers.

I truly believe that public discussions are the best way to be transparent with the community. There're no security issues or other topics that must remain private. Moreover, the governance doesn't say how to do that. Thus, I don't think we did something unfair or not correct. I believe we can disagree and still respect each other point of view, can't we?

That being said, I still want to thank you for all the work you did for Falco, and I will respect your decision.

[leodido]

we opened those PRs to open the discussions

Not clear to me if the process is ongoing and open to discussions,

I don't think flooding with comments on this GH issue is a good idea

or not.

[fntlnz]

@leogr

We discussed this during community calls

Community calls are not the place to decide about maintainership status.

I sent a private message on the maintainers circle slack channel
In a channel where nor Leo or I ever answered or read even when we were the most active maintainers

All the PRs that have been opened are meant to be the actual place for the discussion to happen.

PRs are PRs, Github has issues and discussions for discussing things.

Reviewing maintainers' activity is part of our governance and is a per-repo process. The fact that you'll be moved to emeritus status for the repos you have been inactive on won't prevent you from continuing helping on the ones on which you actually kept being active.

I stepped down myself, thanks for quickly reminding me

I don't think flooding with comments on this GH issue is a good idea

Being a maintainer also means hearing voices of other people and making sure they are heard - I would've preferred to not to read a sentence like that from you @leogr - you are essentially asking Leo to mute himself.

[krisnova]

Ciao.

@fntlnz, @leodido, @nestorsalceda, and @leogr.

I admire all of you equally. In my opinion you all have been strong and extremely effective supporters and leaders of the Falco project. We have all come to the Falco project in the same way (working at Sysdig) and have all had our own equally important journeys with the project.

I have a suggestion I would like to propose in the hopes of coming up with a positive and productive path forward for everyone.

1. We spend time together as a group in the coming weeks on a Zoom call to calmly talk through some of these concerns as a group of Falco emeritus leaders/maintainers.

2. We identify a new category of leadership for the project that myself, @leodido, @fntlnz, @nestorsalceda, @mstemm, and potentially others can move in to (as needed) that serves a deeply influential steering committee/leadership role of the project.

The Zoom conversation would be intended to help us move forward and address any miscommunication. The new position would be intended to find a happy home for the maintainers impacted by this situation.

Emeritus Leadership / Steering

This is a difficult situation to manage as we would like to BOTH keep traditional Falco leaders as productive, supportive, and influential leaders of the project while also adhering to the the needs @leogr has identified as well.

The new status could be called (this is open for discussion)

 Emeritus Leadership

or

Emeritus Steering

That would effectively serve as a long-term super-maintainer that has the ability to oversee and influence direction of the project without the responsibility of managing day-to-day tasks such as code review and issue triaging in specific repositories. This position would also be responsible for finding healthy and positive outcomes to situations specifically like the one we are in today. 😅

The new position would have limited responsibility in the code base, however would be given access to the same spaces traditional maintainers have found success with in the past. (Slack, Security response, Mailing list, CNCF events, etc)

I believe such a space would be helpful in ensuring the vendor neutrality of Falco moving forward, while also continuing to remember, support, and take full of advantage of the positions of influence seen from @fntlnz and @leodido and @nestorsalceda in the past.

I believe this to be a positive outcome for everyone.

We are on the same team

What I would like to see is for everyone to remember we are on the same team. I am on the same team as @leodido and @fntlnz as well as the same team as @leogr and other Falco leaders.

We all want the same outcome, and to feel that we can bring the best version of ourselves to Falco while keeping Falco as vendor neutral as possible. Ideally we would all be able to give hugs at the next Kubecon.

If a Zoom call in the coming weeks sounds agreeable please identify yourself in #2132 or sending me a message somehow. I can invite everyone and help mediate the discussion and find a time that works.

Additionally if this seems like a viable path forward I believe we will need a proposal drafted for the new Emeritus Leadership or Emeritus Steering position and to update the code base accordingly. I would need help drafting the proposal (if we chose to pursue this path). I would also need help identifying a set of responsibility that does not keep one position more or less effective than the other. We must remain neutral and diplomatic.

Please remember we are on the same team, and that there is a way forward that ensures we can all see each other and celebrate Falco together soon. ❤️

---

I am closing and locking this issue. We can take these sub-issues offline. We can discuss these consequences of the CNCFs graduation criteria in another thread, ideally with the CNCF ToC itself.