TSC Structure and composition

[mbolivar-nordic]

This issue covers an open discussion around the structure of the TSC.

The purpose of the discussion is to align on goals within the WG and determine if we want to make recommendations for changes at the next TSC F2F.

[mbolivar-nordic]

@nashif to present alternatives from other projects to drive discussion.

[mbolivar-nordic]

@nashif : I was looking into different projects, e.g. ROS (robot operating system) and hyperledger. I would like to take ideas for processes from existing projects like these.

Brainstorming session followed; no conclusions were reached.

[mbolivar-nordic]

• @mbolivar-nordic I think we're still brainstorming -- unless there are concrete ideas, would like to postpone due to lack of time
• @nashif I would like to hear people's thoughts on this

Request:

• If you have thoughts on this, please write them here on GitHub or let @nashif know what they are privately

[keith-zephyr]

My thoughts:

• Short term we could consider reducing the TSC members for platinum members from 2 to 1. Then move these seats to the general community to be voted on.
• For community seats, I see value in allowing companies to nominate the company itself for a seat. Once approved for a seat, the individual company would select the specific individual to actually participate on the TSC. This allows for some continuity for companies that are actively contributing to Zephyr, in the event that a specific individual leaves, or just changes roles.

[henrikbrixandersen]

My thoughts:

• Short term we could consider reducing the TSC members for platinum members from 2 to 1. Then move these seats to the general community to be voted on.

• For community seats, I see value in allowing companies to nominate the company itself for a seat. Once approved for a seat, the individual company would select the specific individual to actually participate on the TSC. This allows for some continuity for companies that are actively contributing to Zephyr, in the event that a specific individual leaves, or just changes roles.

This sounds like a good starting point. I'd like to reach a situation, where the TSC is mainly composed of technical contributors to Zephyr as opposed to e.g. people with management roles from member companies. Not that I have anything against these, but I strongly feel the Technical Steering Committee should be more technical than political.

[mbolivar-nordic]

Process WG: roundtable discussion and feedback

AI:

@nashif to provide a proposal with options based on feedback in 2 weeks time

[mbolivar-nordic]

Process WG:

• @nashif next week I will be out, so defer to August 24

[mbolivar-nordic]

Process WG:

• Defer to next week

[nashif]

@mbolivar-nordic can we put this back on the agenda tomorrow?

[asmk-ot]

My thoughts:

• Short term we could consider reducing the TSC members for platinum members from 2 to 1. Then move these seats to the general community to be voted on.
• For community seats, I see value in allowing companies to nominate the company itself for a seat. Once approved for a seat, the individual company would select the specific individual to actually participate on the TSC. This allows for some continuity for companies that are actively contributing to Zephyr, in the event that a specific individual leaves, or just changes roles.

This sounds like a good starting point. I'd like to reach a situation, where the TSC is mainly composed of technical contributors to Zephyr as opposed to e.g. people with management roles from member companies. Not that I have anything against these, but I strongly feel the Technical Steering Committee should be more technical than political.

Having technical managers part of the TSC makes a lot of sense for organizations offering many resources to the project. Secondly we should not dismiss the soundness of having a diverse skill set as part of the TSC.

[mbolivar-nordic]

Process WG:

• Continue discussion in google doc to try to align on goals for this effort
• Google doc link: https://docs.google.com/document/d/1TkAwx31YP43DDx_oK8sWDnjKh9LEzNY0qVZ8QnbNzSQ/edit#
• Purpose of this issue is to try to have a recommendation for any changes we might want to the TSC structure in time for the next F2F

---

• @nashif presented a Google doc ("TSC Structure") discussing problem statement and various options
• @asmk-ot I want to discuss the problem statement about pay-to-play. I think the TSC is based on merits. I don't think people are voting based on politics. I think we need to keep a price on the platinum membership because we are using the money for good purpose.
• @mbolivar-nordic governing board seats to set the budget would not change regardless of what we do. I think things have worked out well in the existing binary blob discussion, but I do remain concerned about technical decisions being made by representatives that may not be making decisions based on the best technical interests of the project.
• @nashif I agree we need to fund the project. We run into situations where people think they cannot influence the project because they aren't TSC members even though they are technical contributors. We also have people joining and not voting. So I think we at least want to increase community representation -- any disagreement?
• @asmk-ot I can say my and my company's general intent is to make sure the project thrives and survives, because we're using it. I think there are probably a lot of other companies like this. Is a high community membership a good thing for Zephyr? I think so
• @henrikbrixandersen in order to "protect your investment", so to speak, do you really think the TSC is the best place, and not the board?
• @asmk-ot Both are important. Hearing aids are a very specific design area due to the physical size of hearing aids being decided by the size of the chips, and we design our own chips. We want to make sure the codebase continues to run on very tiny devices.
• @asmk-ot another discussion is whether the userbase of zephyr stalls because we're focused on certain user profiles; talking to my colleagues who are board members might not know about whether we should be supporting macOS, for example.
• @gregshue once zephyr starts capturing user needs and business requirements, I can see it being part of the TSC's scope to start capturing which ones are addressed. So there's an interest in getting community members' interests reflected. But probably a bigger value to capture the community's needs.
• @nashif you get to be a community representative by making things happen and getting voted into the TSC -- don't take it as the zephyr project is sitting there waiting for requirements to implement. E.g. @henrikbrixandersen adding and maintaining CAN support; we expect that to happen in every aspect of the project.
• @kartben one thing I'm not really clear about is who is in charge of zephyr as a product -- who is defining what zephyr should and should not be, beyond the technical solutions. E.g. related to footprints, is there someone setting requirements for future footprint growth? I don't think that's just a TSC discussion
• @nashif footprint is present in the 'user experience' pillar discussed at the governing board level; we care about footprint too. The board is the body that sets the direction of the project
• @galak as far as setting direction, I think that's a misnomer. It's an open source project; for the most part zephyr as a project doesn't have resources to say "go do this". If you have an interest, e.g. CAN, you can come and contribute it. If footprint is important, people will monitor and engage in that. If nobody does any work, nothing happens regardless of what the TSC and board say. I think the TSC's role is to address discussion when someone is going and doing something, but the question of what the TSC's role is is important
• @keith-zephyr in terms of setting direction, let's look at Benjamin's role. We got approval to fund that salary and I expect the TSC has a lot of say in what activities he does for us. This could be something that expands in the future if there's enough funding. This gets back to the original point of how we encourage contributors to become members so there's budget and funding behind zephyr
• @nashif to Kumar's point, the board obviously doesn't go into details, but the board does set the budget, which sets direction. E.g. funding Bluetooth qualification testing, since one pillar was deciding what to be competitive in. Networking: same thing. We could do the same for IDE support. Deciding what shows you go to also matters.
• @asmk-ot we all work for companies and have probably seen how a high level direction influences our own technical strategies. I agree with Kumar it's a different situation since we have people working for free or funded as developers by companies. It's a matter of rallying people around a common idea. It has to be driven by interest in open source projects. It's not a chain of command thing. Maybe we can rely on partnerships in some way. Once we get to a certain size, tool and IDE vendors will want to work with us
• @nashif returns to google doc to summarize goals. Especially last bullet point that every TSC member should have a role in the project.
• @asmk-ot I think we should think about what Kumar said -- much is driven by interest. E.g. in bluetooth, people want to contribute but move on. Mainly driven by 2-3 main contributors. I don't necessarily have a problem with that; I don't see how to resolve it in any other way
• @nashif that's true, and there are many areas in the project for people to work on
• @galak Anas, have you looked at vote history and categorized what the TSC has voted on? Are there patterns that fall out -- purely technical questions like int main vs void main, other things about process, etc.?
• @nashif I was looking at the vote tracker; we vote a lot for modules and blobs recently for example. This is actually another topic -- TSC voting granularity; refining our guidelines so we make the rules for changing TSC charter or previously voted upon issues require a supermajority, for example, so the TSC can deal with more important stuff.
• @galak might be good to review these and also other issues that were particularly close. Maybe worth giving TSC chair some power to avoid bringing up the same issue every week, which is currently possible
• @gregshue I want to go back to guidelines. Something unclear to me is whether compliance is necessary or encouraged.

[dleach02]

• @galak as far as setting direction, I think that's a misnomer. It's an open source project; for the most part zephyr as a project doesn't have resources to say "go do this". If you have an interest, e.g. CAN, you can come and contribute it. If footprint is important, people will monitor and engage in that. If nobody does any work, nothing happens regardless of what the TSC and board say. I think the TSC's role is to address discussion when someone is going and doing something, but the question of what the TSC's role is is important

This is an important point. I sometimes feel we put too much emphasis on the TSC when the reality is that we want to encourage growth and participation/contributions at the working group/committee level. As pointed out, what gets done in Zephyr is really based on the interests of those who want it done. The high-level guidance that may be set at the governing board helps identify where the funding may be applied but things still need resources to invest their time to get things done.

[henrikbrixandersen]

This is an important point. I sometimes feel we put too much emphasis on the TSC when the reality is that we want to encourage growth and participation/contributions at the working group/committee level. As pointed out, what gets done in Zephyr is really based on the interests of those who want it done. The high-level guidance that may be set at the governing board helps identify where the funding may be applied but things still need resources to invest their time to get things done.

Those are very good points, I think. More active contributors in the various, TSC delegated WGs would be a welcome addition.

[mbolivar-nordic]

Process WG:

• rough consensus seems to be developing on a hybrid model mentioned in the google doc (https://docs.google.com/document/d/1TkAwx31YP43DDx_oK8sWDnjKh9LEzNY0qVZ8QnbNzSQ/edit#heading=h.gc2pbkjrj0ue)
• detailed transition plan would be necessary
• well considered membership formulas that manage TSC size while preserving representation would be critical

---

• @nashif want to try to settle on goals
• @mbolivar-nordic these LGTM; I think implementing the "TSC member shall have a role in the project" one will be the most interesting
• @nashif what I see is people may want to contribute but don't find a role; we can use the TSC F2F to discuss something like this
• @keith-zephyr do you have anything specific to keep silver attractive? Not necessarily a direct benefit to a silver member if we have community membership
• @nashif good point. Back in the day, I proposed a change so Silver members get a TSC seat and Platinum get 2, instead of Silver 0 and Platinum 1. We didn't have silvers back then, and probably those that joined since then were attracted by voting. Something to think about. If you're an active silver member and we drive the community member, I think there shouldn't be a problem getting the votes to be a TSC member. Some people might drop their membership and nominate themselves to be a TSC member. Could also consider expanding limits as well.
• @galak one thought I had was doing something like what the board does. Could reserve some number of seats for the silver pool of members (e.g. 1 member for every 4 silver members; details TBD). Need to find a balance so people who aren't contributing directly can get a stake if they want to vote. But if I remember, the bar for silver membership is so low, I'm not sure what the selling point is besides being a good community member.
• @keith-zephyr I like that proposal of pooling silver members so there's something that entices them to pay since we do need money to keep infrastructure going. Another thing worth mentioning is zephyr summit discounts for members.
• @nashif pooling is interesting. Another consideration is listing the "assets" associated with project membership (also marketing, booth space at conferences like Embedded World, etc.)
• [summary of alternatives follows]
• @mbolivar-nordic one concern is that the hybrid model amounts to removing things silvers have paid for, so we need to line up with membership renewal timelines, make sure LF is on board, etc etc
• @nashif yes, any new solution would require a transition period, would have to go to the board, etc
• @gregshue tangential, but something worth noting. Legrand hasn't done this in part because it requires LF membership, which is a significant additional cost. If you're looking to raise funding, worth looking for ways to lower some of those thresholds. That's been prohibitive. End user businesses have very different sets of domains they participate in than chip vendors
• @mbolivar-nordic agree, and I think that's why it's important to increase community participation -- engineering payroll is money, and giving engineer time as a maintainer is a contribution worth rewarding
• @dleach02 can one of the options be a concerted effort to add community TSC members?
• @nashif something we can do, but also need to manage the TSC size concern. Something like the hybrid/pool seems like the way to go, especially in concert with what the optimal TSC size is. What is the right formula to keep TSC size under control but still representative?

[mbolivar-nordic]

Process WG:

• use of 'community' terminology should be revised to make it clear that paying members are also community members.
• proposal to change terminology to 'appointed' versus 'elected' TSC members
• some discussion around additional elected TSC members from member companies based on participation
• rough idea of about 30 TSC members being a goal, with sub-groups helping drive decisions without bringing things to the TSC
• additional proposal to name members of each WG which creates a quorum that must be reached to make decisions

---

• @nashif what is the optimal size of the TSC for a project like ours in terms of getting things done?
• @dleach02 really comes down to objectives. If getting more community representation in the TSC is the goal, what needs to be communicated is why that's a good thing vs current structure. If quorum is the issue, we could change the way we determine quorum. Where you run into problems is going to the governing board and changing Platinum benefits.
• @nashif this is a discussion item in the board already under the sustainability pillar. Need to come up with a plan as the TSC and present to the board
• @henrikbrixandersen I'm having a hard time listening to "community" vs "other group" -- I think we are all community. I think it's important in communication to come up with another term. As an open source project, even paying member company representatives are part of the community
• @henrikbrixandersen apart from this, while I'm all for increasing number of nominated members of TSC, I think we'll have a hard time nominating people. I had a hard time going through who I would nominate as TSC member right now because most of the technically active people are with a paying member company already or are working as consultants and submitting patches with emails from that paying member company. Think we need to be realistic about how many members we see ourselves nominating
• @nashif to first comment, this is just for lack of a better term. If we're looking at 'hybrid approach', contrast is 'member appointed' vs 'elected'. Members are also community. Not about having non-members join the TSC, but about having the TSC be more composed of people who are technically contributing. May end up with a TSC in this model composed of people in largely member companies, but based on participation in the project
• @galak following this comment, goes towards 2 things. one is TSC size as mentioned. the other is how many members from a given company is acceptable. we've said paying members get what they pay for, excluding people who may be good community members from the TSC. maybe want to look for a percentage base of individuals who do work directly or indirectly for somebody to be part of the TSC. may not want to limit the number of TSC members per member company if they have more community members who contribute significantly
• @keith-zephyr one thought is regarding the goals: one is about TSC structure, the others are about how to get more engagement out of TSC members. Is there value in splitting this apart? Maybe think about working group participation as an interim step while we're thinking about composition
• @nashif these points aren't about leading WG. More about first improving definitions of WGs to allow improving decision making in WGs. Don't think we need WGs to be led by a TSC member, but perhaps having a body of some size, ideally made of TSC members, which would help improve TSC participation. To @keith-zephyr 's point, I think that's something we can look at immediately improving
• @galak I wonder if formalizing what areas we want more representation in the TSC from, and stating that WG chairs should be TSC members. Take toolchain WG. Perhaps Torsten should be on the TSC as the voice of that WG.
• @mbolivar-nordic seems like "getting TSC members to participate in WG" is separate from "people knowing they can be part of any WG regardless of if they're TSC members" are separate problems in @keith-zephyr 's point
• @nashif yes, need to create something that is hybrid. I want to have a place for TSC members joining and making decisions at that level
• @dleach02 WGs always have an ability to make decisions, but if they are decisions that require TSC, you bring it up there. but generally speaking we empower WGs to move things along
• @nashif agreed, but it's random right now. To give weight to a WG, a body has to be established with permanent group members that can reach quorum and make decisions. Right now we don't have this: we can make recommendations in WGs, but they need to be ratified
• @dleach02 depends on the WG-- architecture WG drives direction of the project. But for Testing WG, not sure what decisions are that need to be solidified. Feels like we're conflating things
• @nashif not saying TSC members have to be WG members, but do want to specify project roles and rotations for them. Can't just be "I was there first, I'll be there for 10 years" to chair a WG. Want to facilitate new appointed TSC members taking roles in the project. These are the goals, need to figure out mechanics and logistics. Wouldn't necessarily look at details of this/that WG, but about creating platforms for moving things forward
• @dleach02 we see a lot of participation going on now. Curious about whether feel they can't participate
• @mbolivar-nordic I do observe this anecdotally
• @dleach02 could be a communication problem
• @henrikbrixandersen I think that leads back to us referring to "the community". I've spoken with Danish engineers using zephyr who don't participate because they're not members. I tell them they're as welcome to participate as anyone else.
• @keith-zephyr since we have @kartben , what about putting out quarterly newsletters laying out the WGs and their activities? I imagine there's quite a bit of churn
• @kartben I like the idea. To the point about terminology, I think there might be some implied gatekeeping in terms "working group", "steering committee", etc. Maybe naming is part of this. Hopefully people get submitting issues and PRs is open. Everything else feels more complicated
• @nashif going back to size: assuming 1 appointed TSC member per platinum, that gives 10 TSC members. Then safety and security gives 12. If we say we want to double the appointed numbers total, that would be 25-30. Is that workable? Then we have to vote 12 members in. For silver, we discussed pooling: how would that work? If every 5 silvers get a TSC member, how would that work?
• @galak I think it'd be no different than choosing the silver board representative. Every 10 silver members gets a board representative created. Silvers nominate people and they vote for those positions
• @nashif comes to around 30 members. That won't change the size dramatically in terms of active members

[mbolivar-nordic]

Process WG:

• consensus around using people in the MAINTAINERS file plus current TSC at the time of a vote on a new TSC member as the group of people who get to vote
• consensus on expanding the scope of the MAINTAINERS file to include other categories where we want people to have a vote (WG chairs, release managers, etc.)
• consensus on having the set of voters equal the set of people who can be nominated as elected TSC members
• revisiting "30 TSC members" proposal: replace this language with "size of TSC is 2x the number of appointed members", targeting 50% elected and 50% appointed

---

• @nashif would like to discuss regarding elected members: 1. who gets to nominate themselves? 2. who gets to vote in the election?
• @nashif for 1., I don't think it should be based on a commit count or subsystem maintenance. We need a definition of involvement that doesn't just count commits etc. Also want to avoid discriminating against certain vendors.
• @dleach02 if we structure the project so that WGs and maintainers have the main influence on the project, and TSC is only involved to smooth out conflicts. I don't see the TSC as being that important of a role if we're successful at that
• @nashif we cannot leave all decisions to maintainers, though -- we have governance and the WGs and TSC are necessary to manage the whole project. We'll still have a TSC and we need to define who can be elected and who votes
• @galak I think having maintainers as part of this makes sense, and could hopefully be a carrot to becoming a maintainer. I think WG chairs are important too. Some WGs or groups may be a bit more fluid, though -- e.g. footprint WG or release managers. Generally speaking want to see if we can use this as a carrot for other roles, not just maintainers
• @keith-zephyr any thought to how the first group of elected members selected? who gets to vote?
• @nashif the current TSC
• @keith-zephyr and moving forward, it'd always be the same?
• @nashif that's what we need to decide - who gets to vote? should be more than current TSC or maintainers. I would use the MAINTAINERS file -- if you're a collaborator or maintainer in that file, we could use that as being able to vote. We could expand the MAINTAINERS file as well to be more inclusive of people who don't contribute code.
• @mbolivar-nordic could have a union based approach where we say "maintainers can nominate themselves", etc., and a catch-all category that allows anybody to nominate themselves but with a justification
• @galak so who gets to decide on the catch-all?
• @mbolivar-nordic whoever gets to vote in the election for TSC members
• @galak for the catch-all case, I would leave it to the current TSC instead to decide if a catch-all person was suitable
• @nashif I think we do need a body that drives all of this. Probably the Process WG.
• @mbolivar-nordic not to get too far ahead, but I think the way we conduct the election will matter (51% or runoff election, ranked choice, etc.) will also affect whether we want a body that gates whether you can even be on the ballot
• @galak I think having the maintainers file plus the TSC as the voting body makes sense.
• @mbolivar-nordic do we want to weight votes so TSC members have more votes than someone in the maintainers file?
• (no one thinks so)
• @mbolivar-nordic so do we want to allow anyone to nominate themselves?
• @nashif I would say no: let's have a well defined set of ways to let you nominate yourself: you have to be involved in the project in some way
• @galak I think having anyone in the MAINTAINERS file is fair game to nominate yourself. have the set of voters equal the set of people who can be nominated

[mbolivar-nordic]

Process WG

• Call for interested parties to investigate voting systems and make suggestions for Zephyr

Consensus on:

• having defined terms for elected TSC members: 2 year terms are proposed
• having different elected TSC chair positions end at different times, to avoid having a single large election for all elected TSC members (e.g. elect half of the elected members on even years, and half on odd years)
• adding or removing elected seats at the next regularly scheduled election, not when appointed membership changes (like a 1 year census)
• if elected members are no longer able to serve, allowing (but not requiring) TSC chair to call a snap election to fill the seats

---

• @nashif next items are voting and cadence for adding members. If we go to a 50/50 appointed/elected member composition, what happens if we get 2 new platinum members? We would want to try to elect additional TSC members -- how do we see that working? Always on the hunt for additional TSC members?
• @mbolivar-nordic seems to become clear when we have an election. We agreed that anybody who qualifies can nominate themselves. Today if we have to elect a new elected member, it's just a 1 week election over email, right?
• @nashif yes, but today we have a yes/no vote for a single nominee, not an election among 20-30 people.
• @keith-zephyr need a nomination window and an election window. During the nomination window, anybody can nominate themselves, collected up by @bprestonlf . When that closes, have an election window for probably longer than a week, given the size of the electorate.
• @nashif could be 2 weeks
• @dleach02 feels like we're trying to find additional elected TSC members, and we're doing that maybe once a year. Another question is what the term is -- I would say existing ones remaining engaged could remain until they're voted out.
• @nashif do we want to go through the process of ranking based on their involvement and voting mid-year, for example?
• @dleach02 I think we should have a way to vote people off who aren't participating. If you've done IEEE standards, to get voting rights, the criteria for gaining and losing them are clear.
• @nashif so let's say we are at a 20/20 composition. I think there should be a term for TSC members which should probably be aligned with the TSC chair, which is 2 years (1 year passes so fast). The appointed/elected members vote in the chair, so we can have this happen at the same time: every 2 years we would have an election. Right now we don't have term limits, so if you're a member and you want to continue, you can nominate yourself again and people will decide to vote you in or not (e.g. if you're inactive). Dealing with exceptions (people leaving their positions, complaints against individuals) needs some bylaws.
• @dleach02 I suggest keeping expectations very simple: simple rules for how to retain, since too much complexity opens things up to interpretation. I think of this in terms of voting quorum when needed.
• @keith-zephyr I would say if we didn't have terms for TSC members, that'd make it hard for new contributors to join the TSC. We'd tend to get a fairly static TSC with familiar faces on it without much turnover.
• @galak I like the comment about a 2 year term; agree that 1 year goes by real quick. If you're trying to vote for 30 people at one time, it becomes noisy. How do you deal with 30 positions open at one time? I don't have a good suggestion. Do you stagger some votes quarterly? E.g. take the number of elected positions and divide them by 4 and expire a subset every quarter?
• @galak yeah, so some seats might expire a bit earlier than others to get this process going. Another question is if someone leaves a seat, then someone else is voted in, but that position is only until the next voting cycle for whenever that seat was.
• @MaureenHelm I agree with @galak. I'd lead to an annual cadence on a 2 year term instead of quarterly to also encourage new blood on a more frequent basis. That would reduce the size of the election and have a more consistent pipeline for opportunities for community members to join the TSC.
• @nashif also need to think about who gets to nominate themselves as the TSC chair. If the TSC chair is an elected member for example, what happens?
• @dleach02 could have a one line variance to extend their term to the end of the TSC chair term
• @galak what do we say currently for who can nominate themselves for TSC chair? Do you have to be a TSC member?
• @mbolivar-nordic that isn't explicitly specified in the charter that I can see
• @nashif I think this is implicit; need to clarify with Kate
• @mbolivar-nordic can we settle on yearly cadence for elections (half on even years, half on odd years)?
• @galak OK with that until we have 10 or more people per election, then it gets to be too much. I would suggest that if a new platinum member joins we do the election at the next time
• @galak so what do we do if someone elected leaves? do we leave the seat vacant until the next election?
• @nashif maybe we can allow an election as an exception
• @galak I think maybe allowing the TSC chair to call an election if necessary
• @nashif that would allow for doing an election for 3-4 seats if multiple people change -- makes sense since it's not just appointed TSC members voting.
• @galak posts link to https://civs1.civs.us/, used by linux TAB
• @mbolivar-nordic does anybody think we should not use some type of ranked choice?
• @dleach02 I need some time to think about it
• meeting adjourns early since no consensus on voting systems today seems likely

[keith-zephyr]

Process WG summary:

@nashif - will create proposal based on currently discussion talking points from this issue.

==== @nashif - What are the mechanics for making the TSC structure change? How can this be done incrementally? @keith-zephyr - what about switching platinum or silver members as each group individually. nashif - this requires a change to the charter so better to do both at the same time. @nashif - could experiment with expanding elected members first. But more interested in making the TSC more effective first. Restructure working groups, identify additional areas for a new WG. Make governance of WGs more official. Get more TSC member involvement in WGs and other areas. Figure out election mechanics and charter change later. @nashif - focus on changes that don't require a charter change. @keith-zephyr - what other roles should we encourage TSC member to take on. WG chair, maintainer of an area. @nashif - currently at 45 members - adding elected members means the TSC needs to scale to continue be effective. @dleach02 - silver members are the larger change. Silver members are giving up a lot if the TSC vote is dropped. What's the value proposition to silver members. @nashif - agrees some silver/platinum members will see this as a downgrade. We need to present a proposal to gather feedback. Could eventually get to a point where TSC is all elected members. At governing board, they are investigating the various Zephyr assets that could be opened up based on the member level (silver, gold. platinum) @dleach02 - Should add a goal/objective that the TSC is more active. Hopefully current silver TSC members already have enough engagement to be elected. @nashif - TSC votes are very close. This is due to quorum requirements and non-votes. May need to adopt new voting requiremets/rules. We should use an existing process that is proven. @keith-zephyr - In terms of gaining engagment - start with formalizing WGs.
@nashif - has a working doc with some ideas on new WG organization. Rules can't be top down - need buy in from the community. Execution of proposed changes is lacking within Zephyr. It usually comes down to individual or company championing their own goals. @dleach02 - The lack of execution is common for open source projects. Not an easy problem to solve. @nashif - The Zephyr structure should allow us to be better than other projects.
@nashif - Coding styles is an area that exemplifies problems with execution. Not enough tooling to enforce all guidelines. @dleach02 - at NXP, lots of business units. When evangelizing Zephyr to other BUs, other groups ask how to get changes to Zephyr? David's feedback is to contribute their ideas directly instead of trying to wait for the community. But there is some pushback from teams want to protect their own IP. Other teams see the value of using Zephyr, but still lean on David's team to make changes upstream.
@dleach02 - there are successes at the Zephyr project to advertise - number of devs that contribrute directly to a release. @nashif - More areas in the project need more engagement. How does the project drive changes to completion? If the community doesn't step up, Zephyr could consider hiring an expert to address a specific task (e.g. security audit). @dleach02 - any objections to presenting a restructure to the TSC. @nashif - Need to have the high level goals written down. Participation in Process WG doesn't necesarily represent the full community, @dleach02 - Status quo is also an option. Maybe use the F2F to gauge interest from the full TSC. @nashif - Status quo for TSC composition still leaves existing problems with effectiveness of TSC. @nashif - option A status quo, option B improve voting and improve WG and improve particpation. @dleach02 - Suggests creating a straw poll to gather sentiment from the TSC members. Non-binding vote on the options for restructuring the TSC.
@nashif - The governing board has requested to get more community involvement. The Process WG is doing the prep work. Goal should be to have straw poll ready for F2F meeting. @dleach02 - wants to make sure we get feedback from TSC before doing a full proposal. TSC may have different priorities than what Process WG has identified.

[keith-zephyr]

Process WG notes for 2023-06-14

@nashif slide deck: https://docs.google.com/presentation/d/1FGCT-Rp-36y6kgndNtU_l5ksEZO021YHdyDbfXs8GcM/edit?usp=sharing

@nashif presented problem statement with existing TSC structure. TSC growth, efficiency, appointed members, no definition for TSC member role. @nashif without clear TSC member definition, there is confusion from new contributors. @nashif How to keep silver membership attractive if we reduce appointed members and increase elected members. @nashif Working groups need more participation. @dleach02 It's a low barrier to attend WG. Community members can attend without being on the TSC. @nashif - Wants to get TSC members participating more on WGs. This would allows TSC to delegate more tasks to WGs, but this needs a defined structure. @nashif - each working group has a board/body/quorom. This establishes some authority to the WG, when there is a defined process. @nashif suggests a minimum requirement for TSC members is to participate on a WG.
@dleach02 restating - TSC members need to participate in technical direction by participating in a WG. @nashif - Not all WG need to be done through meetings. @dleach02 - expanding TSC definition - members should engage on PRs, issues, etc. "impactful contributions".
@nashif - helping with backlog of issues and RFCs is an area where TSC members can help - this doesn't require a meeting. @nashif - WGs need participation to be successful. Phase 1 defines a 5 member body. @nashif - delegation of TSC duties can help keep TSC meeting more focused. TSC is used for escalation. @dleach02 As member of IEEE, so companies hire experts knowledgeable in Robert's rules. David likes the structure generally, but it can be overbearing. @nashif Phase II defines new TSC structure. We can point TSC members back to github issue for details of past discussions. The F2F meeting will be an opportunity to get new ideas for TSC structure. @keith-zephyr What's the timeline for phase 1? @nashif conservatively to define roles by the end of year and start executing in 2024. @dleach02 There are organization making large contributions - will we end up with a TSC that consists only of members? @nashif - This is okay, because TSC will be filled with elected reps. It's expected that many elected reps will be part of member companies. @nashif Historically Intel was the main contributor. This self corrected as more companies joined. Intel didn't drop number of commits, other companies added to the total commit level. @dleach02 The biggest change is of phase 2 is the switch from 2 to 1 TSC members for platinum companies. @nashif Switch from 1 to 2 was done to increase the size and engagement of TSC, without changing charter and coming up with an election process. This happened 5 years ago - it's time to manage the growth. @nashif It's possible phase 1 solves enough problems, that phase 2 is not needed. If WG take larger role, TSC becomes less involved. @simhein One question about offloading voting to WGs? If WG has voting responsibility, does TSC still have veto? @nashif There would be official duties assigned to WGs. Currently consensus in WG doesn't have any official weight. @dleach02 Not every TSC member needs to cover every meeting. @nashif WGs should send out minutes with decisions. This provides opportunity for other community members to object and re-raise the issue.

[keith-zephyr]

Moving to on-hold as this issue is blocked by https://github.com/zephyrproject-rtos/zephyr/issues/60315.

[keith-zephyr]

Blocking issue #60315 is closed, nothing more to do on this issue.