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 |
| 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 | ||
| the Team, since every Team member becomes a Steward of the Project. If a member of a |
There was a problem hiding this comment.
In the case where someone is inactive for a year, does the "unanimous decision to remove" exclude the inactive member? Or are they expected to remove themselves?
There was a problem hiding this comment.
I'd recommend excluding that member
There was a problem hiding this comment.
I think we should clarify here that the other active members of the Team are the ones who decide on removal.
| issue, but must recuse themselves from voting on the issue. If the BDFL has | ||
| recused his/herself for a particular decision, they will appoint a substitute | ||
| BDFL for that decision. | ||
| All Stewards shall disclose to the Steering Committee |
There was a problem hiding this comment.
What happens if a conflict of interest is not disclosed and later discovered?
There was a problem hiding this comment.
Our current governance policy doesn't cover this case. Open to suggestions as to how to handle the case you bring up.
There was a problem hiding this comment.
Maybe a good default is to say that they are then removed from the team and have to be voted back in? I don't know if that is too extreme but it at least signs the rest of the committee up to sign off on the new disclosure not being problematic
There was a problem hiding this comment.
Have we done this to date w.r.t conflicts of interest? What kind of things are in scope? Core Developer on another project or works in a company that uses pandas heavily/has an agenda?
There was a problem hiding this comment.
We borrowed this text from numpy: https://numpy.org/doc/stable/dev/governance/governance.html#conflict-of-interest . We haven't had a policy of how to deal with a lack of disclosure.
We do list the potential conflicts as follows:
Such conflict of interests include, but are not limited to:
- Financial interests, such as investments, employment or contracting work, outside of The Project that may influence their work on The Project.
- Access to proprietary information of their employer that could potentially leak into their work with the Project.
There was a problem hiding this comment.
It is hard to say what will happen if a conflict of interest is not disclosed.
We'll add text like this: "If a conflict of interest is not disclosed and later uncovered, it will be left to the Steering Committee to decide how to handle the lack of disclosure on a case-by-case basis"
|
|
||
| The initial slate for the Steering Committee election will consist of 5 or more | ||
| candidates who volunteer to be on the slate of candidates for the initial Steering | ||
| Committee. For the initial election, any candidate receiving more than 50% of the total |
There was a problem hiding this comment.
I don't understand this sentence:
For the initial election, any candidate receiving more than 50% of the total
number of members of the previous pandas core team that register at least one vote
will then become a member of the initial Steering Committee.
There was a problem hiding this comment.
The idea here is that the current core team does the initial vote. Let's say only 15 people from the current core team vote. Then any candidate receiving 8 or more votes is on the initial Steering Committee.
Open to suggestions for clarifying this.
There was a problem hiding this comment.
that register at least one vote
This read to me as 1 vote would be sufficient to be voted in. Your clarification makes more sense, thanks.
Maybe:
For the initial election, any candidate receiving a vote from more than 50% of the total
number of members of the previous pandas core team who voted in the election
will then become a member of the initial Steering Committee.
There was a problem hiding this comment.
@Dr-Irv I forgot again why we wanted to do this initial election differently. What was the reason to not follow the procedure as described for subsequent years? i.e. we have a set of candidates, do approval voting, and top-5 are elected?
There was a problem hiding this comment.
The concern here is that we might have a lot of people who want to be on the Steering Committee who are currently on the core team, so we wanted to not exclude anyone. Conversely, if we didn't have enough people who wanted to be on the Steering Committee, it would be easier to get approval of half of the people.
I'm not opposed to using the future "top 5" process, but we should also determine the threshold for how many of the current core team members need to vote. Or we don't worry about that - if only 10 of the core team members vote, we take the top 5 from that.
There was a problem hiding this comment.
After discussion, we'll change this so that the initial election is a top 5 vote getters among the current pandas core team that votes.
| Committee will be asked if they would like to continue in that role. If any member | ||
| decides to step down from the Steering Committee, new volunteers will be solicited from | ||
| the group of stewards by the Steering Committee. Those new volunteers will then be on a | ||
| slate for an election that will occur by December 15 of that year. For each year after |
There was a problem hiding this comment.
Any reason why this is in December with the Christmas frenzy and not either in November or January?
There was a problem hiding this comment.
We chose December 15 to avoid the holiday season, but we could certainly change that.
There was a problem hiding this comment.
Personally, the pre-holiday season is busier for me than the actual holiday season. Maybe just moving it up a month to November? I would prefer that.
The old steering council will stay in effect until the voting is finished, correct?
There was a problem hiding this comment.
Yes. I think we also need to clarify that the term for Steering Committee members is from January 1 to December 31.
| 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 | ||
| the Team, since every Team member becomes a Steward of the Project. If a member of a |
There was a problem hiding this comment.
I'd recommend excluding that member
| The Steering Committee may appoint temporary working groups to work on issues, such as | ||
| governance, that fall outside the scope of responsibilities for the existing Teams. | ||
|
|
||
| The ideal composition of the Steering Committee consists of 5 people. The Steering |
There was a problem hiding this comment.
Having to make decision among 5 people seems as inefficient as having to make decisions among the whole team. I'd prefer to have maximum 3 people, otherwise it doesn't seem this is adding much value.
There was a problem hiding this comment.
The current number of 5 was a compromise between the people involved getting to this initial version. Personally I think to also like a smaller team of 3 (and brought this up before in the meeting), but others felt that this was too small of a team.
It's of course a project of a completely different size and scope, so difficult to compare, but for example the Python steering council also consist of 5 people, and that doesn't seem to prevent them from making decisions (my impression from the sideline).
There was a problem hiding this comment.
It could be that each steering group member represents one of the teams and is accountable to that team. Has this been considered?
Each team could have a deputy representative to participate in the discussions/votes when the steering committee member is unavailable/on holiday.
The teams could be responsible for choosing/electing their representative on the steering council.
I'm not sure if this would increase or decrease the efficiency of making decisions but would maybe make the decisions focused on team goals and not on individual preferences?
Of course the upside/downside (depending on viewpoint) of this would mean that each team has equal importance on decision making.
There was a problem hiding this comment.
I didn't spot anywhere in this document that says a steward can only be a member of one team. I have assumed that one may be in multiple teams and this is is probably likely for most people is some specific teams. Not sure how this would tally with the above idea, but possibly the people who are in multiple teams are the ones most interested / qualified in seeking votes to the steering committee anyway?
There was a problem hiding this comment.
Actually the teams document has criterias of membership being in other teams, so this is implicit.
There was a problem hiding this comment.
Yes, I suspect that as most teams will have members that are also in the core library team, that the representatives would also be from the core library team.
The difference that I see would be that the steering committee would have those core library members being accountable to different aspects of the project and not just a superset of the core library team (even though the members would probably be the same individuals).
We'd have to see how this would evolve over time. In the beginning, the Steering Committee would consist of people who are currently on the pandas core team. But in the future, I could imagine that someone could be a key contributor/leader on one of the other teams (e.g., documentation, infrastructure, pandas-stubs) and not be on the core library team and then be elected to the Steering Committee.
One goal we had is to reduce the responsibilities of the current core team. For example, finance discussions wouldn't involve the entire core team as it does today, but just the Finance team, which would let people who really want to focus on core library issues not have to worry about Finance issues.
There was a problem hiding this comment.
I agree that reducing the responsibilities of the core (library) team is a great way to allow the core developers to concentrate on the issues that interest them the most.
(I personally had no interest in CI/infrastructure but this was a necessary evil while managing the releases)
I think that the initial selection for the teams should be any current core developer that has an interest in that area and allow the core developers to choose themselves which responsibilities they are happy to relinquish.
( I personally would be happy not to be on any of the teams. I consider my presence on the pandas-stubs team as purely a representative of the core team from the perspective of maintaining consistency with the in-line types)
But that leaves the steering committee. Now it appears that this is intended to replace the BDFL. Now Wes is not usually called upon to make decisions and we now have the PDEP voting process for technical decisions. I would hope that the steering committee does not have the power to override a PDEP vote and so that leaves very little for the steering committee to do. (I am concerned with the text The Steering Committee will itself decide when a circumstance is exceptional as this gives the small group carte blanche to override a PDEP decision.)
Now the steering committee is defined as
The role of the pandas Steering Committee is to coordinate the activities of the
different Teams and to ensure that different policies and procedures are carried out in
a consistent manner.
and so to me it makes sense that those teams should somehow be represented.
There was a problem hiding this comment.
I think that the initial selection for the teams should be any current core developer that has an interest in that area and allow the core developers to choose themselves which responsibilities they are happy to relinquish.
Yes, that is the plan.
But that leaves the steering committee. Now it appears that this is intended to replace the BDFL. Now Wes is not usually called upon to make decisions and we now have the PDEP voting process for technical decisions. I would hope that the steering committee does not have the power to override a PDEP vote and so that leaves very little for the steering committee to do. (I am concerned with the text The Steering Committee will itself decide when a circumstance is exceptional as this gives the small group carte blanche to override a PDEP decision.)
I think we should say that the Steering Committee cannot override a PDEP.
Now the steering committee is defined as
The role of the pandas Steering Committee is to coordinate the activities of the different Teams and to ensure that different policies and procedures are carried out in a consistent manner.
and so to me it makes sense that those teams should somehow be represented.
An earlier draft version of the proposal that we discussed in the governance meetings did say that each team would have a representative on the Steering Committee, but then it was felt that it would be giving equal weight to all of the teams, and would also make the committee too large. Maybe we should consider that certain teams must have someone on the Steering Committee, but one person can represent multiple such teams. (E.g., someone on docs and core library could represent both). The concern with doing that is that some of the teams could be small, so that restricts who can be on the Steering Committee.
Our thinking evolved that if a Team is not represented on the Steering Committee, that when the Steering Committee meets, it should reach out to those non-represented Teams to find out if there are any issues from their team that require coordination across the teams.
There was a problem hiding this comment.
Our thinking evolved that if a Team is not represented on the Steering Committee, that when the Steering Committee meets, it should reach out to those non-represented Teams to find out if there are any issues from their team that require coordination across the teams.
Or conversely, that a team without any members on the steering committee, has one of the steering committee members to represent them and liaise with.
There was a problem hiding this comment.
Or conversely, that a team without any members on the steering committee, has one of the steering committee members to represent them and liaise with.
We can be more explicit about this concept in the next revision
|
|
||
| The initial slate for the Steering Committee election will consist of 5 or more | ||
| candidates who volunteer to be on the slate of candidates for the initial Steering | ||
| Committee. For the initial election, any candidate receiving more than 50% of the total |
There was a problem hiding this comment.
50% seems to low. If a person has 50% of people against having they in the steering committee, I don't think this person should be in it. Something like 80% seems more reasonable to me.
There was a problem hiding this comment.
We'll use the top-5 model via approval voting, so the 50% issue becomes moot.
| ### Subsequent Elections | ||
|
|
||
| Subsequent changes to the membership of the Steering Committee will occur towards the | ||
| end of each calendar year. By November 30 of each year, each member of the Steering |
There was a problem hiding this comment.
Renewing the committee every year seems too much overhead. I'd prefer two years to renew the whole committee, and just in case someone has to step down earlier, consider electing a new person if the committee becomes too small.
There was a problem hiding this comment.
We chose the annual election process based on the python steering council using annual elections.
|
|
||
| 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.
| attempts at communication and conflict resolution have failed. | ||
| 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. |
There was a problem hiding this comment.
I find this naming confusing. Not sure if this also created with the idea to replacing the code development team with the union of all team members, including people in teams that are not core devs. But -1 on the naming and giving the decision making to a group with non-core dev people.
There was a problem hiding this comment.
The core development team still exists, but has less responsibilities than they do now. Any member of the core team can be a member of any other team as well, including being on the Steering Committee. What we are trying to do here is enlarge the number of people who have input into the project, based on various roles defined by the teams.
| Committee will be asked if they would like to continue in that role. If any member | ||
| decides to step down from the Steering Committee, new volunteers will be solicited from | ||
| the group of stewards by the Steering Committee. Those new volunteers will then be on a |
There was a problem hiding this comment.
Rereading this, this seems to imply that a new candidate can only step up if one of the existing members step down, but I would think we want to allow a new candidate to be part of the election regardless of someone stepping down?
There was a problem hiding this comment.
The idea here was that members of the Steering Committee, once elected, can remain on the Steering Committee for as long as they want, and they don't have to get re-elected each year. I think (but I'm not sure) this is how other projects do this.
There was a problem hiding this comment.
We can consider putting up the entire Steering Committee up for re-election each year, if they want to continue.
There was a problem hiding this comment.
once elected, can remain on the Steering Committee for as long as they want,
My main comment here that I personally think we should not allow the situation that someone can decide themselves to essentially stay on the committee indefinitely, without ever being reelected. That doesn't seem like a healthy situation if that would ever occur. At least putting a year limit on it would prevent that, but also just requiring to be reelected every election is also a possibility.
| If an existing Institutional Partner no longer has a contributing employee, | ||
| they will be given a one-year grace period for other employees to begin | ||
| contributing. | ||
| the Steering Committee must nominate and approve the Partnership. |
There was a problem hiding this comment.
Seems odd that a smaller steering committee has the ability to approve institutional partners without say/informing those working on the project. Maybe stewards/ Core Lib Team members should have the ability to object?
There was a problem hiding this comment.
We will clarify that the Steering Committee will solicit input from the Stewards before making decisions, which would cover this case.
There was a problem hiding this comment.
Also, such changes will normally always happen in the open through PRs (typically on this repo), and so every member of the project will be able to see those changes and comment on it.
| deems it to be necessary. There will also be a mailing list consisting of all Stewards | ||
| of all Teams. | ||
|
|
||
| Each Team has specific responsibilities as well as Permissions authorities, as defined |
There was a problem hiding this comment.
"authority over permissions" opposed to "Permissions authorities"
|
Thanks for all the work on this @Dr-Irv - looks great to me. |
| the group of stewards by the Steering Committee. Those new volunteers will then be on a | ||
| slate for an election that will occur by December 15 of that year. For each year after | ||
| the initial election, the current Steering Committee members plus any new volunteers on | ||
| the slate will be elected via approval voting, with the top 5 candidates elected as |
There was a problem hiding this comment.
We need to add clarification on who is eligible to vote. It would be all Stewards, except members of the Code of Conduct Team.
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).