APE0: Coco term limits and Ombudsperson #89
Conversation
|
FWIW, my thoughts:
|
This is a chicken and egg problem. If I were new and I see this veteran on Term 5 still re-running, I would hesitate to compete in the first place. |
There was a problem hiding this comment.
FWIW, here are my current votes as of 2023-11-07:
❓ Coco: Only one person from each employer, unless...
❓ Term limits for Coco
I am undecided for the two above because I also share Adrian's worry though I really want these to work out. In our past elections, we do not have an abundance of candidates. Would this suddenly change? I do not have enough existing data points to be confident.
If we try this out and it does not work out as expected, do we then have to change the APE 0 policy again?
I lumped these two together because I think if the term limit end up not making into APE 0, we might still require employment limit. Otherwise, you might have a single institution reigning forever.
✔️ returns officer for votes
I have not seen any nefarious returns officer trying to game the system in Astropy, so this is uncontroversial in my books. Unlike... insert witty political commentary I cannot say here. 😉
✔️ Share Ombudspeople between projects
This is definitely worth trying. I am also curious to see what our current Ombusperson (@perrygreenfield) thinks.
|
@adrn - remember that the terms were different length only for the first election. I think we now have full 3 year terms for all members. I think the proposal for a single 3 year term followed by a break of a year is, in theory, a good idea. I agree with @pllim's point that some people might feel dissuaded from running against an established incumbent. The real concern I have is not being able to fill the ballot. It gets a little hacky, but maybe there needs to be a clause that allows an incumbent to run again if no other candidates are available? The other three are fine by me. About "Only one person from each employer", I believe that individuals can impartially execute their role as a CoCo member without a bias to their employer. Perhaps saying that explicitly in APE0 would help a tiny bit. |
|
Yes, current terms are all 3 years (we only had shorter terms while we phased in APE0):
I explicitly want to get away from the "unless we don't find enough candidates". We had that before with the one-employer rule (and I think I suggested it), but it really makes recruitment difficult because everyone knows that the incumbent can probably convinced to run again. In the last few elections we always had between That's not because of a shortage of people who we could motivate to run, it's because most people are modest and don't put themselves forward as candidates. Instead, most of the Coco members elected post-APE0 (except the incumbents) have been motivated by talking to several members of the community, often heavily involving the previous / outgoing Coco. Also, note that my proposal allows for re-election after some time (one year), so all previous Coco members are also eligible to run. For a Coco election filling two seats the "pool of candidates" is really just reduced by 2 (the outgoing Coco members). We can discuss how long the break should be before being able to be re-elected. I suggest one year for exactly that reason - don't narrow down the pool eligible candidates too much. However, we could also say e.g. 2 years. Note: My intention was "don't run for re-election while on the Coco". I realize now that "one year" might not be a good wording ,e.g. if the 2023 Coco election happens on Oct 5th, but the dates fall differently and the 2024 election starts on Oct 4th, that's less than one year. Maybe we should say "10 months" to buffer that. I don't want to say "can't run if currently on the coco" because that would open the door to people resigning from the Coco 2 days before the election is announced, just so they can run again, and that does not feel right. |
|
@hamogu - fair enough, I'm convinced! |
|
Regarding sharing ombudpersons between projects, that seems like a sensible thing to do, but would increase the workload of each (though I have to say that in the past year or so I have done very little so probably that isn't an issue). That's because people in different projects sometimes need to understand the history of some issues before making informed contributions. It probably is also sensible to get an idea of the work load in different projects (e.g., is one going to greatly dominate most of the work?). Finally, I really doubt I am that qualified; surely there is someone better suited for this than I am ;-). |
|
As far as elections go, I also don't think there should be a rule against more than one person from the same institution. If a particular case is seen as a problem in that regard, the voters can take that into consideration. And the idea of requiring term limits with a 1 year gap should be tried to see if helps encourage more candidates. |
|
If the problem is people being too modest, how about we make it an opt out instead of opt in? Or is that too controversial? "Hello, I see you have been a voting member for N years. You are automatically going to be on the ballot unless you opt out." ❓ |
|
I don't think that having each voting member on the ballot makes that any easier. It would be a fun think to try, but because people just go with the default many might also not opt out and then we end up with 25 names, each of which gets 1 or 2 votes - so the winner is mostly random; and, if we are unlucky, declines the post or resigns on the first day and then we need to vote again. I think the answer is to force the outgoing leadership to make sure there are sufficient motivated candidates - and that's something we can do if we just require that all new Coco members be new. |
|
I am not super excited about a three-year term limit. Folks are just getting the hang of things after three years. If this were a more conventional board where we were advising an executive officer who did the work, I'd feel differently. But the CoCo actually needs to do things and not just advise. Having more turn over means more training and more overhead for the other CoCo members. I'd be more comfortable with a limit of two consecutive terms. |
|
BTW, is CoCo5 not allowed to review this in the first place? LoL... I see in https://github.com/astropy/astropy-APEs/blob/main/APE0.rst#responsibilities-and-authority there is a |
|
Well they are allowed to review but acceptance/rejection is down to voting members right? (And CoCo are voting members!) |
|
I have been thinking about this on and off and still am not firm on all of it, but tentatively I like it with a couple of big "buts": Ombuds group: may not be necessary? (but still worth doing)I am not sure we actually need the Ombudsperson change to do as suggested here. That is, some of our Astropy roles are ambiguous whether they refer to an individual or a group. E.g., the CoCo shares the duties of the CoCo without needing to say "person X does part Y". So I think we could, in theory, have the "ombusperson" be filled by "the NumFOUCS Projects Ombusboard" or whatever and have that work without needing to change APE0. That said, I'm fine with a change clarifying that if a change is happening anyway, but I'm not convinced its strictly necessary to do the good idea you're already suggesting here @hamogu. (And critically, that means groudnwork on this could be done before any vote to modify APE0, which in practice will take quite some time most likely.) Term limits: two terms not one?I agree with @kelle that a single term is simply not enough time for some of the work the CoCo does. If it were a full time job maybe 3 years would make sense, but it is nothing close to that, and in practice that means less effective governance as people rapidly cycle through. I also think, as we have recently been discussing in the CoCo, that it makes the CoCo less effective as a "strategic" entity - i.e., a group that thinks about long-term goals and projects for the Project. There are reasons (which I could go into detail more on if anyone wants) why having a smaller group of people talk to external entities to speak strategically is important, and it's hard to do that if your time is limited to being significantly less than the time scale of the group you're talking to. And 3 years is pretty short for most astro institutions. All that said, I do understand and agree with @hamogu and @taldcroft 's broader point on the value of requiring "gaps" giving chances for new people and ideas to filter in. I'm also well aware that I am the most impacted by this in some sense as the longest-running CoCo member. And certainly the point of
weighs very much on my mind, and is the main reason why I am not planning to re-run when my term is up next. Indeed my explicit "platform" in my candidate statement was "make sure nothing will break if I leave"! So with that in mind, I would like to suggest a significant but not humongous modification: instead of saying no consecutive terms, instead say no more than two consecutive terms. I.e., you can hold a spot for at most 6 years before you have to take at least a year off. I could also see an argument for making the gap two years instead of just one on that basis. My thinking there is that most long-term planning and conversations in Astropy tend to be on the 5-year horizon, not 10-year (but also not 2-year). So 6 years is enough time to both address my concern about strategy, and I think is long enough to be quite effective - e.g. a year or two learning how stuff works, and then 3-4 years actually doing it. Another option would be to extend the terms themselves to 5 or 6 years so and keep the only one consecutive term approach in this PR. I don't like that as much because I think 5 years is a long time to not have to check in with the voters... But I could be convinced if someone really likes that over the 2 3-year terms idea. Other twoI like them as @hamogu proposed! |
Usually, the community will elect Coco members who have been involved in astropy leadership in other ways before (roadmap, finance committee, coordination meetings, very involved maintainers, etc.), so the learning time is much shorter. I was on the Coco only for two years (less than a regular term of three year) and I feel that I meaningfully contributed that vast majority of that time and certainly did not spend two of those two years learning how it works - and feedback from members indicates that others had that impression, too. All that said, if we can build community consensus about a "two term max" but can't agree on "one term max", I can live with that, too. |
|
While astronomy itself is slow-moving, software is fast. 3 years is a lot of time for software, so personally, I am ok with one term max. Also this PR has conflict. |
|
I think one major factor in you being effective for a short term was because you came with extensive experience from being on a board of a different non-profit. We can't expect most CoCo members to have had that much prior experience. |
|
I think a single term is not a bad idea. Particularly for Ombudsperson ;-) |
|
Re: experience -- FWIW I wouldn't vote for someone who is totally inexperience in the first place. We are not a new project anymore. I don't think it is too much to ask that a candidate comes with experience already. Anyways, I think this should be wrapped up one way or another before or at the Coordination Meeting 2024: astropy/astropy-project#349 (comment) |
I want to suggest several changes to APE0. They touch different aspects of Astropy governance and should be voted on separately by the members.
However, for the purpose of a discussion, it's much easier ot read in one document, thus I've put it all in one PR for now. The changes are:
Coco: Only one person from each employer, unless...
I believe the original motivation for the requirement was to prevent any one employer to take over Astropy by stuffing the Coco with their staff. I think our experience has shown that this is trying to solve a problem that does not exist. Coco members act as individuals and not as representatives of their employer and the community will only vote for people they trust. On the other hand, large employers have very different centers, e.g. "a NASA employee" might be someone at a NASA center such as JPL or work thousands of miles away at NASA headquarters, so I don't see why we could not have two Coco members from the same employer. Then, there are centers where people might share an office but technically have separate employers (e.g. SAO/Harvard, or a faculty member on sabbatical at a different institution). Thus, this rule does not guarantee the diversity of the Coco - it's up to the members to vote in the right people.
Note that this change also removes the "unless it would be short of candidates otherwise" exception. While I initially suggested it, I now thinks it's a bad idea to have such an exception. Astropy is big enough that we can find candidates if we try. Having such an exception just reduces the motivation for the leadership to look to the right candidates and motivate them.
Term limits for Coco
Instead of a "only one per employer" rule, I suggest a limit of one consecutive term. This will guarantee that the membership regularly chooses new leaders and that no one (and not any one institution) can dominate Astropy for too long. I do think people can be re-elected after a while, but it is important to cycle in and out of power to prevent a situation where Astropy relies too much on any one individual and that person becomes so crucial to running Astropy that, should that person leave the Project or take a different career, the Astropy Project itself suffers.
This is equally about team building and growing our capabilities. One of the most effective ways to "be part of the project" and "be really involved" is to be part of a leadership group such as the Coco that regularly meets to discuss issues. The Astropy project as a whole can only profit from having more people involved in that way; and once involved as Coco members, that experience stays with the project after the end of their term. Former Coco members are available for re-election after some time period or to help and advice in other roles. The fact that Coco terms are already staggered under the current APE0 guarantees that there is continuity and sharing of experience.
returns officer for votes
Currently, we require the return officer for Coco election to be "non-voting". I suggest to remove this restriction. In practice, that means that we've always asked NumFOCUS staff to act as our returns officer and that is just additional complexity in organizing for little benefit. They don't have direct access to the list of email addresses for voting members, they don't know the timelines for APE0 by themselves, and they are not always available, e.g. we had to reschedule the 2023 Coco election because it happened too close in time to the NumFOCUS summit. So, in practice, we have to say "take this text and input it in this field, then press that button". On the other hand, there is nothing to gain from having the return officer be non-voting. The current APE0 does not specify that the returns officer is "external" or "neutral", only that they don't vote themselves, so it could be a project member, they just have to abstain from voting. As long as we use a secure voting system like helios where all voters get a receipt and can check the hash to see that the vote is counted correctly,it does not matter if the return officer is voting themselves or not; and if we use an insecure system (e.g. "just send a slack DM to the returns officer") then the returns officer could cheat weather or not they vote themselves.
Share Ombudspeople between projects
It is hard to find qualified people for the job of Ombudsperson. Most if us join Astropy to code and advance research, not to mange interpersonal conflicts. That also means that most project members don't have experience or training in this role and, fortunately, the number of serious incidents is low, so that there is not a lot of on-the-job training either. On the other hand, the stakes are high, so we do not want to fill the Ombudsposition lightly.
At the same time, I believe that this really should not be any one person, but a group of people who perform the Ombuds duties together. In that way, they can discuss amongst themselves and in confidentiality any ethics concern or Code of conduct violation. A discussion between several people will almost certainly lead to a more balanced view than a single opinion. It also provides a back-up should an issue arise with the Ombudsperson themselves. If there is a group, an issue could be reported to other members of that group and the person accused can recuse themselves.
So, how do we find a group of Ombudspeople? I suggest to join forces with other NumFOCUS sponsored or affiliated projects and form a joint group of ~5 projects where each project sends one representative and then the 5 of them together act as "Ombuds" for all projects. I have discussed this idea at the NumFOCUS level and several other projects are interested. However, there is chicken-and-egg problem here: Until such a group exists, nobody can change their rules to join it, and as long as no project sets up their rules to join it, it won't exist. Thus, I'm suggesting changes to APE0 to empower the Astropy Ombuds to start / join such a group.
Also see
https://groups.google.com/g/astropy-dev/c/d6ivOjaWl3s