Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Proposal] Tech Lead Lifecycle Revision #1342

Closed
eddie-knight opened this issue Aug 5, 2024 · 14 comments
Closed

[Proposal] Tech Lead Lifecycle Revision #1342

eddie-knight opened this issue Aug 5, 2024 · 14 comments
Labels
proposal common precursor to project, for discussion & scoping triage-required Requires triage

Comments

@eddie-knight
Copy link
Collaborator

eddie-knight commented Aug 5, 2024

After parsing a lot of community feedback recently, the Chairs and TOC Liaisons have floated the idea of opening up the tech lead role to more community members on an annual term basis.

ref: cncf/toc#1283

Please comment with your insight or support for this proposal.

While implementation details are still wide open for feedback, the following general proposal has distilled:

  • Tech Leads will still be a position with no recurring term limits
  • Tech Lead role and responsibility will be unchanged
  • A maximum number of Tech Lead seats will be available per region: APAC, EMEA, Americas (Number TBD)
  • Two elections will be held annually to fill half of the seats each time. (Qualified voters TBD)
  • Any active community member may self-nominate
  • Elected Tech Leads will hold their role for two years before the seat is available for reelection
@eddie-knight eddie-knight added proposal common precursor to project, for discussion & scoping triage-required Requires triage labels Aug 5, 2024
@JustinCappos
Copy link
Collaborator

I'm not a fan of this for a few reasons.

In my view, the tech lead role has been a way to give someone who is doing a lot of work for the community a way to act more like a maintainer would be for a traditional open source project. I don't think this proposal would make sense as a way to delegate out maintainer roles. It should really be based upon contributions and not set to an artificial number.

Second, I think that election by the TOC isn't great because, with a few exceptions, they aren't usually that involved with the TAG to really understand the people they are voting on. This seems like it could increase the likelihood of broader industry politics playing a larger role in this process (which we have worked hard to avoid).

I'd suggest we all have a conversation internally to discuss if there are any problems that should be addressed that are leading to this request. If so, I would propose we try to address them in another manner, if possible.

@eddie-knight
Copy link
Collaborator Author

Of course @JustinCappos- this is definitely the sort of big thing that benefits from multiple discussions!

@linsun
Copy link

linsun commented Aug 6, 2024

After parsing a lot of community feedback recently, the Chairs and TOC Liaisons have floated the idea of opening up the tech lead role to more community members on an annual term basis.

Please comment with your insight or support for this proposal.

While implementation details are still wide open for feedback, the following general proposal has distilled:

* Tech Leads will still be a position with no recurring term limits

* Tech Lead role and responsibility will be unchanged

* A maximum number of Tech Lead seats will be available per region: APAC, EMEA, Americas (Number TBD)

Per region could be a stretch to fill in the roles imho.

* Two elections will be held annually to fill half of the seats each time, with the TOC acting as qualified voters

We would love existing TAG leaders and active members to vote, while TOC has final approvals. I agree with @JustinCappos that TOC members are generally not involved with day to day TAG activities so it is best to have TAG leaders and active members to vote.

* Elected Tech Leads will hold their role for one year before the seat is available for reelection

Maybe 2 years so we don't have a lot of elections going on?

@eddie-knight
Copy link
Collaborator Author

  • Changed one year to two years
  • Changed with the TOC acting as qualified voters to Qualified voters TBD

🤔 Though it's open to debate, I still like the idea of a maximum number of seats per region

@dzolotusky
Copy link

In general, I support the direction that this is going in, but think that it's important that the TAG members support this. I'm sensitive to @JustinCappos's concerns and want to ensure that people like him are on board with whatever we end up doing here. So, please speak up or have the internal conversation that Justin suggested and update the rest of us here.

I'm glad that we removed the TOC being the voters, but I'm not sure that a tech lead is as easily mapped to a maintainer-like role in a project. Though, even if it is, I feel like having some sensible cap on number of maintainers is necessary. Do any of you have a proposal on what that cap would be? I think that TAG Security has 6, and every other TAG has 3 or fewer. I'm guessing that the specific numbers that people have in mind may be the bigger problem than the concept of a cap.

I also believe that having a process for ensuring that the maintainers are still active, trusted leaders in the community without having to create an awkward removal process is a good thing. I like the idea of the elections, since Tech Lead is an open source leadership role, but know that I'm a TOC member and am not involved with the TAG.

@anvega
Copy link
Contributor

anvega commented Aug 6, 2024

After careful consideration and discussion with other long standing members of the TAG, I have several concerns about the proposed changes to the TL role. I believe this proposal may be premature and could potentially undermine the effective functioning of our group.

It's surprising to see this proposal, as it seems to contradict the direction we discussed in our recent internal leadership meeting. This disconnect suggests that there may be a gap in communication or understanding between different stakeholders in our community.

The TL role has historically been an earned distinction, awarded to those who have demonstrated consistent, high-impact contributions to the community. These contributions have typically been measured by outcomes rather than outputs. It's important to note that all current TLs have rightfully earned their positions through their dedicated efforts and valuable insights. While activity levels may fluctuate due to personal and professional commitments, this doesn't diminish the value of their expertise and past contributions. Given the broad scope of security, different Tech Leads naturally gravitate towards various areas of interest, leveraging their unique strengths. This diversity of focus and expertise is a strength of our current structure, allowing us to address a wide range of security concerns effectively.

Rather than implementing a rigid election system, we had discussed last Friday creating a more structured mentorship program and ladder to nurture future leaders. This approach would allow promising contributors to gain experience and understanding of the TAG's operations before taking on leadership roles.

We also discussed creating an "Advisory Fellow" distinction to recognize significant contributors who may not be able to engage in day-to-day TAG activities due to other responsibilities.

The proposed election system raises several concerns:

  1. It may not accurately reflect the meritocratic nature of how we operate.
  2. It could potentially introduce unnecessary politics into what should be a collaborative, expertise-driven process.
  3. The regional quotas may not align with the global nature of our work and the uneven distribution of expertise.
  4. Regular elections might create instability and disrupt ongoing projects and initiatives.

Instead of restructuring the Tech Lead role, we might better serve the community by addressing current challenges:

  1. Improving the onboarding and mentoring process for new contributors.
  2. Enhancing communication between Tech Leads, Chairs, and the broader community.
  3. Developing clearer pathways for recognition and advancement within the TAG.
  4. Addressing any bottlenecks in decision-making or project progression.

While I appreciate the intent to increase community involvement, I believe this proposal may not be the most effective way to achieve that goal. Instead, I suggest we focus on enhancing communication between new chairs and technical leads, improving mentorship opportunities, and addressing any perceived issues that have led to this proposal.

I recommend we have a broader discussion involving current Tech Leads, active contributors, and other stakeholders to identify the causes of any perceived issues and collaboratively develop solutions. It's important to recognize that our TAG is already highly functioning and deeply immersed in the ecosystem. We consistently deliver valuable contributions through numerous reviews, assessments, publications, and events. By the numbers, likely more than any other TAG.

Echoing the sentiment of our leadership meeting last Friday, as we consider ways to evolve, let's ensure we build upon these strengths and continue to enhance the TAG's impact and effectiveness rather than potentially diminishing it by introducing unnecessary policy, process, and bureaucracy.

@eddie-knight
Copy link
Collaborator Author

I wasn't present for the discussion you're referencing from Friday's call, so I'll respond to your suggested alternatives here.

But first, I'd like to note that we have not clearly articulated what value, if any, is added by persisting in the current lifetime position model.

  1. Properly implemented elections will precisely address the "meritocratic" intent of the Tech Lead role, and do so in a far superior manner when compared to a lifetime position.
  2. We have lots of "politics" already, and it's frequently very unproductive, resulting in both leaders and contributors withdrawing or pausing their participation. If there are any "politics" added by an election, it will likely be far more productive than the current model because it creates an incentive for Tech Leads to consistently contribute and work well with others if they wish to continue in the role.
  3. The regional quotas are an implementation detail.
  4. As noted in a comment above, we currently have twice as many TLs as any other TAG. Many discussions with regards to adding new Tech Leads end up circling around to "Don't we have too many already?"
  5. Tech Leads and Project Lead roles are clearly demarcated, giving a built-in resilience to project disruption.
  6. Creating new advisory roles is not excluded by this proposal, but also would not address the key value sets that this seeks to provide— creating an avenue for new leaders to hold well-defined leadership roles to support the community and, hopefully, elevate their careers.

@anvega
Copy link
Contributor

anvega commented Aug 7, 2024

I appreciate the intent to improve process, but I think we should have a group discussion first. It would be the same if TLs were trying to make stipulations for chairs without hearing and discussing their views. We have plenty of space for those discussions as a group and also availability to do rounds one-on-one.

A key topic raised last Friday was governance changes being sought unilaterally without group discussion, and chairpersons with a tendency of imposing their will rather than ensuring everyone's views are heard, discussed, and clear decisions reached and accepted.

So let’s work on what the proposal seeks to accomplish and what is the improvement we’re after. Few of those last points raised were captured in the original proposal. This is a good example of why it's worth discussing to crystallize the real underlying "why" behind it.

For what it's worth, I'm not reluctant to change. I’m actually a strong proponent of organizational change and I've advocated the position for years that we need a wider set of TLs for more diverse perspectives and balanced leadership team. I've suggested half a dozen of nominees from many different geographies and backgrounds that chairs at the time didn’t select. Instead of imposing regional maximums, we should aim for minimum representation across regions, and where feasible, even at the national level in countries not currently represented but that have active participation like France, Germany, Israel, Japan, and Brazil, and others. Our higher number of tech leads reflects the scope of our work, not inefficiency. There is plenty to do that more willing people with demonstrated capability can pitch in on.

I don't consider the roles lifetime. We have folks on leave, and in the past, we've accommodated extended leaves. Even though it hasn’t been the primary reason, it’s coincidentally been those periods that have chosen to grow the number of TLs, understanding that no one's life is balanced year-round and commitments fluctuate.

I don't concur elections would better serve to recognize merit. Merit in our context is about consistent, high-impact contributions over time, not popularity or short-term visibility. We have numerous pathways for involvement like shadowing assessments, being a reviewer, leading projects, and organizing and volunteering at community events. We could risk people having knowledge gaps in the operations of the TAG or worse, lacking domain expertise or ethos and practice of open source, which would result in unsound advice to projects going through assessments and reviewing contributions.

We used to have a static member list for a long time. The only requirement to become an active TAG Security member was to have attended two meetings and filed a PR with their name. We moved away from this because folks were using it to claim they were part of the group for their own career advancement and personal gain, without pitching in or making meaningful contributions after having attended just a few meetings.

It's a novelty that we have non-tech leads leading projects, but there's no project not led by at least one tech lead, so that’s something we should seek to open up further, but it’s hard to find committed newcomers for long term projects.

I think we're all open to improvement, but proposals should be grounded in shared context and collective interest.

@anvega
Copy link
Contributor

anvega commented Aug 7, 2024

While it's not my place to dictate anyone's actions, I'd like to share some additional points from the group's recent discussion. It was pointed out that being a TL largely involves voicing one's viewpoint, while effective chairpersonship, by comparison, is about bringing people together and facilitating what the group wants to achieve.

You know, one of the things I've always appreciated about our group is how we've managed to be both opinionated and collaborative. We've had our fair share of lively debates and haven't shied away from disagreements, but at the end of the day, we've always found a way to come together, commit to collective decisions, and move forward as a team. It's my sincere hope that we continue to tackle growing pains and new challenges in the same spirit.

In addition to the spaces mentioned in the last post, I see another TL has taken the lead to move the conversation to Slack to try to determine what it is we're trying to solve here. That is another great space to foster discussion and work publicly within the group on proposals.

@mlieberman85
Copy link
Collaborator

I think we can do this in a lighter way. I do think it would be useful to have some of this written down, and if the TOC is looking to make sure we all have a process around this I think something like:

TAG Security nominates, manages, and removes tech leads at its discretion based on consensus. Escalations are available to the TOC and any code of conduct violations still go through their appropriate path.

@lumjjb
Copy link
Contributor

lumjjb commented Aug 16, 2024

I'd like to share a doc which I worked on with previous chairs which may be useful in guiding the discussion. It will likely not be representative of what we do today, but it was useful for us to think about to decide to scale back and combine efforts where we felt there was a lot of overhead with various working groups.

https://docs.google.com/document/d/14r9e5u7r9PzVaGPyo24cTkQ_e5Br7Xuds1GDHl2rTe4/edit

@anvega
Copy link
Contributor

anvega commented Aug 19, 2024

My parting thoughts is this proposal is short-sighted. The throughput of this group directly depends on the number of TLs who have both the agency and commitment to carry out the work. Those with a proven high say:ratio typically shoulder the workload, while others may contribute to projects but lack the dedication to drive them from conception to delivery.

TAG Security sees many ideas (I've closed out hundreds of stale issues), but without ownership, these ideas are meaningless. TLs take ownership because they are committed to execution. Voting in individuals who haven’t demonstrated this track record risks a lack of execution. Introducing terms for TLs only adds unnecessary bureaucracy, distracting them from making, moving, fixing, maintaining things and forcing them to focus on re-election if they care enough about the tasks at hand to continue to go.

I was told this proposal stems from the TOC questioning the number of TLs in TAG Security. But does the number really matter? Should TAG Security mirror other TAGs? CNCF's open governance allows projects to create their structures; imposing uniformity across the board contradicts this.

A proposal like this one is useless if it alienates TLs or causes disengagement. Chairs connect with the TOC, but TLs execute the work. If a chair loses effective interaction with TLs, the group suffers. The chair’s role is to facilitate and manage overhead so TLs can be effective, not to create comfort or insulation. Traditionally, chairs have been former TLs with a deep affinity for the group’s ethos and practices. Proposing changes without taking the time to understand the current structure is a tourist move.

A lot of what’s happening here exemplifies “On the Phenomenon of Bullshit Jobs,” “The Dictator's Handbook: Why Bad Behavior is Almost Always Good Politics” and “Barbarians to Bureaucrats,” but in an open source context.

Everyone in leadership here incurs significant personal costs to contribute. No one is paid. Startups and academics sacrifice valuable work to share insights here. Imposing administrative conditions on their participation is unnapreciative. Telling @mlieberman85, @ashutosh-narkar, or @jkjell that their time is up arbitrarily, or asking Justin and Marina to prove their commitment despite years of selflessly making themselves available, is not just poor form. If someone wanted to consolidate power and authority over this group, they couldn’t have done it better. Real productive altruistic people are being sidelined.

Escalations are available to the TOC and any code of conduct violations still go through their appropriate path

While I appreciate the thought from @mlieberman85, I'm not sure how the code of conduct relates to this, as someone who helped shape it during the previous interim CoC committee. Like in any organization, enforcement is typically reserved for situations that pose reputational or legal risks to the foundation.

@mlieberman85
Copy link
Collaborator

I agree with most of Andres' points here, but I also want to stress that at least I think everyone here is operating largely in good faith. If the TOC is concerned about our current governance structure I think it would be nice to hear that from them and what the actual concerns are.

The CoC addendum was more of just an example of how in my opinion the CNCF already has governance dealing with escalations outside of our group. I just mean we can keep it simple and defer to TOC or CoC where needed.

@eddie-knight
Copy link
Collaborator Author

Thanks for the feedback everyone. I'm gonna close this as it's gathered all the input I expect it's going to get for now. We can reference it later as needed.

@eddie-knight eddie-knight closed this as not planned Won't fix, can't repro, duplicate, stale Aug 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal common precursor to project, for discussion & scoping triage-required Requires triage
Projects
None yet
Development

No branches or pull requests

7 participants