Propose a new Conda Technical Review Board

[jezdez]

Proposal

I’m proposing to form a “Technical Review Board” subteam to improve the process of authoring, reviewing and voting on Conda Enhancement Proposals.

Team Charter

Following the governance policy, this is a static charter with the additional conditions that:

• any member of the Conda Steering Council may join this team at any time
• the number of non-steering TRB members is at most 3
• the Conda Steering Council may change the number of non-steering TRB members via a simple majority vote
• the non-steering TRB members are elected, and can also be removed, by the Conda Steering Council in a secret ballot similar to sensitive voting items listed in the Conda Governance Policy
• the vote threshold for addition or removal of a non-steering TRB member is a simple majority
• the elections happen annually after an application period of 2 weeks before the election date
• the Conda Steering Council will call for applications
• applications must contain a short statement by the candidate towards confirming their credentials and their ability to work as a technical reviewer
• the Conda Steering Council retains the right to call votes on CEPs without the approval of the TRB

Work areas

The Technical Review Board is charged with the following:

• follow the Conda Code of Conduct
• act in the best interest of the conda community
• provide their technical expertise to the conda governance process
• facilitate the review, handling and shepherding of Conda Enhancement Proposals that are labelled as "technical"
• enable the Conda Steering Council to vote on technical CEPs

Responsibilities

• co-maintenance of the conda-incubator/ceps repository, especially of CEPs labelled "technical"
• guide and mentor the CEP authors in scope of this team charter
• provide quarterly reports to the Conda Steering Council about the current status of the technical CEPs
• submit all technical CEPs that are deemed ready for vote by the CEP author(s) and TRB for vote to the Conda Steering Council
• provide a recommendation to the Conda Steering Council (e.g., “Our vote recommendation: yes”)
• to reduce the effort needed by the Conda Steering Council, the technical CEPs may be submitted as an omnibus proposal set (read: one vote for many technical CEPs)
• if the vote by Conda Steering Council does not match the TRB’s recommendation, the technical CEPs must be reviewed again by the TRB and may be submitted in the future, after appropriate changes are made
• communicate the voting results to the CEP authors and communications team

Scope

The “Technical Review Board” is working for the Conda Steering Council and follows the Conda Code of Conduct. The team provides guidance to new and existing authors of Conda Enhancement Proposals with the objective to submit the proposals for vote to the Conda Steering Council individually or optionally as part of a regular (quarterly) omnibus set.

The team in particular exists to enable the Conda Steering Council to conduct votes on matters that require deep technical understanding and to facilitate the participatory process.

Initial applications

As part of the adoption of this proposal, I suggest to:

• [ ] vote on the proposal (see below)
• [ ] if passed, call for applications for the founding Technical Review Board

[jezdez]

@conda-incubator/steering

Vote

This proposal falls under the "Sub-team Formation" policy of the conda governance policy, please vote and/or comment on this proposal.

It needs 50% of the Steering Council to vote yes to pass.

To vote, please leave "Yes" or "No" below as comments.

If you would like to propose changes to the current proposal or have questions, please leave a comment below as well.

This vote will end on 2023-02-22, End of Day, Anywhere on Earth (AoE).

[beckermr]

Yes!

[ocefpaf]

Yes

[jaimergp]

Yes!

[jakirkham]

Generally think this is a good idea. IIRC this follows off of a discussion we had last year to move in this direction of having a technical advisory group on CEPs.

One discussion in the meeting that raised was that "the number of non-steering TRB members is at most 3" is kind of limiting. Admittedly this falls out of our governance structure today. The thinking is that a subset of the steering council may not be the answer for moving technical proposals forward. We may need/want a different group of people. Maybe there is another vehicle we can use that doesn't have this limitation? Alternatively we can update governance, which @tnabtaf is looking into (please correct me if I misunderstood).

Another thread of discussion in the meeting, would suggest we somehow organize this by subtopic (installers, repodata, package format, recipe structure, plugins, etc.) and form subgroups (within? below? ??) the TRB to handle these more scoped topics. Suggest this in terms of expertise, interest, creating smaller/faster groups to make changes.

A final point was a concern IIUC about the SC and TRB handing down edicts. At least as I understand it the process we have been going through (particularly recently) is the opposite. Namely we have lots of code out there that has some behavior, but lacked a spec previously. So the work of the TRB and the SC to some extent is helping developers convert these into readable specs so this knowledge is accessible.

[beckermr]

Yes your final statement is goal here. It might be good to have a more cohesive approach to specs and standards. Having a standing body devoted with expertise devoted to this would be helpful.

I'll also add that even if your expertise is in one subdomain as opposed to the other, that doesn't necessarily disqualify you from looking over CEps.

[beckermr]

Also, @jakirkham, there just are not that many of us active in the community as a whole, maybe 25-30? So having the TRB be divided up by topic, while it sounds nice, might end up with an excess of bureaucracy. A single body, of order 5-10 people give or take, would be sufficient for most things.

[jakirkham]

AIUI the overall goal here is to be nimble and move quickly. I'm imagining ~5 +/- (maybe even just 3) per topic. More than that is probably more than needed.

[beckermr]

The TRB should organize this themselves. There's no reason to enshrine a fixed list of subjects in our docs or even that that has to exist. Instead we specify large scale responsibilities and let the folks with the responsibility do as they please.

[jakirkham]

Yeah not trying to micromanage people or overencumber governance docs

Instead my aim is to save all of TRB from being pulled into a bunch of different areas when finer areas of focus and delegation would result in a smoother experience and quicker resolution. If we were to encapsulate this in the docs perhaps it is by setting a very low number of required TRB members for any one discussion thread

Anyways maybe in practice these subgroups would behave similar to language subteams of conda-forge/staged-recipes. Allowing people to dedicate attention to core competencies/interests

[tnabtaf]

Some thoughts.

1. I also think we should rethink the 3 person limit.
2. As discussed in today's call, I will work with @jezdez, and anyone else on this thread, to create a governance update proposal, including formal language.
3. @jakirkham and @beckermr That includes addressing, somehow (please keep discussing!), how to get decisions from board members with relevant experience for a topic, without overwhelming board members without relevant experience. Since teams are self-governing, most of this might end up in the team's charter, rather than in the conda organization governance doc.

@jezdez Thanks bunches and bunches for starting this discussion.

[jezdez]

Thank you all for the feedback!

FWIW, I’m not interested in changing the governance to help with the issue. I’ve contemplated it and decided against it given my experience the last two years. E.g., the last governance update was hand-wrung about even after it passed and so I learned to enable those that are wiling to act instead (e.g. create more subteams and project teams). My goal here is a low-bureaucracy standards and proposal process. IMO the “subteams” of the governance policy already provides enough structure for this, with an appropriate team charter.

I’m a sad to see little support for this proposal which would give enough wiggle room to the TRB to self-govern other than that, e.g. hear expert witnesses to make an appropriate recommendation to the steering council.

In particular @wolfv’s words rung true about whether the TRB would be effective and need to be heard with the context of Mamba’s existence and the work in the larger conda ecosystem not coming from Anaconda Inc.

The number of people in the TRB proposal exists to reduce the overhead of communication and coordination and is balanced out by the time limitation serving on the TRB, to prevent power hoarding. It doesn’t have to be 3, but 5 or 7 also works. But the more seats, the harder it is to find enough people willing to do the work. Would no limit be preferable?

Whatever we do, if the TRB ends up being a “steering council light” we missed our chance to enable more voices to actively participate in conda development.

So IOW I’m leaning toward not supporting a governance change myself if it means that power/influence is kept only in the steering council’s hands. We have simply too few people in there that are doing the technical work of evolving conda, supporting proposal authors and enabling a vital community.

[jezdez]

Closing given no additional feedback.