Propose a new Conda Technical Review Board about governance HOT 13 CLOSED

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.

from governance.

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

from governance.

Yes!

from governance.

Yes

from governance.

Yes!

from governance.

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.

from governance.

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.

from governance.

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.

from governance.

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.

from governance.

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

from governance.

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.

from governance.

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.

from governance.

Closing given no additional feedback.

from governance.