Establish new Emeritus Leadership/Steering role

[krisnova]

I would like to open up a discussion to update our governance to capture the importance and responsibility of emeritus leadership within Falco.

I would like to codify our governance to call out a new leadership role for the project. The original suggestion in #2106

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...

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)

Ultimately we will need to call out the responsibility of this new position, and specifically how it is unique from a traditional approver.

My suggestion is that we label this position one of the following:

• emeritus_leadership
• emeritus_steering

and that the new role is highly influential over the project. The new position should be opportunity to maintain reasonable access to mailing list, CNCF events, security discussions, and conflict management within the project.

This will be a leadership position that will require prior approvers to work through the current approvers. The only path to this new role is by being a previous approver.

Completion of this Issue

Upon completion of this issue we should complete 2 independent actions.

1. We update the GOVERNANCE.md file to define the relationship between this new role and the existing approvers. Specifically how approvers move into and out of this position. It might make sense to leverage our automation here to automatically move people into the new position after some length of inactivity.

2. We update the /OWNERS file in our various repositories to move people into the new role as needed. Or perhaps let automation manage this for us. In which case we need to set up the automation.

Open Questions

• Are there any volunteers to draft the changes to the governance?
• Are there any existing approvers who are interested in self identifying to become one of the founding members of this new position?
• What responsibilities will this new position be accountable for?
• What responsibilities will no longer be part of the new position?
• How does someone move into and out of this new position?

[maxgio92]

Hi @kris-nova, I like this idea as I think the project would benefit from it.

As contributing to keep the community healthy and the project grow needs to know well both the community and the project IMHO, it's important that only maintainers are able transition to this steering role.

At the same time to accomplish this goal I think isn't needed to keep the development-related duty of a maintainer.

I'd like to contribute to the draft if you think the help of a non-maintainer can help.

[krisnova]

@maxgio92 please feel free to start a document if you would like. We can all collaborate on it concurrently.

Perhaps share the link privately with folks who identify themselves here so we do not get spammed? I would like the link. You can message me on Kubernetes slack.

[leogr]

Hey @kris-nova

I think you raised an interesting topic. I see the importance of giving the proper significance to all people that have been involved in the project. I agree that emeritus maintainers have much to offer, and should be recognized for past contribution, even if they are not performing maintainers' duties anymore.

As a project, we need to improve our governance to include structures to respect a broad variety of non-code contributions, and hear the voice of major end-users. And our structures must be fair to both past and current contributors.

We're not the first project to reach a point like this, so I propose that we look at models from similar projects in the CNCF, and seek advice from CNCF's TAG Contributor Strategy to understand what structures can work for the long-term health of Falco and its community. We can then bring a proposal to a vote among the maintainers.

PS Would we move these discussions to falcosecurity/evolution? Since it's the repo aimed to document the evolution process of The Falco Project, I think it would be more appropriate.