First very rough draft of the conferences CFP

Author: skade

text/0000-rust-project-conferences.md

@@ -0,0 +1,121 @@
+- Feature Name: rust-conferences
+- Start Date: 2016-05-05
+- RFC PR: (leave this empty)
+- Rust Issue: (leave this empty)
+
+# Summary
+[summary]: #summary
+
+This RFC formulates base rules for conferences that want to be official Rust project conferences. This RFCs clarifies the expectations the Rust project has towards conferences taking part in an officially curated conference cycle and the benefits both sides can expect from the relationship. These efforts should be to the mutual benefit of the project, the event and - above all - attendees.
+
+# Motivation
+[motivation]: #motivation
+
+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 conferences 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:
+* A representation of the Rust project at the conference
+* 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 conference organisers these offers.
+
+It is _not_ the intention of this RFC to standardize conferences, there will always be conferences focussed on specific topics or organised in a different fashion outside of this framework and the Rust project to support them to the extend possible.
+
+# Detailed design
+[design]: #detailed-design
+
+## Contact
+
+Events interested as being official Rust project events should apply through a mail to the community team or the core team.
+
+## Rust project involvement
+
+The Rust project needs to have some representation at the conference. This gives attendees direct access to people that can showcase recent developments and future goals appropriately. The Rust project should also be consulted about the general guiding theme of the conference.
+
+To ensure this, one keynote slot should be kept free for a speaker to be assigned by the Rust project. If the topic of the talk is not keynote material (e.g. a very detailed explanation of a technical aspect), a talk slot of similar size should be reserved. The Rust project has to make a proposal for the slot. The event is free to deny the talk when it feels the proposal does not match the overall quality of the rest of the event. The Rust project is then free to send in additional proposals.
+
+## Content
+
+Events on the official Rust project conference cycle should be 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.
+
+## Training
+
+Depending on the size of an event, on-site trainings or spaces for projects to provide training is desireable. These should come at an affortable price.
+
+Outreach workshops should be for free.
+
+## Policies
+
+Conferences that partner directly with the Rust project should have the following policies in place:
+
+* An actionable Code of Conduct, fit for a conference 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 conferences with ready-to-use material to ensure they don't need to work our things on their own all the time.
+
+## Outreach
+
+Events working closely with the Rust project should do ample 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.
+
+## Unified language
+
+To make sure the Rust project and the event in question can properly communicate and promote aspects of the conferences, a unified language is desierable. This is less 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 conferences 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.
+
+## Leeway for new events
+
+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.
+
+## Renewal
+
+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.
+
+## Benefits for events
+
+The Rust project has ample access to people experienced in running small to large international events...
+
+TODO: sum up how this makes it easier for the Rust project to promote everything out of these events.
+
+## Monetary support
+
+The Rust project cannot - at the moment - commit to monetary support. It will attempt that some costs directly 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.
+
+# Drawbacks
+[drawbacks]: #drawbacks
+
+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).
+
+# Alternatives
+[alternatives]: #alternatives
+
+There would still be no rules for what's necessary to become an official Rust conference.
+
+# Unresolved questions
+[unresolved]: #unresolved-questions
+
+What parts of the design are still TBD?
+
+# Acknowledegements
+
+The idea of expecting yearly improvements is taken from [RubyCentral's Community Grants](http://rubycentral.org/community/grant).
+
+The idea that outreach must come before and during CFP for fairness is from [eurucamp's CFP learnings](http://blog.eurucamp.org/2013/05/27/end-of-eurucamp-cfp/)
+
+Examples of accessibility statements can be found [here](http://2015.eurucamp.org/accessibility/), [here](http://2016.bathruby.uk/information/index.html).
+
+When it comes to staff procedures, Pycon's [staff procedures](https://us.pycon.org/2016/about/code-of-conduct/harassment-incidents-staff/) and [attendee procedures](https://us.pycon.org/2016/about/code-of-conduct/harassment-incidents/) are still the unbeaten reference