Pre-RFC Discussion about franchising the official Rust conferences

[wycats]

@aturon

it's something we can build JSConf-like infrastructure for, likely managed by the community team

I think the idea of a JSConf-like model is promising, but I think that logistical and event-planning skills are different (although sometimes overlapping, as in the case of skade) from community management skills, and I think we should have a separate Events (logistics and support for official and "franchised" events) subteam, rather than hosting it in the Community team.

[aturon]

@wycats

I think the idea of a JSConf-like model is promising, but I think that logistical and event-planning skills are different (although sometimes overlapping, as in the case of skade) from community management skills, and I think we should have a separate Events (logistics and support for official and "franchised" events) subteam, rather than hosting it in the Community team.

That makes a lot of sense to me. We have this tension on some of the other subteams, like the tools team, that bring together disparate concerns/projects/skillsets that might be better broken out (e.g. having a dedicated Cargo team).

For events in particular, if we want to really scale up to a JSConf-like model, having a dedicated team seems like a great way to do it.

The key point from my perspective is that the core team by no means wants a monopoly on running conferences -- in fact, we've been running our conferences with the help of Leah Silber and others, who are professionals dedicated to running open source events. We should try to take more advantage of existing "in house" expertise (like @skade's and @carols10cents's), as well as building up new expertise. Having a dedicated subteam seems like a great way to do that.

[nikomatsakis]

@skade

That would mean that the keynote speaker must be picked from the core team, which is not very diverse.

Sorry, I must not have communicated clearly. I did not mean that the core team would be the only people to speak at such an event. I meant that the core team would be closely involved in curating the message so that it emphasizes the themes we see being very important for the upcoming year and so forth. Often this might mean core team people speaking directly, but that is not a requirement.

[skade]

@wycats

I think we should have a separate Events (logistics and support for official and "franchised" events) subteam, rather than hosting it in the Community team.

I don't think so. There's much overlap between community management and event management and many in the current team do both. The community team can definitely manage efforts of slightly different nature, especially as both task severely suffer from lost messages, which a two-team split will introduce. The community team can handle that internally.

[skade]

@nikomatsakis

Sorry, I must not have communicated clearly. I did not mean that the core team would be the only people to speak at such an event. I meant that the core team would be closely involved in curating the message so that it emphasizes the themes we see being very important for the upcoming year and so forth. Often this might mean core team people speaking directly, but that is not a requirement.

Then, I totally don't understand why core makes the impression that this is so much work for them. And what happens if there's no speaker available for the topics that core finds important? Will the event be cancelled or loose the "official" marker?

Also, does it need to be a keynote? Not all good talks are good keynote talks. For example, a breakdown of MIR is something you might want to have somewhere, but it definitely isn't good for a keynote.

[skade]

I agree on the different opinions.

@aturon

In both cases, there's a notion of "official" conference involved, but they mean different things. And in both cases, people were imagining the single name "RustConf" designating the official events.

No, I don't think the name is as much of an issue as people believe it to be or understand me. It's core that communicated one name to be selected as "official".

The issue was that core wants to have rules around this, but isn't clear about the rules and tells people off for that reason. This means: even if some wanted to fulfill the rules, now, they cannot, because they are future rules.

I also fundamentally believe that the rule sketches outline above are impractical.

@aturon

One immediate constraint, in my mind, is that the core team keynote shouldn't always be in the same region; by having it move around, we show support for the worldwide Rust community. To make that happen, we'll need the infrastructure to have an acceptable venue in various regions. But there are a lot of ways we could achieve that.

For example, we could adopt a JSConf-style model where we have a large set of official RustConf events around the world. The core team keynote could then rotate through some of these events. There are some challenges around the mechanics here -- in particular, how do we make clear to the world what's going on here? But there are lots of possibilities. For example, perhaps each year, one or two of the RustConf events are labeled as "RustCamp" instead, repurporsing the name as a way of signaling "here's where the visionary keynote is going to be this year".

I think both of these are overthinking things. If we introduce a set of official events run by the project, both of your wants will follow. Obviously, conferences want people from the core team or shooting stars taking one of the keynote slots. Forming rules around that will lead to the weird. If you want to communicate "here's the most important keynote this year", communicate just that. Communicate, don't proxy.

@aturon

Or maybe such advertising isn't so important. Maybe we can just have a franchise model, and then announce each year where we'll have "the keynote", which in any case will also be recorded and distributed.

I believe it is important, it can just happen in many, many ways.

@aturon

As @erickt laid out, the core team is also concerned about overall quality (and potentially consistency) of RustConf events, if we adopt a "franchise" model. But that is not something that the core team needs to manage -- it's something we can build JSConf-like infrastructure for, likely managed by the community team. We'd just need to figure out what that infrastructure looks like.

How about yesterday? The infrastructure is already there: community-team@rust-lang.org /cc core-team@rust-lang.org

@aturon

Let me stop there, because I think the above issues are some of the central concerns we need to get on the same page with. If we can get everyone on board with a common set of goals, I'm confident we can work out a good process to achieve them, and that this doesn't involve the core team maintaining tight control of everything.

I think most of these concerns need to be solved with making attempts and amending. The current way is far too much focused on making things right on the first step and taking tiered approach.

Clarifying that the Rust project would like to bind events to certain expectations/wishes if they want to be officially endorsed by the project is fair and people are okay with that. But it's strictly necessary to have those rules before expressing that wish.