Pre-RFC Discussion about franchising the official Rust conferences

community
1

In today's Community Team meeting, we talked about how conferences should work for the officially sanctioned RustCamp, RustCon, and RustConf conferences. While everyone agrees we'd love to have official conferences around the world (like every month or so), the core team has limited time and budget to organize multiple expensive events globally. This has resulted in this year's official conference being organized in the US, which leaves out a large amount of our international community from attending.

One option we talked about is the possibility of more of a franchise model with these conferences in order to not have their organization bottlenecked on the core team's availability. The Rust Legal Policies suggest that there is a process to get permission to use these reserved names, but we haven't defined what this process is and what requirements would be imposed to use them. This unfortunately means that people like @skade who are ready and able to organize one of these events, but are unable to because there's no process for him to follow.

So let's start figuring out what our process should be. This thread hopefully will lead to a proper RFC that we can propose to the broader community so we can get rid of this ambiguity.

To start things out, @aturon said the core team has some initial requests for anyone using these conference names:

  • A consistent experience across all the officially branded conferences.
  • An equivalent level of quality.
  • Being on message
  • Control over the keynote
  • Consistent media and branding over the look of the conference

How should we meet these, and any future requirements? @skade and @carols10cents pointed us to some conferences that use a franchising model, like JSConf and Devopsdays. Perhaps we can use that to help frame our approach.

@aturon, @nikomatsakis and the rest of the core team:

  • What does being on message mean to you? I assume some basic rules are that the conference must actually be a general conference about Rust, and that the conference needs to follow the Rust Code of Conduct. Are there more requirements?
  • Does control over the keynote mean that the core team picks the keynote speaker, or just has veto over the speaker?
  • Does the core team own the imagery that are used at past and future conferences, and will they be usable by the franchisee?
5 Likes
2

The Rust Code of Conduct is aimed more towards online interactions, which leaves out many important details for in-person interactions (such as how to identify official representatives of the conference and local phone numbers). I would like to recommend instead that conferences adapt and adopt the Geek Feminism Conference Anti-harassment policy, which is what Rust Belt Rust and RustConf are doing, as well as what RustCamp has done in the past and what I have done with Steel City Ruby in the past.

5 Likes
3

I'd like to second that and mention the http://berlincodeofconduct.org/

4

Neither of these things are properly defined. I'm also opposed to full control over the keynote. Program planning is one of the most important parts of a conference and the keynote should fit the program.

1 Like
5

Neither of these things are properly defined.

I had at one point essentially the same comment and inadvertently left it out. Thanks for adding it back in :wink:

6

At the danger of rehashing things here, the core team could choose to pick people spending the time and raising the money through other channels. This, as you write, excludes many people from attending events blessed as "official".

I don't think the missing process is the problem, there. In the absence of a process, core could still decide to engage in free-form talks. The subject matter of a potential European RustConf event being run by the European community with core blessing, on it's individual time and monetary budget has not been discussed.

I don't think we can be non-ambiguous about this and anything beyond outlines (has to have a CoC, etc.) can't be practically enforced anyways. "Level of quality", "Being on message", etc. are extremely hard to define and need to be constantly adjusted.

I'd like to add that RubyConf for example is a name everyone can grab and has a very high marketing value. Also, RubyConf events tend to be very well produced, people don't want to make a joke of their community.

I also don't see that much value in most of these requests. Why should media and branding be all the same? That introduces sync effort and sync effort is draining. We barely even manage to sync on names across the pond. Each of the events will want to be different in style - maybe fitting the venue and similar.

I can agree with base rules and core values. A thing I'm completely missing is - for example - asking those conferences to take part in outreach and contact to outreach groups (which are extremely local).

Fundamentally, I believe, the whole issue is approached the wrong way. A much more interesting question to hack on is: how can we bring more events of a useful base quality to more places in the world fast, without spending wagons full of gold for budget? And how do we find people to cooperate with?

7

I don't think Ruby is doing the same thing that you are advocating for doing -- there is only one "RubyConf" per year, run by Ruby Central. Everything else is "namespaced"-- Golden Gate Ruby Conf, Ruby Conf Australia, Euruko (European Ruby Conf), etc. Core team, have you said no one may use the name "European Rust Conf"?

8

If you don't like and disagree with what the core team is proposing, why do you want an event that you run to be blessed as official anyway?

That is, what does your conference being "official" really mean to you?

9

So how come I spoke at two RubyConf (Argentina and Uruguay)?

Where's the difference between "RustConf Europe" and "European RustConf"?

10

The question is: what does official mean to the core team? I didn't introduce that term.

11

They are called Ruby Conf Argentina (rubyconfargentina.org) and Ruby Conf Uruguay, (rubyconfuruguay.org), respectively. They're not just "RubyConf". This seems "namespaced" to me, does the core team disagree?

12

So why is this so important to you then?

13

I think there is an underlying question here that hasn't been addressed directly: What is the role of the RustConf brand and name?

Many of us on the core team have been thinking of RustConf as the "official" event that represented the "voice of the core team", to the extent that a conference can do that. So basically the keynote would be kind of laying out what core team sees as big priorities for Rust, what are upcoming changes, etc. Think JavaOne or Apple WWDC or RailsConf or what have you. I think this is a pretty valuable thing to have, and it's something that is kind of squarely in the domain of the core team, since it is inherently a "whole project" concern.

These proposed guidelines I think reflect that idea, and hence they are operating under the assumption that, if you want to call your event RustConf, it's because you want it to sound like the "official" Rust conference, and therefore you would want the core team involved in the keynote etc. If you didn't want that, you would therefore want to select a different name, to make it clear that this is organized independently.

But perhaps the base assumption is flawed. Perhaps there should be no event at all which represents the "voice of the core team". In that case, guidelines and advice for running a RustConf becomes really just about the overall quality and other such criteria. That would simplify this discussion quite a bit! But I worry that this could well be a lost opportunity to have a clear event that people can look forward to which kind of "brings them up to date".

Now, I think that having a key event that lays out this vision can be achieved in many ways, and I don't know what is the best way yet. But keeping room for such an event is precisely why we wanted to be careful with the name RustConf. The idea was that this name could serve as a signal for the "flagship" event that year. I would definitely expect this though to move from place to place (and likely change organizers, too), though I agree that it hasn't moved too far this year.

So TL;DR I think we should settle what we want the name RustConf to even mean before we dive into specific criteria. :slight_smile:

14

Because it is used as a criterion by core and they seem to attach value to it. (I also see the value, I don't like to approach to handle it)

So, by that argument, RustConf Europe would not collide with this policy at all and I don't think @aturon would agree.

15

How is that even in slightest compatible with the spirit Code of Conduct? That would mean that the keynote speaker must be picked from the core team, which is not very diverse. In addition to that, that means that an RustConf event can only be planned if someone from core has time. Or, that person needs to be blessed by the core team... I cannot imagine that working in practice.

Pretty much that. Core cannot be everywhere and are not the preachers of Rust. This is and never was a single-person project where the founder of the project has a keynote slot forever. How about people that are heavily involved but don't want to work in project steering? Do Core members need to be good speakers so that the load of passing by all potential events of that category can be handled?

I'm very fine with keeping a close look for quality, but I don't think core involvement should be a must, but a can (a very appreciated one, I might add!)

Uhm. Well, "Rust Conference"? For people interested in Rust? Living the spirit of the Rust Community? :slight_smile:

16

I am actually not sure! It seems ok, but maybe not optimal. I think it depends a lot on the "flagship event" question that I raised.

One scenario that bothers me if we adopt "country-based" RustConf names like this and we wish to have this flagship conference idea is that, in practice, it seems like then that the flagship becomes RustConf. Moreover, because RustConf.EU is taking place in Europe and RustConf.Paraguay is taking place there and what have you, then... sort of by default RustConf will always take place in the US.

(Perhaps others can tell if this is de facto what happens with things like PyCon or RubyConf?)

On the other hand, if we had e.g. RustConf as the main event and RustFest as the defacto name for other events, then you might have RustFest.EU co-located with Rustconf one year. Regardless, people who know that RustConf is sort of the flagship event that year, wherever it happens.

17

In this case, why not name the US event RustConf US to make that clear? (by the way a thing core has stated multiple times they don't want to) :smiley:

All in all, all these sensitivities could have been discussed over the winter before the conference season with involvement of the people interested in outreach.

18

It's not possible to do this before we know that people wanted to call an event RustConf, and you were aware of the trademark policies and didn't bring it up then, either.

19

Yes, you're right. I think we underestimated how quickly things would be moving on the conference front, and thought we'd have more time to work this story out.

You're also right in your commentary elsewhere that this has been an area where the core team was making decisions essentially on its own, without much external consultation. We're working to change that.

I'll comment on the specifics on this thread later, but I want to say that the core team has been talking a lot about what's gone wrong here, and we plan to address some of these problems by pushing toward the same process that's served us so well for technical decisions: RFCs. That's why I suggested we settle the RustConf question, in particular, via an RFC. This should serve to make the issues more visible to everyone, give all stakeholders a chance to weigh in, and then allow for a clear decision based on the tradeoffs discussed.

I realize it's not great to be doing this work at this late juncture, in terms of the EU conf planning. But that's where we are, and I think the best way forward is working toward an RFC here, together.

I need to do some other work this morning, but I hope to jump in with my own thoughts on the topic very soon.

2 Likes
20

So, I feel like one of the key problems here is that different stakeholders are coming in with different, semi-unstated assumptions:

  • On the one hand, there's the assumption that we should have a (large) number of official Rust conferences, covering various geographies. There are a bunch of further questions here about ensuring quality, what level of consistency is desired, whether to coordinate on message, etc.

  • On the other hand, there's the assumption that once or twice a year, the core team would like to give an important, high-profile keynote articulating the vision for the next chapter of Rust. This is a central part of the role the core team plays in terms of project leadership, and we executed the first such talk during RustCamp. The core team reserves a small set of such platforms for spelling out its vision (beyond this, the main other one is the Rust blog).

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.

(This is basically the point @nikomatsakis was making, as well.)

I think a lot of the disconnect has been people coming at the RustConf question from these two very different standpoints. In particular, the core team was initially envisioning a single official RustConf that moves around year to year (or perhaps a couple, per large region), which would house the core team keynote. But that's in tension with having a large number of official events, at least if we also want those to go under the RustConf name.

Important note: the high-profile core team keynote here is not intended to be the only keynote, and as above, it's supposed to be a one-two times a year thing. So for this year's RustConf in Portland, we plan on having it as the opening keynote, and then have a closing keynote that will hopefully bring in some very different perspective.

Now, I'm not sure whether everyone agrees with both assumptions, but I want to talk about whether/how they can be made compatible. So let's assume for the moment that we as a group want both.

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".

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.

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.

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.

1 Like