[Blog post] Rustacean principles

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

I opened an issue on the repo (rustacean-princples#11) to this effect, but I thought I ought to post it here:

I am thinking of splitting up the principles, so that we have “Rust design principles” in one repository, and “Rust team principles” (need to find the right name) separately. As I wrote in the issue (and I guess earlier on this thread):

I initially thought they should be combined, because it seemed like a guide for people looking to help design Rust. You come to one place and you learn both what we are trying to achieve and sort of how to do the act of designing . But I've heard a lot of confusion about having them combined. It was pointed out to me that the audiences are different, in a way: the first set is kind of a contract between "Rust and its users". The second is a sort of a contract between "Rust team members and contributors".

The right name for the second set seems to depend a bit on how they are framed.


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.