Open ashleygwilliams opened 6 years ago
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
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.
we identified a few definitions of official:
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).
we discussed several pros and cons that the term official has in the governance of an open source community:
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:
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:
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:
logo use:
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.
This is the current logo policy: https://www.rust-lang.org/en-US/legal.html
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.
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.