[Blog post] Rustacean principles

I must admit I haven't read the whole thing, so please feel free to disregard. Sorry if this has already been addressed.

Meta-thought: principles need to rely on something measurable. It's too easy to convince oneself that you and the community around you is virtuous if the virtue is not really grounded in something you can see and do daily with your own eyes and hands. So ideally the principles will read less like a set of commandments and more like a how-to manual.

Not a critique of Niko's work, just an instinctive reaction to principles as a concept :slight_smile:


So— @matklad, I’m thinking about the concern that the "How to Rustacean" section is going to stress people out. I'm pretty sensitive to that. It's certainly not what I hope for, but I can imagine it having that effect, and in that case I think it would be a bad thing.

It seems clear that no actual, fallible person can embody all these behaviors all of the time. I know for sure that I don't. I see this as us trying to be clear about what we are striving for: a goal, not a minimum bar. I’m wondering how that can be better communicated and if you think that doing so might help, or does this seem like an inherent danger of having listed principles?

On a related note, one thing that I was thinking after reading your post was that we should have “be gentle with yourself” and “be gentle with others” as the first two principles.


One way to illustrate those characteristics as a goal or ideal is to attribute them to a fictional character. It could be presented something like, "What would Ferris do?"


That’s interesting!

It’s pretty important to me that the principles not be abstract. I was figuring that examples, stories, and quotes would be the best way to make that things concrete. I don’t know how much we’ll be able to find measurable quantities for everything.


On the meta I do think that even having principles creates an opportunity for there to be an explicit in group and out group. A yard stick that you can hold up and say "That's Not Rustacean" or "you're not Good Enough to contribute." While that can be used to curb undesired behaviour, I worry it can be used to exclude more than help.

Which is why it's surprising not to see Inclusivity (yes, with the paradox of tolerance caveat) as one of the core values of these principles. Imo that is one of the strongest values of the community, and it's not quite captured by "Be kind."

Principles are well and good for projects (read: tangible outcomes in the product), like the first section is aiming at, but I am less convinced of utility for communities (abstract and vague, about people rather than things), as does the second section. Maybe it's a bit redundant with the CoC?

I'd also like to see some scoping for those principles, too (not necessarily in the text). The preface is a start, but it's unclear where the principles should start and cease to apply. Are they about the Rust Language project, projects under the umbrella or purview of Rust teams and WGs, projects contributing to "the Rust experience" even outside of these (I don't recall names but there are a few contributor crates mentioned in The Book, for example, maybe pin-project, that kinda thing).

While not directly related, it could be worth to state or restate the mission statement for Rust, not just a foil to present the principles, but as an overarching "this is what we're all working towards, and these principles guide us on the journey" kinda thing. Perhaps every principle should hark back to it, eg "do X, because it works towards The Goal" but that feels a bit overdone.

The case studies make exemplify that every outcome is "a delicate balance", but that "not everything is required" should really be bold and upfront. At the same time, what threshold should there be? Is something that is average in every aspect but very positive in one valid?

More on the concrete side of things, there could also be examples of, say, "wrong moves." Maybe some examples of "red flags" that indicate something isn't quite right, and a design or interaction should be reconsidered.


What exactly is a "Rustacean" ? Is it someone who's involved in the rust-lang projects? Or is it someone's who's involved in the broader global rust community? To me it's the latter, but as I read your blog post it seems to read in the more narrow former case. That said, these "How To Rustacean" principles seem to be ones that we would like to foster in the wider global rust community, and I personally have enjoyed and benefitted from others embodying these principles as I wander through the rust world.


I agree with the idea that inclusivity is missing. I’m thinking a bit about it — one of the things I was trying to do in the first part is to create a kind of “cascade” of themes. The overall goal (“empowerment”), the feelings or qualities of a design that create that (“reliability, etc”) and mechanisms that engender those feelings (“type safety”).

The “How to Rustacean” section doesn’t have that structure, but I think maybe it should. I suspect that the overall goal is the same — empowerment (of people to contribute and shape Rust’s direction) — and “included” or “inclusive” is one of the ways that we create that result.

1 Like

I am also inclined towards the broader definition. A guide for how a wider community is expected to behave (should they choose to get involved) is important and helps to establish positive behaviors and good practices.

At the risk of seeming judgemental, no man is every-man and therefore what they contribute is necessarily limited by their experience. I guess that's why diverse and inclusive teams are so important.

1 Like

Yes, this is a good question, and I was deliberately somewhat ambiguous. It may be that it would be good to retool the page to be more narrowly tailed, but I’m not sure!

As you said, I think it would be great to have principles that “set a tone” for the broader community. I’m reminded of how Apple publishes Human Interface Guidelines and other things that help 3rd party app developers create things that feel more harmonized with the platform as a whole (caveat emptor about whether Apple follows its own guidelines etc). Something like the libs team’s Rust API Guidelines have a similar effect.

So I guess my hope is that I think we should create principles that are primarily driven by the Rust project’s needs, but that I would like to think that others may find inspiration in them. Even within the Rust project, to be honest, I see the role of this page not as something “proscriptive” (thou shalt do this), but more like something inspirational and aspirational.

The other thing I’ve pondered is that there’s such a continuum between “Rust user” and “Rust team member”. Is someone who posts on twitter a “Rust developer”? Who comments on internals? Who comments on an RFC thread? Who opens a PR? Who writes a blog post? I feel like any one of those things could be an interaction that ultimately leads to someone becoming a really influential part of Rust’s direction, and so I would like to think that we could create guidelines for how to engage with poeple that are useful to all of them, even if they become more and more relevant the deeper you get in the project.



(Heh, re-reading I see that you were suggesting more or less the same thing that I did. I think this is a good idea, yes.)

1 Like

This makes a lot of sense. I think the page could benefit from some explicit text to this effect. This also touches on the point you made later:

Agreed, this is interesting to think about. The broader rust community itself is a bit like a collective member of the rust team, since the core rust team depends on them for so much (bug reports, PRs, RFC comments, all the things you mentioned).

1 Like

One point that was raised that I’m thinking about:

  • The first set of principles are kind of a “contract” between Rust and its users (using Rust, you’ll get reliability, performant, etc)
  • The second set of principles is kind of a “contract” between Rust team members and contributors.

Perhaps it’s confusing to combine them in the same document, or at least they should be more clearly separated.

I was toying yesterday with restructuring the second section so that it had a similar “feel” to the first one:

I’m curious what people think of this direction. I kind of like it, but I have to experiment more with the right set of adjectives, and it may be that we can’t always find a single adjective to describe the thing we are going for.

1 Like

Makes sense

It seems to me that these two remarks don't make sense together. Personally I don't like it when the distinction between Rust team members and other ecosystem contributors gets emphasized, because I don't think team membership is, in the large, a very important characteristic in terms of contributing to our ecosystem. So in that sense, I feel that the very notion of "Rust team members empowering contributors by being inclusive" is not inclusive.

Which is not to say that the second section is not valuable, I just think the distinction you're aiming for is more between what is laid down in code vs what is in human interactions.

I agree with this too =) There is a tension there that I’m trying to unravel. Partly this gets at what is the role of a team member in the first place. I thought @m-ou-se made an interesting point in her RustConf talk about the primary role of teams being empowering contributors. I feel like we sometimes paint teams as being “the people who do the work” and we sometimes pain them as enabling. I tend to think it’s correct to think of the role of a team member being guiding, both in terms of setting direction but also in terms of helping mentor folks, provide reviews and feedback, etc. Of course many team members also contribute, but they are playing a different role in that case (e.g., when I write a PR, I am acting as a contributor, not a team member).


One possible context to unify these two is: "When you sign up for rust, this is what you get". Meaning you get all this stuff from the language (reliability, type safety, etc), and you get all this stuff from the community (inclusiveness, respectfulness, etc). This is probably a bit of a stretch, since someone "passively" using rust is not going to interact with the team in the same way a contributor would. But maybe there's something to be said about a "passive" user still might be an observer in some way that relates to the team/contributor interaction.

I'm not sure how strongly I believe this, but perhaps it's an interesting point for discussion

1 Like

Yeah. I think I combined them, in part, because I had in my mind:

If you want to contribute to Rust, you go to a Forge page, and there you find both guidelines on what we are trying to do and how to participate in the design process.

I also do feel that Rust’s community is an important part of the overall experience of using Rust, though not necessarily the open source team member part — I’m thinking of things like asking questions on users, stack overflow, twitter, etc, and the way that people react to those questions. That’s probably a sufficiently different context that it makes sense to think about separately, although I think (as we’ve said here…) it does kind of “draw on” the direction that we set within the open source org.

I somewhat dislike the notion of prioritizing "empowering contributors" because I feel like it can sometimes result in a sort of first come first serve basis, where contributors who have more time/availability can use up more of the team's effort than things that seem more deserving of a team's attention. (My go to example right now is Implement (most of) RFC 2930 by DrMeepster · Pull Request #81156 · rust-lang/rust · GitHub .)

The difference between team member role and contributor role is interesting, but I think for most of the points we'd also want contributors in, well, pretty much the entire Rust ecosystem, to be respectful (which shows up twice in your list), pragmatic and honest.

1 Like

This seems like the problem to address, though!

I am debating now, is the role of a team member to empower contributors, or is empowering contributors one of the techniques that a team member uses to help make Rust great? Perhaps the latter is the ultimate goal.

Going to think about it more.

I also got some feedback that the revised list (which centered things like “Inclusive”) was too vague to be actionable. I’m not sure if I agree, but I can see that.

One thing I do like, though, is that it puts the burden on what team members do for others — this sort of implies that it’s what you ought to do if you want to become a team member, but I think it feels better this way.

1 Like