# Project Director Elections Retrospective 2025

*Once this has settled down, Tomas will prepare the relevant updates to the leadership-council docs*

Tomas: Please reply to these retrospective questions. I've added my observations below, feel free to write there as well!

## What went well?

*Write your answers here*

* Tomas: We stuck to the schedule
* Tomas: candidate statements

## What could have gone better?

*Write your answers here*

* Tomas: More candidates from more diverse backgrounds
* Tomas: Clarifying that the statements will be made public
* Tomas: Spelling the affiliation rules more clearly
* Tomas: Communicating with the leads directly
* Tomas: Getting more feedback on the nominees
* Tomas: Have a private (hackmd) document created for the meeting
* Tyler: Proximity to LC selections and several conferences meant more demands on people's attention and probably less engagement

## Where we got lucky?

*Write your answers here*

* 3 people were nominated in the last few days before the deadline

---

## Candidates

We had 5 candidates for 3 positions. For a while it seemed we won't even have enough but people stepped up in the end.

Tomas: There was one nominee added by accident due to the close proximity to the LC selection. The nominating person thought they were adding the name to the LC (rather than PD) document. We should be on the lookout for this, I discovered it while checking whether they're open to the role (a required part of the process). That shows the process as designed is working, but it is something to keep in mind.

### Diversity

The diversity pool seemed to be rather low.

Tomas: The high expectations of the LC (the PD candidate being a known quantity, familiar with the Project as a whole, have an a clear and stated agenda and proved they can push it forward) limit the pool of candidates in general. This means people need to work towards being in some sort of visible leadership or similar position before they're able to become a PD. That can exacerbate existing systems that may be keeping people with underrepresented characteristics or non-normative backgrounds out. Note, this is a generic statement, I don't know enough about the Project to know how much this is true. Rust definitely feels more welcoming than a lot of other places I've seen.

Tomas: The 2024 retrospective stated:

> We continue to struggle with the problem of being biased towards people we know.

This seems relevant to what I mentioned above.

Tomas: The 2023 retrospective seems to have been more successful about this:

https://hackmd.io/@rust-leadership-council/B19rbPz1p#Select-Candidates-Who-Fulfill-the-Outlined-Candidate-Criteria

Josh: I recall that some past candidates had an issue with real/legal name requirements, even though the foundation assured that this would only be used where absolutely required in legal filings. A recent [GNOME Foundation update](https://blogs.gnome.org/aday/2025/10/10/gnome-foundation-update-2025-10-10/) mentions changes in this regard for their membership, and I wonder if their reasoning might apply to our Board of Directors as well. It may not be the same though since members probably aren't listed in legal filings.

## Facilitating

We've managed to stick to the schedule we published. The meeting was set up on a Friday between the regular fortnightly Council meetings and the rest of the dates were counted back from that.

It is recommended to get the process (timeline, blog set up, etc.) started at least 2 months from the expected board meeting the new PDs will attend.

Tomas: It seems that having someone like me (outside of the Council so fewer conflicts of interests, working full-ish time on the Project) worked well -- I set things up and the LC could focus on what they needed: discuss the candidates, requirements and elect people. For as long as there's an active PM, this does sound like a perfect situation. If/when there isn't one, asking a Foundation staff might be useful (but should be done well ahead of the election meeting -- 3-4 months so they can make sure someone can be found and make the time).

## Spell out affiliation requirements explicitly

People weren't sure what exactly they were and the various requirements are listed in multiple docs

## Set up the election poll at least a week before the actual meeting

The Rust Foundation CEO (Bec / Dr. Rebecca Rumbul) sets it up

Tomas: Explicitly note that the poll doesn't allow changing the vote after it's been cast. The voting members should verify that they can load their poll page, but hold off from voting until the actual meeting.

## Nomination process

Some of the team leads were surprised that they were expected to nominate the candidates. We should make this clearer in the document and communication.

Tomas: In multiple places, it seemed that the wide ping did not garner the reception or understanding it should have. I think sending a short DM outlining the what's expected from each lead would produce better results (but it is more time-consuming).

Tyler: I agree with DMs (or at least mentions of specific people) being more effective. I don't love the framing that candidates are nominated *by* teams; that feels too "official" and like it should involve a team-wide decision making process. The framing I prefer is that team leads are responsible for collecting nominations from their team members.

## Voting

The candidates are being considered all at once. So when the facilitator provides the "most likely" option for the discussion, that's the 2-3 candidates we're electing all together. Rather than selecting them one after the other.

We'll use the +1/0/-1 table for a vibe check.

The meeting continues until there's full consensus on the candidates. Once there is, everyone votes while on the meeting (privately of course).

The facilitator reaches out to the person who set up the poll to verify everyone's voted and what the result was.

The facilitator shares that with the Council as well all the nominees individually right away.

The public announcements tend to happen later, but we should not keep people directly involved waiting. The Foundation puts out a post and the Project sends one as well (the two can be interlinked after).

## Candidate statements

These were great and helped provide more level playing field.

Tomas: We should make these a documented part of the process. The facilitator should make it explicit the statements are going to be published alongside the nominations (two people provided a statement thinking it was only going to be shared with the Council. I had to work with them to make sure we get something they're comfortable sharing -- best to be up-front about it next time)

## Pre-election feedback

Tomas: There was essentially no feedback given from anyone. The existing PDs shared feedback with the facilitator but that was all. This feedback was valuable and we should make it a point to reach out to the PDs for their thoughts.

Tomas: But we also need to proactively ask for feedback from others. Leads of the team, prospective colleagues (the remaining PDs, Council)? The broad "please provide feedback" calls didn't result in anything.

Tyler: It might be helpful to lean on team leads again here. If we structure it in two stages, candidate nomination and feedback collection, it would be easier because then the leads and share the list of candidates to prompt feedback. Also, a blurb about how important feedback is to a selection process (both positive and negative) can help.

## What to do when a Council member runs for the PD as well

Tomas: What we did this time: The team the Council member (TC) represents (Lang) pics a new representative (Tyler) for the election. The facilitator creates a group DM with everyone participating in the election.

Tomas: Because we had to exclude one LC (as they were a PD candidate) and include a non-LC stand-in, we couldn't use the Rust Leadership Council hackmd group for the document we used during the election meeting. Non-paid hackmd only allows a private doc being shared with three people and I found this out too late. It would be great if the Foundation could provide the Project with some paid accounts where this could be achieved. Or maybe we could use a different format. We worked around it by sharing the hackmd doc's URL privately and then closing it down (in case the URL leaked).

## Meeting

This time, the meeting lasted 2.5 hours (in contrast to the previous ones that seemed to take about 1.5h).

The meeting was scheduled on a Friday on an off-week between the regular LC meetings.

## Previous retrospectives:

https://hackmd.io/@rust-leadership-council/BysGbe3m1e
https://hackmd.io/@rust-leadership-council/B19rbPz1p