agenda: 1 March 2018, "officialness"

[ashleygwilliams]

the goal of this meeting is to allow for an open dialogue between community team members about the issue of "officialness" in the rust community. the deliverable from this meeting will be a proposal that @ashleygwilliams will present to the core team.

1. intro and summary
2. define the problem
   • categories?
     • events
     • groups
     • resources
     • other?
3. come up with solutions
4. collect and delegate action items

[ashleygwilliams]

this meeting happened! @Manishearth @bstrie and @ashleygwilliams were present.

we discussed several things which i will write up into an RFC on the rfcs repo:

defintions
- rust property: a group, event, communication channel, or resource
- official rust team: any team listed on the Rust org chart

1. historically this issue has caused some emotions! mostly around how unclear and poorly documented it is. we want to be sensitive to those situations and seek to prevent them in the future.

2. we identified a few definitions of official:

   • sponsored by funds that are managed by official Rust team(s)
   • the responsibility of members of official Rust team(s)
   • the responsibility of official Rust teams(s)

   the last two there are a subtle but critical difference. members of a team can organize/run/create something, but that does not mean that that thing is a responsibility of the team. this distinction is important in the heuristics we generated (see below).

3. we discussed several pros and cons that the term official has in the governance of an open source community:

   • PROS:
     • helps people discover and identify rust property
     • helps set people's expectations about the quality of a rust property
     • appropriately identifies the responsibility of an item as being an official rust team
   • CONS:
     • can (either intentionally or not) "claim" a space, stifling growth and diversity
     • lack of "officialness" can feel like the absence of a vote of confidence or worse, an insult
     • misunderstandings of what is eligible for funding from the Rust official teams

4. the problem spans across 4 categories of properties: groups, events, communication channels, and resources:

   • groups (e.g. a meetup group, or other affiliation group)
     The policy around groups should be that they are never deemed official in anyway. This is important for allowing the growth and expansion of social groups. The Rust team does not wish to accidentally allow an affinity space (language, country, or other denomination) to be claimed by a certain organization. As a result, none of these will be deemed official as we believe that officialness would detract from our desire for a growing, diverse, community.

   • events (e.g. a conference or workshop)
     The policy around events should be that no event is considered official unless it is the direct responsibility of a Rust team. If the event has members of a Rust team on it's organizing committee, this is still not grounds for officialness as it is the affiliation with the team not the members that the officialness is derived. These events can still be supported by funds managed by an official Rust team and advertised on official channels (twitter, website).

     The only events that currently fall under official Rust events are:
     - RustConf- responsibility of the Core team
     - RustBridge - responsibility of the RustBridge team, under the Community Team

   • communication channels (e.g. IRC, reddit, twitter, slack)
     The policy around communication channels should be that a communication channel is consider ed official if it is governed by the Rust Code of Conduct and has moderation under the guidance of the Rust Moderation team. The largest factor limited the officialness of communication channels is the bandwidth and willingness of the Moderation team to ensure that the experience on these channels align with the Rust Community Standards (NOTE: @Manishearth we might want to write this up in addition to the CoC).

     Current official communication channels:

     • (NOTE: make a list of these)

   • resources (books, tutorials, documentation)
     The policy around resources should be that a resource is considered official if it is the direct responsibility of a Rust team. If the resources has members of a Rust team as it's author or on it's organizing committee, this is still not grounds for officialness as it is the affiliation with the team not the members that the officialness is derived. These resources can still be supported by funds managed by an official Rust team and advertised on official channels (twitter, website).

     Current official resources:

     • The Book
     • (NOTE: make a list of these)

5. logo use:

   • need to have a separate meeting about this

[bstrie]

Seems like the heuristic is pretty clear: something is "official" if one of the teams (or a subteam) agrees to make its management a team priority. Official learning resources are determined by the docs team, official communication channels are determined by the moderation team, and official community events are determined by the community team (which is consistent with our current consensus that no event should be official). This also naturally extends to ways in which we've already been operating for years: e.g. the "official" third-party libraries in the nursery are all determined by the library team, our "officially-supported" platforms are all determined by the infra team, our "officially-supported" editors are determined by the dev tools team, etc. The only one that sort of sticks out is that RustConf, the "official" conference, is managed by the core team rather than by some sort of dedicated events team, though I guess it's justifiable if we consider RustConf first and foremost as a way for the core team to publicize project progress (in the same way that the core team writes all the "official" blog posts).

Regarding trademarks, IANAL but Mozilla's trademark policy (which covers the Rust logo) is pretty readable:

To summarize, provided that the use adheres to our trademark policy and visual guidelines, here are some of the things that you can do with the Mozilla Marks that do not require our permission:

• use the Mozilla Marks in marketing, and other publicity materials related to Mozilla or the relevant Mozilla product;
• distribute unchanged Mozilla product(s) (code + config) for each platform downloaded from www.mozilla.org as long as you distribute them without charge;
• describe your executables as "based on Mozilla technology", or "incorporating Mozilla source code;"
• link to Mozilla's website(s) by using the banners and buttons we provide to allow your visitors to download Firefox and Thunderbird;
• use Mozilla's word marks in describing and advertising your services or products relating to a Mozilla product, so long as you don't do anything that might mislead customers. For example, it's OK if your website says, "Internet browser customization services for Firefox available here;" and
• make t-shirts, desktop wallpaper, or baseball caps though only for yourself and your friends (meaning people from whom you don't receive anything of value in return).

It seems like we can be pretty lenient about letting people casually use the logo (in other words, that we don't have to aggressively enforce trademark usage), which means that we don't necessarily need to worry about the logo being equated with "officialness", as long as whatever the logo is attached to is referring to Rust and not a fork of Rust or something.

[carols10cents]

This is the current logo policy: https://www.rust-lang.org/en-US/legal.html

[sophiajt]

Officialness also seems to cover something related to moderation. When I was RFC'ing an official Slack channel a while back, that was a concern was if we had enough moderation folks to cover, and I think that there's a sense that something can't be official if we can't ensure the CoC for it.

edit: I see you list it under communication channels, but I think this is a more general thing as well.