Add RFC to discuss RustConf 2024 Steering Committee

[graciegregory]

This RFC was created to discuss and make decisions around an idea proposed by the Rust Foundation staff team to the Project Directors during our bi-weekly meeting.

We would like to see a RustConf 2024 steering committee be formed. This committee could be composed of ~5 volunteers from the Leadership Council and the Project Directors. This steering committee would represent the Project's priorities during the Foundation's RustConf 2024 planning process.

The idea for a steering committee was born out of this comment from @rylev in Zulip: https://rust-lang.zulipchat.com/#narrow/stream/335408-foundation/topic/RustConf.202024.20next.20steps/near/404046046. The staff team had questions resulting from this comment about where and how the Project would like to be involved beyond leading the program committee for RustConf.

Rendered

[traviscross]

@rustbot labels +I-council-nominated

Nominating this for discussion by the council.

[clarfonthey]

This should at least have a .md extension so it can be viewed in rich text more easily (the "rendered" link doesn't do so right now), and while normally the recommendation is to prefix the file with 0000- before filing, since an RFC has been filed and now has a number, it should probably be prefixed with 3549- instead.

[Turbo87]

disclaimer: posting as a Project member, not a Foundation employee :)

[Turbo87]

from within the Leadership Council and the Project Directors

it's probably useful if those people are involved too, but should the group be limited like this? it might limit people with prior conf organizing experience from participating and probably also increases the work load of the council members and project directors.

[jackh726]

I agree here. In my opinion, it would make sense to have 1-2 PDs, 1-2 council reps, and 0-2 others.

[rylev]

Taking a step back, the most important point is that the program committee reflect a cross cut of the Rust Project and the wider Rust community. We have a mechanism in the Project for reflecting "Project will" that does not require polling all members of the Project: the Council. Unfortunately, we don't have such a mechanism for the wider community, and it seems like it would be an extremely large amount of work in and of itself to attempt to determine such a mechanism.

With all of that said, I think this RFC should not layout who forms the Steering Committee but rather who selects the Steering Committee membership and what the criteria for that selection are. This allows for flexibility to pick Steering Committee members who fulfill the prescribed criteria without artificially limiting the pool of potential candidates.

Straw-man Proposal

My straw-man proposal would thus be the following:

Who selects the steering committee?

The Rust Project Leadership Council is responsible for choosing the steering committee based on the criteria below.

Criteria for the Committee as a whole

• 6-9 members total
• No more than 2 members may share the same affiliation (using the definition of affiliation used by the Council already)
• A simple majority must be Project members
• TODO: ideally we'd have some criteria for demographic diversity but putting such criteria into strict quantatative terms can be difficult.

Criteria for individual members

• Must have the time and energy to engage in the process
• Must not be currently under moderation team sanction
• Must have some qualification that speaks towards their knowledge of Rust and the Rust community including but not limited to Project membership, authorship of well known ecosystem crate(s), prominent Rust author/speaker/blogger/etc., organizer of another Rust conference, etc.

[Turbo87]

Suggested change

Although we have always intended for the Program Committee to remain independent (with management and facilitation provided by the Foundation), Ryan Levick commented that additional Project input throughout the planning process is desired. The staff team discussed this internally and decided that a steering committee would be the right vehicle to identify and drive the type of Rust Project input requested.

Although we have always intended for the Program Committee to remain independent (with management and facilitation provided by the Foundation), Ryan Levick commented that additional Project input throughout the planning process is also desired. The staff team discussed this internally and decided that a steering committee would be the right vehicle to identify and drive the type of Rust Project input requested.

[Turbo87]

a clear set of expectations about their preferred involvement in RustConf planning

it might be good to give a rough list of what areas of planning exist when organizing such a conference. that would make it a lot easier for the volunteer team to figure out in which areas they would like to be involved. the list would not need to be part of the RFC, but it would probably be good to have during the volunteering process, so that people know what they would sign up for. :)

[jackh726]

I do think it's useful to outline a bit about the different parts of the planning process and the (potential) role of the committee in those.

[jackh726]

Overall, I think it's a great idea to form a steering committee from the Project to collaborate with Foundation on RustConf planning. I think the RFC lacks details on the responsibilities and privileges of the committee, though. While I don't think all the details need to be decided in the RFC, I do think it's important to describe the nature of the collaboration.

Importantly, I think its crucial to touch on things like "if concerns over X or Y are brought up, how are those concerns handled" and "who has the final say on X or Y".

My thoughts here stem in large part because of the potential for the work presented at the conference to be in some ways "blessed" by the Foundation or Project - which, while in some ways a concern in the past, is even more of a concern now that the Foundation is leading the planning. I don't inherently disagree with the Foundation taking on the planning role of RustConf, but I do think this should be thought about and addressed, not only in this RFC, but also likely in other ways too.

[jackh726]

Probably just worth just saying "~5 Rust Project members as decided by the leadership council"

[jackh726]

and other groups

So, this brings up a point: what does the steering committee do? Are they privy to potential speakers, scheduling, etc. that might not be shared more publicly? Do they help make decisions on these, or are they only "advisory"?

I think it totally makes sense to have some things (e.g. UnConference planning) be more public with input from "anyone", while more private things like potential speakers would obviously not be.

[jackh726]

and received encouragement from the Project and Leadership Council to proceed in Q4

Pretty nitpicky, but the linked Zulip thread is basically all about the location of RustConf, rather than general thoughts on Foundation involvement in RustConf planning.

[jackh726]

Although we have always intended for the Program Committee to remain independent (with management and facilitation provided by the Foundation)

I'll elaborate a bit more on this later, but I think it would be useful to specify what the Program Committee is (who does it consist of - at least, foundation staff, people hired specifically for the role, etc - and what does it do). And how "independent" is it(how does to committee interact with the Foundation staff and board)?

[jackh726]

additional Project input

Again, I think elaborating a bit on what this input would look like, and how it is used would be helpful.

[jackh726]

The staff team discussed this internally and decided that a steering committee would be the right vehicle to identify and drive the type of Rust Project input requested.

Maybe replace this with a short list of motivating reasons why a committee is better than e.g. a Zulip thread or survey?

[jackh726]

This probably doesn't need to be included

[jackh726]

I do think it's useful to outline a bit about the different parts of the planning process and the (potential) role of the committee in those.

[jackh726]

Next, we can establish a practice of the Rust Foundation sharing timeline updates and next steps with the steering committee and field any questions or comments that might arise from these memos.

So, this sentence gives off the vibe to me that the committee is essentially a mini mailing list that gets periodic updates on conference planning, rather than collaborative involvement.

[jackh726]

The Foundation and steering committee can collaboratively identify practices around public communication of progress and advocacy efforts.

Public communication is good, but it would be good to elaborate a bit on what kind of communication could be helpful?

[jackh726]

Suggested change

	If the Leadership Council is in favor of this idea, we would like for the steering committee to be in place and active by the end of February 2024.
	The steering committee should be in place and active by the end of February 2024.

[jackh726]

Elaborating a bit on the upsides and downsides here would be good.

[jackh726]

Not sure if this fits

[Manishearth]

I've got a couple thoughts. I've filled the role of "liaison between the Project and the conference organizer" for RustConf for multiple years (some predating my appointment to the core team). Typically this was in the form of managing the content: collecting trainings, putting together a program committee, communicating with speakers, while Leah would handle the actual hard organizing work of booking stuff and making sure it all happens. I'd usually have one other person from the project helping me do this.

Firstly, I would say it's somewhat too late to initiate an RFC process for governing RustConf 2024. Due to timelines on things like event space booking typical advice is to start planning a conference a year out. January is fine for a conference in autumn, but we really should be moving soon, and my guess is that there are still some major decisions to be made like location.

I would rather suggest that something be set up quickly for 2024 and people start thinking about long term governance separately (the formal governance of RustConf has always been a big question mark, and has led to conflict in the past). I guess it's still fine to use the RFC process for 2024's committee, but we should be quick about it.

---

But also, I think 5 people from the council/directors is too much. These are all people with high context (which we want!), but also high investment already, you want people who really can focus on the conference when needed. Perhaps we have enough people who feel confident in doing so from the council, but I'm skeptical. Conference organizing is hard work and the deadlines can be brutal, even if you're not directly dealing with the "hard stuff" of on-the-ground organizing and focusing on content and flow.

The council was formed on a principle of strong liaising with subteams. I'd suggest we continue with that: have one or two people from the council be the core of this steering committee, who periodically check in with the council and directors to ensure they're doing the right thing (and to sometimes bubble back decisions). They can, then, include more people from the project (anywhere from the project) to be members of the steering committee¹, to help with decisionmaking and the actual work. The key is to get people who can actually dedicate time to this, rather than people who are already splitting their time a million ways.

Also, honestly, from a governance perspective, venn diagram overlaps between teams and subteams without an explicit liaison can lead to a lot of confusion since instead of a subteam having a decision that gets communicated back with context (and the parent team can potentially push back if they have new thoughts or otherwise disagree), you basically get the same decision being litigated twice in two contexts with the same arguments happening and everyone learning of things from the other team in bits and pieces.

Footnotes

1. While I've really enjoyed this work in the past, this is very much not me volunteering; I don't have that kind of time anymore. Happy to answer questions about how we've done things in the past if people are curious, and in general the Rust project has a fair number of people who have organized Rust conferences who can do the same. ↩

[ehuss]

Sorry for my ignorance, but I know next to nothing about RustConf or how conferences are organized. Some background and definitions might help. Some initial questions I had:

What exactly is the "Program Committee"? I'm guessing they decide on the list of speakers? How are they chosen? What is the relationship between them and this new "Steering Committee"?

What kinds of input would the Steering Committee be giving? Would they be helping with deciding the schedule, or other things? How would they be able to provide representative input that wasn't just their personal opinions?

[Manishearth]

What exactly is the "Program Committee"? I'm guessing they decide on the list of speakers? How are they chosen? What is the relationship between them and this new "Steering Committee"?

The program committee is the group that decides the actual program, or at least the bulk of the talks.

Typically for RustConf they are responsible for:

• Voting on talk proposals after the CFP opens
• Once the CFP closes, having a couple meetings to go through their votes and put together a program
• Separately, figuring out who to invite for keynotes and other invited talks
• (Sometimes) figuring out which trainings to have. This has been done differently in different years; sometimes trainings are a part of the CFP, sometimes the organizer reaches out to known trainers, etc. Trainings are ticketed separately and have a higher bar for quality.
• (Sometimes) working with the selected speakers, performing runthroughts, etc. Often just the Program Chair, the head of the PC, does this.

I can't speak to the intent of this RFC for certain, but from experience I would guess that the steering committee will likely be the people who select the program committee and also work with organizing staff to make wider decisions about the conference, like:

• How many tracks / days should it have?
• Is there going to be an Unconf? Who runs it?
• What tack-on events are we planning on advertising? (and making sure that goes smoothly)
• Some part of the discussion around sponsors/etc.
• There's also just a hundred and one more minor decisions that will crop up as the conference nears.

They'd also likely be doing most community-facing communication about the conference: announcements, coordination with speakers (potentially delegatable to the PC), etc.

I would imagine there to be overlap between the steering committee and the program committee. But the way I see it is that the program committee is a very well-scoped job where you kind of know exactly what you're in for, whereas conference organizing is quite broad and Stuff Will Come Up.

[rylev]

Nit: these sections read more like a historical recounting of how the decision was made to make this RFC rather than an attempt to establish the Steering Committee. While some of this is good historical context, I think it would be better to try to write more from the perspective of "what/who/why is the steering committee" vs "this is the history up to this point".

[graciegregory]

Here is an updated version of the RFC that makes the Foundation's proposal clearer and follows the typical RFC format more closely. I have also incorporated many of the comments left into this draft.

[rylev]

The Foundation intends to maintain this tradition in 2024

Is there a reason to not commit more to this in the RFC? It seems like this would be an appropriate time to layout how the program committee and is formed and what rules they must abide by.

If there is a worry that the Program Committee won't take the feedback of the Staff into consideration (which does seem very important given that the Staff has the responsibility of orgnanizing conference logistics), why not make a Staff member a member of the steering committee?

[rylev]

The split between Project and wider community makes sense to me, but I'm unsure why we're being so prescriptive about who represents the Project. What is the advantage of this over 2 members who represent the Project as selected by the Leadership Council? Requiring that the members be Leadership Council members or Project Directors seems like a good way to artificially limit the pool of who can participate without much benefit.

---

We will lean on the Leadership Council as a whole to select this group based on a process of self-nomination initiated by the Foundation and promoted by the Leadership Council.

Nit: the way this is worded seems odd to me. I think we can phrase it much directly:

The Leadership Council is responsible for establishing the process by which the members of the Steering Committee are selected.

With that being said, are we sure we really want to leave it up to the Leadership Council to establish their own rules which are not subject to wider review? It might make sense for this RFC to lay out some base rules

[Turbo87]

how about this?

Suggested change

- Members: 4 total members from the Rust Project -- one leadership council member, one Project Director member, and two members from the wider Rust community. We feel that an even split between leadership members and community members makes sense as the former positions can provide context and Project authority while the latter can advocate for those who are not necessarily in a position of power within the Project. We will lean on the Leadership Council as a whole to select this group based on a process of self-nomination initiated by the Foundation and promoted by the Leadership Council.

- Members: 4 total members from the Rust Project -- e.g. one leadership council member, one Project Director member, and two members from the wider Rust community. The Leadership Council is responsible for establishing the process by which the members of the Steering Committee are selected.

[rylev]

That's fine with me - my only nit is that "wider Rust community" would indicate to me people who are explicitly not members of the Rust Project which sort of contradicts what you stated previously.

[rylev]

Nit: I doesn't strike me as normal for an RFC to talk about the desires of the author unless that information is relevant for justifying why the authors have chosen a certain way between tradeoffs or if the authors would like to throw in a "nice-to-have" loose requirement. For more foundational information, a more direct wording is preferred:

Suggested change

	- Scope: The Foundation would like the Steering Committee's involvement in the following areas:
	- Scope: The Steering Committee's involvement will be in the following areas:

[rylev]

with oversight and collaboration from the Rust Foundation

What are the limits to this oversight and collaboration. Is the Foundation allowed to disband the Steering Committee? Is the Steering Committee making proposals that the Foundation Staff ultimately has the right to give their approval or disapproval of?

[rylev]

If this RFC is purposefully limited just to the 2024 RustConf than I'm not sure an RFC is appropriate.

My initial impression of what this document would be was a document for establishing how RustConf would be run at a high-level. Such a document would clearly layout who has authority over which decisions. For example, I imagined that the RFC would have said something like:

Areas of Responsibility

The following groups are responsible for the following areas. More detail on the nature and limits of the responsibility can be found below:

• The Rust Foundation Staff: logistical operation of the event itself, coordinating sponsor relations, ...
• The Steering Committee: all programming aspects of the event (e.g., program committee, MC selection, format of talks, whether to include workshops, inclusion of an UnConf day(s) or other supplementary events, etc.)

[rylev]

Again, this is written too much from the author's perspective. Try to avoid an us/them framing and talk about all groups in the third person.

Suggested change

> - **UnConf Day:** The Foundation would be pleased to offer an UnConf Day again in 2024, but would lean on the Steering Committee to decide this. If they decide there should be an UnConf Day after RustConf, the Foundation would like the Steering Committee to provide us with a basic plan including content and identification of people from the Project we should be logistically coordinating with ("UnConf Day Organizers") to ensure proper supplies and resources are available to UnConf organizers and attendees. The Foundation would welcome the Steering Committee's participation in planning and running the UnConf alongside the Organizers they identify.

> - **UnConf Day:** The Steering Committee is in charge of deciding whether to include an Unconf style event in the programming. If they decide there should be an UnConf Day after RustConf, the Steering Committee is required to provide the Foundation with a basic plan including content and identification of people from the Project that should be involved in coordinating logistics.

[rylev]

The Foundation would also like to lean on the Steering Committee to understand if there are any other areas of the event they would like to be involved in on behalf of the Rust Project.

This seems wishy-washy in a way that is unhelpful. I think what you're trying to say is that the various groups should make a best effort to involve input from other groups in their areas of responsibility. I think we should state that.

All responsible groups should make an active effort to involve the input of other groups in their areas of responsibility. For example, the Foundation Staff should coordinate with the steering committee on event location before making their ultimate decision. Likewise, the Steering Committee should involve Foundation Staff in discussions on supplementary events even before they make a final decisions to minimize difficulties with logistics planning.

he Rust Foundation needs to operate independently on major event decisions (like co-located events and conference activities, tickets/access, general event experience, and sponsorship experience)

You've stated this mater of factly, but I'm not sure I agree that the Staff must be able to act independently in all of these areas in order to effectively organize RustConf. While logisical concerns like Sponsorship experience and tickets/access seem to fall squarely in the "operations" bucket (and thus appropriate for the Staff to be charged with executing on them more or less independently), "co-located events", "conference activities", and "general event experience" seem to be much more of a programming concern, and thus I would have imagined they would have falled squarely in the responsibility of the Steering Committee.

[rylev]

Suggested change

Since it was approved by the board and leadership council for the Rust Foundation to play a larger role in managing RustConf, we have intended to facilitate an UnConf Day and for the Program Committee to remain independent (with management and facilitation provided by the Foundation). We also understand that there may be additional expectations around Rust Project involvement and feel that clearer parameters around the Rust Project's role in RustConf would be helpful.

Since it was approved by the Rust Foundation Board and leadership council for the Rust Foundation to play a larger role in managing RustConf, we have intended to facilitate an UnConf Day and for the Program Committee to remain independent (with management and facilitation provided by the Foundation). We also understand that there may be additional expectations around Rust Project involvement and feel that clearer parameters around the Rust Project's role in RustConf would be helpful.

[rylev]

I don't think this is really necessary to say personally.

Suggested change

When the Rust Foundation staff team raised the idea of a Steering Committee to our Project Directors during our biweekly meeting, we were asked to outline our idea in an RFC.

[traviscross]

@rustbot labels -I-council-nominated +S-waiting-on-author

This seems to be waiting on action from the author and so is probably not ready for any council discussion, so let's unnominate this, as suggested by @ehuss.

Likely the council would wish to discuss this after those changes, so I'd recommend renominating it after they are made.

[graciegregory]

Thank you to everyone who participated in this discussion. It was really valuable, and I appreciate your patience with this Rust Project RFC newbie!

I have ultimately come to the realization that this RFC was not properly conceptualized and that the idea of a Rust Project steering committee for RustConf isn't really fit for purpose.

Much of what @Manishearth outlined in this comment hits the nail on the head as to how this kind of committee would unintentionally complicate existing Project processes and the general event planning process. Any new Project-specific RustConf process should be value-add and well thought out. I’ve realized that the RustConf steering committee idea would violate these principals.

I am closing the RFC. With that said, my team owes you all some updates on how we are thinking about the 2024 program committee specifically — documenting+sharing our intentions in this area is a major priority.

[graciegregory]

Please see this message in Zulip about the program committee process updates this year. Although we opted not to go with the steering committee approach, I appreciate the discussion in this RFC as it helped inform the shape of our plan. Thank you!