Governance proposal: Steering Committee and Teams #17
Conversation
|
@jorisvandenbossche here is the first PR for the governance document, covering the front and back matter. |
|
Also see #18 for the material that goes in the middle. |
jorisvandenbossche
changed the title
|
cc @pandas-dev/pandas-core |
governance.md
Outdated
|
|
||
| Each Team has defined responsibilities for different aspects of the project. As a | ||
| general rule, an Individual Contributor can be nominated by a member of a Team to become | ||
| a member of that Team, and the Team must unanimously agree to admitting that person to |
There was a problem hiding this comment.
-1 on this whole part. The core team should make the decision on updates to teams. This seems design to allow couple of people to become part of a team, and then decide who can join it, who is kicked out of it... The core team and the interested person should be able to decide who becomes part of a team and who better leaves it.
There was a problem hiding this comment.
Let's take the example of the pandas-stubs team (maintaining the pandas-stubs package). If there is a new active contributor that they would like to add to the stubs team, I am fine with the existing stubs team to decide on that, and I don't think the whole "core team" should have a say in that.
So in some way this is indeed "designed" to allow that, but of course not designed to misuse that power. But if that would happen, there are still other mechanisms to do something about that (such as the Steering Council and code of conduct).
Strictly speaking if another team would disagree with the addition of a new member, I think that would already fall under the current description of the general scope of the Steering Council, but we could also explicitly mention the Steering Council here as having an overruling power for team additions in case there are profound concerns.
|
Thanks for all the work on this @Dr-Irv - looks great to me. |
|
@pandas-dev/pandas-core pinging for any further comments. |
|
Moving some of the discussion here, to keep the voting issue purely with actual voting comments (it's fine to explain the reasoning of your vote when voting, to be clear, I just want to keep further discussion here): @datapythonista explained his -1:
with @MarcoGorelli's response to those items:
with which I fully agree. Yes, we listed a lot of teams, and probably too many for the current reality. But 1) the thinking was that we were listing the teams we would like to have, and then actually having them listed might be easier to get people interested in it, and 2) those teams are not set in stone. If one of the teams doesn't work out in practice, then we can just update or remove it from the list later. Personally, I am seeing this as voting on the new structure of having a SC and teams, i.e. the principle of having teams, and then the exact teams and their responsibilities can grow and evolve in practice. |
|
No, those are explicitly excluded from having voting rights: "All members of each Team, except the Code of Conduct Team, are eligible to vote."
Specifically for the Finance team, we updated the text to say that the Steering Committee has to approve new members for this team. Now of course that is only for the Finance team and not in general. I did suggest adding a note that the Steering Committee could overrule team additions if necessary to cover such misuse, the previous time you brought this up: #17 (comment) |
Just in case the current proposal does not get enough approvals, an alternative based on the Areas of Focus from https://www.opentech.fund/funds/free-and-open-source-software-sustainability-fund/ Proposal for Simplified Team Structure for the Pandas ProjectObjective: To streamline the team structure to address complexity, ensure clarity, and enhance long-term sustainability by focusing on three core teams: Maintenance, Operations, and Community. Proposed Team Structure: Maintenance Team:Responsibilities: Operations Team:Responsibilities: Community Team:Responsibilities: Discussion Points:Simplicity and Clarity:This proposed structure simplifies the current complex proposal, making roles and responsibilities more explicit and easier to manage. Resource Allocation:With only three teams, we can ensure that each team is adequately supported. Steering Committee Concerns:The current proposal includes a Steering Committee with significant authority, which may centralize too much power. Conclusion:By focusing on three core teams, we can create a more manageable and effective framework.
My reservations about the current proposal is about the viability of the proposed team structure and the concentration of power in the Steering committee. Both these concerns could be addressed if we also discussed/voted on a much simpler structure as suggested above. |
In our discussions, we did not give that much "power" to the Steering Committee. The goal of the Steering Committee is to coordinate efforts across multiple teams. From the proposal:
I am struggling to see how this list of responsibilities gives the Steering Committee a "concentration of power". In addition, the Steering Committee is chosen via an election, so if members of the committee did something so egregious that it upset people, the annual vote could remove them. Also, the Teams structure we came up with was an outcome of the discussions in Basel in August, 2023. |
This does not address the concerns I have about the Steering Committee (SC) potentially having too much power. Let's break down the points:
To address these concerns, we would need to consider implementing the following protections:
These measures can help balance the SC's authority and prevent the potential for autocratic behavior. |
|
tl;dr
I really really don't like this sentence! |
The proposal states that the Steering Committee has “limited” routine decision-making authority. However, it does have the authority to:
Each year by October 31, Steering Committee members will be asked if they wish to continue. If a member steps down, new volunteers will be solicited from the Stewards by the SC.
|
|
@simonjayhawkins you have some really good questions here, although I'm curious if you think this proposal makes those issues worse than they are today, or if they are just things that can improve after this initial structure is set in place? The potential for abuse of power by the SC can definitely happen, but I think that's less of a risk moving from a BDFL model to an SC model. Of course, we've been fortunate with Wes at the helm to have never faced that issue, but I'm also then hopeful that having a 5 person board that we elect will continue in that same direction |
|
I don't think it's only the potential for abuse of power of the steering
commitee that is worrying.
As of today, the actual way of making decisions is that for anything
important the core dev is asked. While not always very efficient, I'm
personally very happy with this. We decided together spending money in
mentorships, signing a sponsoring agreement for our hosting, or creating a
Slack instance.
The new proposal is quite ambiguous in my opinion, but in general seems
like the core team doesn't have the decision making anymore. Teams seem to
have it, so if I'm the only person in the communications team, sounds like
I can make pandas publicly endorse a US presidential candidate. Or the
finance team can decide to give or deny mentorships without the core team
even being notified.
Amd then, the steering committee can overrule anything done by the teams.
But I don't think it's defined how the steering committee will make
decisions. A majority vote? Consensus?
I think we are all counting in people having good intentions for those
things to not happen. But if that's the case, why do we need such a complex
governance that make things ambiguous, time-consuming and complex in the
first place?
I'd rather have a one paragraph governance that says the core devs are the
decision makers of the project, and that any important decision requires
consensus, consensus with maximum one objection, 2/3 of the votes or
whatever.
…On Fri, Aug 30, 2024, 00:01 William Ayd ***@***.***> wrote:
@simonjayhawkins <https://github.com/simonjayhawkins> you have some
really good questions here, although I'm curious if you think this proposal
makes those issues worse than they are today, or if they are just things
that can improve after this initial structure is set in place?
The potential for abuse of power by the SC can definitely happen, but I
think that's less of a risk moving from a BDFL model to an SC model. Of
course, we've been fortunate with Wes at the helm to have never faced that
issue, but I'm also then hopeful that having a 5 person board that we elect
will continue in that same direction
—
Reply to this email directly, view it on GitHub
<#17 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACMXUAAE2DGZXVPG7B22EHLZT6K33AVCNFSM6AAAAABFQAEEAWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJZGEYTKNJTGE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@bashtage answering one of your comments here:
It might be something we should clarify, but at least it was not our intention that a steering committee member could just stay on the council if they wanted without being re-elected. It can probably be simplified by not making such a clear distinction between new volunteers vs existing members, but at least the intent clearly is to always have an election regardless of members stepping down or not. |
Thanks for clarifying - I understand your point of view more on this now, although I have the exact opposite assessment as to whether that is good or not :-) In our current state, while our team is very large, I find that very few people actually vote on things, and if they do, its entirely unclear who made what decisions and when, so there is very little to trace decisions back to. I'll bring up some recent examples that are hopefully non-controversial (and for which I am to blame if there is disagreement):
Of course this proposal won't solve all of our problems, but I could only imagine it helping those situations.
The core team has almost always been about coding, which doesn't mean that its members have interest or want to do anything with finance. For the few that do, they can still join the finance team if they want, but I think this enables the finance team to also add to the larger organization people who don't code, but that can still offer help with finances. |
|
Thank you for sharing your opinion and experiences.
I don't see how the new governance would help in these examples. You wanted
to do something, you asked, nobody objected or cared, and you could move
forward, no? I personally think it's better to still share those things, so
the rest of the team is informed, and in other cases could potentially
contribute.
What you describe could surely help in other cases. When we did the new
logo, I spend a decent amount of time trying to get feedback from the team.
The proceas was often frustrating, and not very efficient. But I still
think it was better to give people the opportunity to have an opinion,
object... Than creating a logo team for me, and end up with the logo that I
like without counting with others.
I'm not trying to say that you should agree with my point of view. It's
great to have different opinions. But I'm still -1, and even if the team is
big, I won't be comfortable that decisions are made by small groups which
aren't even necessarily made of core devs. And given that all our existing
teams are in my opinion inactive, I also think the new governance is
unrealiatic and not very useful.
…On Fri, Aug 30, 2024, 01:43 William Ayd ***@***.***> wrote:
As of today, the actual way of making decisions is that for anything
important the core dev is asked. While not always very efficient, I'm
personally very happy with this. We decided together spending money in
mentorships, signing a sponsoring agreement for our hosting, or creating a
Slack instance.
Thanks for clarifying - I understand your point of view more on this now,
although I have the exact opposite assessment as to whether that is good or
not :-)
In our current state, while our team is very large, I find that very few
people actually vote on things, and if they do, its entirely unclear who
made what decisions and when, so there is very little to trace decisions
back to.
I'll bring up some recent examples that are hopefully non-controversial
(and for which I am to blame if there is disagreement):
1. Back in June I asked on Slack about the team's opinion on if we
should opt out of Slack's updates ToS for SlackAI. I received three thumbs
up, with only 2 of them actually coming from team members. I went forward
with this decision anyway
2. When we were talking about the ROSES grant (to which I ultimately
never applied), I really had no idea who to contact. I almost
single-handedly made the decision to submit an NOI, and then ultimately to
withdraw our application.
3. The last two CZI applications were not shared with the entire team,
which I don't think anyone even realized until after the second one was
rejected, because no one volunteered to help. The submitters asked for any
feedback, but never got any
Of course this proposal won't solve all of our problems, but I could only
imagine it helping those situations.
Or the finance team can decide to give or deny mentorships without the
core team even being notified.
The core team has almost always been about coding, which doesn't mean that
its members have interest or want to do anything with finance. For the few
that do, they can still join the finance team if they want, but I think
this enables them to also add to the larger organization people who don't
code, but that can still offer up a lot with finances. In all, I think that
helps with the financial aspects and continues to grow our team
—
Reply to this email directly, view it on GitHub
<#17 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACMXUAHRCJWFE2VJFUSUSM3ZT6WZNAVCNFSM6AAAAABFQAEEAWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJZGQ3DSOBXGE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Do you think they would be more active if our team included more than core-devs? I think the reason we can't staff teams that aren't dev-related is because of lack of time, interest, and resources, but on the flip side we aren't allowing in resources that are non-devs, which feels like a catch-22 |
Of course, the benefits of moving from a BDFL model to an SC model are well documented. The BDFL Model concentrates power in one person, which can be risky if that person acts against the project’s best interests. A Steering Committee distributes decision-making power among multiple elected members, which can mitigate the risk of power abuse by any one individual. However, we are solving a problem that we do not have. Currently, important decisions are made collectively by the core developers. This approach, while sometimes inefficient, ensures that decisions are made with diverse input. The new proposal seems to shift decision-making power away from the core team to individual teams, which could lead to inconsistent and potentially problematic decisions without broader consultation. The new proposal attempts to mitigate this by giving the Steering Committee the authority to overrule team decisions, but the process for how it will make these decisions is not clearly defined. So I think the overall result of the proposal in its current form is that the decision making will be less democratic, less transparent, less diverse and less accountable while also being more complex and crucially, untested and unrealistic. |
Continuing on those specific examples, I do think that the new governance helps with this. Not auto-magically with the fact that Will didn't get much response on those specific questions and made a decision (although we also hope that having more explicit teams will improve this somewhat), but to make it clearer that it is OK that Will did this. In my mind, even if we adopt the governance proposal, we mostly keep working as we are. And I would still expect that Will would ask those questions to the whole team to gather input. But then if there is some (or not much) input, it is explicitly OK that Will makes a decision on this (assuming he is part of the specific team that has slack admin access, or part of the team writing a grant proposal, etc). One of the motivations of the governance proposal is to make more explicit what is already happening implicitly. Will is maybe seasoned enough in the project that he then did make those decisions, but he still shouldn't have to wonder about that, and making those aspects more explicit has a lot of value. I still expect that people, in this example Will, listen to other people in the project, and takes that into account when making a decision on e.g. the slack setup. And if concerns are raised and Will would just stubbornly and single-handedly ignore those concerns, well, then there is a conflict. And at that point the Steering Committee has a responsibility (and mandate) to intervene in such an "exceptional circumstance" (ask Will and the others what is going on, mediate, and potentially make some intervention). |
Perfect. How do we ensure that these principles are not just expectations but clearly communicated? |
We are still solving the "problem" of having an (inactive) BDFL while we think that there are better models for our community. While we definitely had no specific problem with our BDFL in the past, IMO that doesn't mean that it is not worth addressing the issue.
And also with this model, the idea is that important decisions are still made with our collective input. But at some point, after potentially lengthy discussions, someone still needs to "call" an actual specific decision. This is the part that in practice has, IMO, often created unclear situations (have we discussed it long enough? is there "enough" consensus? is it OK that I go ahead now? or if there is disagreement but it is an issue that still requires some decision, then who makes that final decision? etc) We wanted to make this "decision part" (not the discussion part) clearer. And there are of course other options than the steering committee and teams. For example, we could extend the PDEP model to all kinds of (also non-technical) decisions and vote on everything. But in the meetings discussing this proposal, we felt a preference for not voting on every single issue, but rather a model like a steering committee (quite similar to what several other projects in Python community have as well). Specifically for decisions made by the Steering Committee, this is currently written in the proposal as "members of the Steering Committee are responsible for soliciting input". Re-reading our current governance text, I noticed it has an explicit paragraph saying: "In general all Project decisions are made through consensus among the Core Team with input from the Community. The BDFL can, but rarely chooses to, override the Core Team and make a final decision on a matter." While something like that isn't stated explicitly anymore. It might be good to still include something along those lines, adapted to the proposed structure (something saying decisions are still made through consensus among Team member with input from the community (for things a specific team can decide on) or through consensus among all members with a final decision by the Steering Committee (for things that fall beyond a single team).)
My feeling is that you are overestimating this decision-making power that is shifted. Most of the responsibilities and permissions listed in the proposed teams page are quite obvious things (or how we already work in practice), I think. For example, the core library team can merge PRs and vote on PDEPs, the stubs team can merge PRs in the stubs repo, the infrastructure team manages the server and the passwords and accounts, the triage team can manage github issues, the documentation team can merge PRs specific to documentation, etc. The one exception is maybe the Finance team, where the decision power they are given feels bigger. But I also want to point out that our current website already describes this team as "Responsibilities: Manage the funding. Coordinate the request of grants. Approve the project expenses." .. (and I didn't add this to the website, to be clear) So for the "Currently, important decisions are made collectively by the core developers.", I think most of the important decisions (except for technical decisions that are covered by the PDEP process, which probably doesn't leave that many decisions) will not be taken by individual teams but still collectively. |
|
Thanks Joris for taking the time to respond to my post. Firstly, the last thing I want to do is block any changes or discredit any effort by the governance team over the past 12 months. Thanks to all involved. Changing the governance could potentially be the most important decision made by the project for a while. To not have full consensus and have several positive votes with caveats is a tad worrying. It is important that the transition from a BDFL model to a Steering Committee and Teams ensures that the governance structure remains effective and fair. I made a comment back in May (#17 (comment)) about a particular sentence. This was my "red line" and while still included in the document would not give a positive vote. We now have some extra input from the voting process that we did not have during the months of discussion . And to be honest, after my small batch of initial comments, I neither engaged in further detailed review of the document wording as I normally feel that it is important to first let the dust settle on the important discussion points before going more in depth. I will not address the specific points you have made at this stage because I don't generally disagree with you intentions and views and will first wait for the outcome of the vote. If the proposal does not pass first time, I am more than happy to help with more detailed review so that a subsequent vote is more conclusive. There has been some mention of losing momentum. I personally think the opposite is true. We have more engagement from the team as a whole now that the vote is underway. To make another iteration of the proposal to incorporate the feedback gained during the vote would probably be better than just saying we can do it later. I think that once the vote passes, the momentum to improve the document is more likely to be lost. This is another reason why I am now comfortable with giving a negative vote in the first round. |
|
Thanks Simon. Quick question for clarification on one thing:
Is that about the the Steering Committee being a "small group carte blanche to override a PDEP decision." ? |
|
IIRC my intention was that I gave the PDEP as an example. |
|
@jbrockmendel wrote at #20 (comment):
The proposal includes that we will use the voting procedure as described in PDEP-1 for future changes to the governance model, and so that includes abstaining votes that count towards the quorum and a majority rule based on non-abstaining votes. So this concern should be covered.
I certainly understand that concern for changing the governance, but I am not sure what to do about that .. A similar issue happens for PDEP discussions, and it is something we have to be beware of, but to some extent I think it is also unavoidable when you want to build consensus in online (with mostly written communication) projects.
I would say that this is (for "less important" decisions, however you interpret this, like not having project-wide impact, or not requiring explicit buy-in from a majority) more or less compatible with what we propose through the teams (e.g. the people working on the server infrastructure are empowered to make decisions on that, the people working on the website can make decisions about the website, etc). Only that by defining the teams it makes it more explicit who those people are.
This concern indeed has come up regularly, and I was planning to explain a bit more the reasoning behind that in a separate post. |
For future reference, Irv opened a separate issue to discuss this -> #21 |
|
And thanks Irv for the writing! |
These are changes to the governance documents with respect to the beginning and end of the document, and with the details about the Steering Committee and the concept of Teams. The exact list of teams and their responsibilities are in #18
Summary
We are proposing the following changes to the governance model, based on ideas used in other projects:
To manage the project, there are different Teams that each have responsibility for
specific aspects of the project. Collectively, the members of all Teams are referred to
as Stewards of the project.
Compared to the current governance docs, this removes the notion of a BDFL, and the "Core team" (the current set of committers) essentially becomes the initial Core Library Team (with the same responsibilities and rights as the current core team).