- Feature Name: NA
- Start Date: 2017-02-04
- RFC PR: (leave this empty)
- Rust Issue: (leave this empty)
This RFC formulates how the Rust project can support new and upcoming events in the Rust space. It tries to cover both offerings and the expectations. These efforts should be of mutual benefit of the project, the event and - above all - attendees.
Rust is in the lucky position of having thriving communities all around the globe. In the light of this, it makes sense to formulate better how the Rust project can support these communities, especially when they try to run larger events.
The Rust project intends to provide as many people as possible with knowledge and insights about what is happening in Rust. For this, it intends to cooperate with organisations all over the world to organise events where people can get authoriative knowledge. This means that certain baseline conditions must be met to make sure the can be efficiently promoted and attendees can have a common expectation about them. The motivation of this RFC is to clarify them.
Common baseline expectations are:
- The opportunity representation of the Rust project at the event
- Some alignment in theme of current developments in the Rust scene
- Being open to beginners and newcomers in content and action
- An actionable Code of Conduct and procedures
- An accessible environment with clear documentation
- Include offers for newcomers, for example workshops
The Rust teams intend to support the event organisers these offers.
It is not the intention of this RFC to standardise events, there will always be events focused on specific topics or organised in a different fashion outside of this framework and the Rust project to support them to the extend possible.
This RFC is aimed at events of medium to large sizes, where considerable costs and effort are involved.
This generally does not include meetups, but events that at least take a day.
Meetups are generally supported as usual, through promotion and the community team for questions. A larger process here would introduce much effort.
Events interested in getting help from the Rust project should send a mail to the community team or the core team.
Events that got in touch with us can use the Rust projects infrastructure. This currently includes advisory and monetary assistance, but can be expanded later on.
The Rust project has ample access to people experienced in running small meetups to large international events. They can help newcomers in getting their event up and running and can advise how to get most things organised smoothly.
The Rust project can also provide monetary support. This depends on the size and location of the event. The aim is to cover the risky parts of the setup, like venue setup fees. This assistance will most likely happen through a form of sponsorship.
The final, already existing, benefit is access to Rusts promotional network. This includes out Twitter account, but also our weekly newsletter.
The Rust project cannot - at the moment - commit to a budget for monetary support. It will attempt that some costs stemming from the wishes of the Rust project - especially speaker costs - are covered.
Monetary support can come either through the Rust project directly or through associated, local, funding organisations.
It is highly recommendable that the event is ran through some kind of limited liability body.
The Rust project wishes to have some representation at the event. This gives attendees direct access to people that can showcase recent developments and future goals appropriately.
To ensure this, both parties should talk early about a projects involvement at the event. This may include sending keynote speakers, normal speakers and masters of cermonies, or provide on-site assistance with topics important to the Rust project.
The Rust project will cover costs that the event cannot cover.
The Rust project generally trusts event organisers about curating their events. It should be noted, though, that the Rust project prefers to sponsor events that are accessible for attendees of all skill levels. Selecting a program with a range of difficulty levels is important. Talks should be marked by difficulty level in the relevant material.
This does not rule out involvement in specialised events.
Depending on the size of an event, on-site trainings or spaces for projects to provide training are desireable. These should come at an affortable price.
Outreach workshops should be for free.
Events that partner directly with the Rust project should have the following policies in place:
- An actionable Code of Conduct, fit for a event and in faith with the Rust Projects Code of Conduct.
- A clear accessiblity statement, giving infos about services in place and venue details, along with procedures to handle unforseen cases.
- A briefing for on-site staff on how to handle issues
- A briefing for attendees on who to contact for handling issues
The Rust project will assist in helping to pick these and give recommendations. It will provide interested events with ready-to-use material to ensure they don't need to work out things on their own all the time.
Events working closely with the Rust project should do early outreach towards underrepresented groups. The Rust project will assist in those efforts. It is important that this outreach happens before start of the submission phase, making sure that speaker diversity is reached through the normal submission process.
The Rust project will provide support in outreach efforts, but expects the event to actively approach relevant groups.
The Rust project will bring its good reputation as an approachable and friendly group to the table - the event should make sure not to tarnish it.
To make sure the Rust project and the event in question can properly communicate and promote aspects of the events, a unified language is desireable. This is not about control, but to avoid miscommunications. It makes sure the same feature of all events is called the same. For (an admittendly mild) example, all events should call their CFP "Call for Proposals". This also makes sure that frictionless outreach can be done without having too much explaining about vocabulary.
The Rust project will publish this wording as a living document.
Some leeway should be given to new events. Exceptions can be made - especially to content - for events that start out fresh and need to build reputation.
This is at the discretion of the Rust project.
Project partnerships should be renewed every year. In the interest of a growing community, this should be the moment to seek ways of improving over the last edition. The renewal should happen before the planning for a new event starts.
For events that happen more frequently then yearly, a different mode can be discussed.
There should be a written report of the conference after it happened. Feedback from conferences has helped us tremendoulsy before. In general, the report should not involve too much effort.
Currently, the name RustConf is used by the Rust project for a event run by Rust project directly. These events will be run regularly, with no fixed geographic location. The Rust core team will select the hosts of RustConf. (TODO: rust-core, please fill in if, or how, you want to be approached)
The name RustFest is currently held by the European Rust community and is intended for more relaxed events with a schedule that gives people time to meet each other. The RustFest name should only be used after approaching the current team. The RustFest team is open to applications.
Both brands are intended to be global.
Finally, events using the name Rust in their name should be aware of the Rust trademark policies.
People might feel put off by the rules and not want to be involved officially.
There's no documentation yet how events that don't meet those criteria will be featured (e.g. because they have very specialised content).
There would still be no guidelines under which events can contact the Rust team.
Should we have opinions on pricing?
Who would handle disagreements?
The idea of expecting yearly improvements is taken from RubyCentral's Community Grants.
The idea that outreach must come before and during CFP for fairness is from eurucamp's CFP learnings
Examples of accessibility statements can be found here, here and here
When it comes to staff procedures, Pycon's staff procedures and attendee procedures are still the unbeaten reference.