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

Address shortage of Project Mentors #207

Open
dcmiddle opened this issue Dec 1, 2023 · 3 comments
Open

Address shortage of Project Mentors #207

dcmiddle opened this issue Dec 1, 2023 · 3 comments

Comments

@dcmiddle
Copy link
Collaborator

dcmiddle commented Dec 1, 2023

As we scale projects beyond the number of TAC Voting Members how do we continue to provide mentors to the projects?

https://github.com/confidential-computing/governance/blob/main/project-mentors.md

Proposal 1:

Request volunteers from the TAC community.
If there are no volunteers then a TAC Voting Member is assigned.
Assignments work in round robin alphabetic order by name of company.

Proposal 2:

Remove Project Mentor role.

Proposal 3:

Subject Matter Specific Mentors
Each Voting TAC Member lists a topic on which they can answer questions for project maintainers.

Example:

TAC Member Subject Matter
Alice Licensing
Bob Annual Review Prep
Eve Inclusive Best Practices

(Thanks to @lkatalin for her insights arising from the cross-project initiatives.)

@AlecFernandez
Copy link
Collaborator

I like the idea of an SME and I endorse this idea. However, it seems like the projects might get lost in being handed off from one SME to another if the projects have multiple subject areas. I think that a top level mentor is still needed. (That said, I'm pretty new to open source project mentorship so this may not be very insightful). Since OE is a project where the majority of the contributors are my peers, my view is a bit biased. I'll continue to work with OE and accumulate experience.

Another thought is that if you made the "round robin" idea have "term limits", that might be easier. Have the term extend to one review cycle. After that, the mentor can opt to stay on or "pass the baton" to the next member in the queue.

@yashkmankad
Copy link
Member

We don't have enough active TAC members to assign 1x project / TAC member now that we have 10+ projects.
So I am not in favor on Proposal 1.

I do see value in having the role, so I am not in favor of Proposal 2 either.

I agree with Chris Ramming that as we continue to grow our list of projects, Proposal 3 would be the way to go.

A change to the proposal could be take the round-robin assignment approach from Proposal 1 and apply it to assigning SMEs for Proposal 3 to avoid multiple members listing one topic and having no members for other topics.

@lkatalin
Copy link
Contributor

It's a good point about projects not getting lost in hand-offs. Perhaps one of the SME roles could be "project point of contact" or something like this, so that projects still have a go-to person (round robin style / term-based as proposed above) but it doesn't need to be a different point of contact per-project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants