Hi! My name’s Karen Rustad and I’m a designer and web developer. I made the non-official rustacean mascot, t-shirts, and stickers a few months ago.
With the unveiling of the new Rust governance structure and subteams, I was wondering if there was any interest in a design/art/propaganda subteam. I imagine such a team would be responsible for the Rust logo and other design assets, the look and feel of the various Rust web properties, and would provide assistance producing other Rust resources–sample tech talk slides, language cheat sheets, and the like.
Is there a desire or need for this sort of help? Are there other designers in the community who’d be interested in joining such a team? While I’ve written a little Rust I haven’t been plugged into the community discussions thus far.
Huge +1 on this. Marketing is incredibly important for an Open Source project that wants to go further. I think rust did quite well in looking appealing so far, but there is a lot more that can be done.
I know I’ve been really wanting to get some frontend work done on Rustdoc’s output for a loooong time, but am terrible with design. Also, the site itself. So yes, huge +1 and would love to have you onboard.
I’m not sure how many other designy people exist here, but this is an interesting idea. I’d like to have folks like you on the team; we shouldn’t just focus on the technical nitty gritty of it all!
Perhaps this sort of stuff could be a part of the proposed community subteam if not its own subteam – the community subteam involves managing the community (“managing the community” is yet to be defined), and I imagine that a uniform look and feel will help the community identity. I don’t know though. Propaganda is sort of a part of community growth.
(Of course, this might mean that there are duties of the community team that individual members may not be interested in, but overall some members will be – I don’t think this to be a bad thing)
Indeed. I think that the ides is that the subteams are the ones setting the goals and making decisions in a certain area, but not everyone on the team has to be responsible for the entire area of the team, there will still be specialization.
I was also recently regretting that even though Playpen and Reddit got nice redesigns for 1.0, rust-lang.org itself still has a pretty bare-bones Bootstrap theme and could probably using some spiffing up. I’m terrible in the design department myself, but I would definitely encourage some work to make the web presence nicer.
When I was redesigning the reddit CSS I was lamenting that there didn’t exist a standardized color pallete for me to employ, as my own color selection skills are rather dismal. Something like this would be lovely.
Making design fall under the community team umbrella (once it exists) makes a lot of sense to me, at least at the current size of the project. I imagine much of the material that designers would be working with/trying to make pretty would be generated by the community team!
Either way, I suppose I could just try pull-requesting the website and working on a style guide like a total autocrat and see who provides feedback and/or objects. I just joined/started #rust-design on IRC, which seems like the first step.
The core competencies of a community team are really different from the core competencies of a design team. Ideally a design team would be able to draw in really great designers (web, print and identity), and those people are not the same kinds of people that necessarily want to be spending time on Hacker News or Reddit, speaking at conferences, running mentorship programs, and all of the other kinds of activities that it makes sense for a community team to do.
To say more, I really like the idea of getting non-coding professionals involved in various aspects of the Rust project. For example, I’ve worked with professional event managers before as well as professional designers in the context of open source projects, and it has the potential to be really awesome.
However, OSS projects have a tendency to treat these skills as being subordinate to more traditional OSS roles (such as programming and community/evangelism), rather than first-class responsibilities in their own right. The effect can be pretty subtle, but I have seen it turn away professionals from contributing their skills. This also has a negative effect on demographics that are underrepresented in programming but better represented in other fields (especially women).
If we created a design team, I would want that team to have the same first-class responsibility for their area that the language design or compiler teams have on theirs, which means not lumping it in together with other responsibilities.
FWIW the community team as currently proposed is already a sort of swiss army knife of nontechnical responsibilities anyway. I mentioned in the past that it should be okay for someone to be interested in only a few aspects of their subteam.
For example, the people who want to nurture the online community and write blog posts galore may not be the same ones looking to manage a swath of offline meetup groups. But yes, design does stand out here as something more different than the rest.
A separate design team could work too, really. I wasn’t sure if we were okay with tiny teams (this one would probably be tiny for now; I guess), but if that’s the case then we could have it separate.
I was also concerned about seeming to club all nontechnical things in one group, but @aldeka had a positive response so I didn’t worry too much.
My suggestion was really in case we didn’t want tiny teams for some reason.
To be fair, the mod team is also nontechnical, so I don’t see this as a risk.
I can see good reasons for either approach. If design is its own team, then you don’t obligate your designers to be on the list for handling meetup events, PR, and so forth. It would also suggest that look and feel are a high priority for the community, and have the other benefits you mention.
On the other hand, currently all teams (except moderation, for good reasons) are expected to have a core team member on them. Is there a current core team member interested in doing that? Otherwise elevating a designer (who doesn’t otherwise contribute to Rust) to the core team seems…I guess not completely outlandish, now that I think about it, but a big decision in any case.
It is also likely that Design will have very few people on it–one to three, I would guess?–which would make it a lot smaller than any of the other teams. And while not everything Community does will concern Design, much of what Design contributes will be related to Community’s projects. Are other teams likely to have joint projects a lot of the time? If so, then that’s fine, but if not, that’s another aberration from the current model.
I guess a lot of this comes down to what it is we think a team is for and how we expect them to operate in Rust. I don’t have a clear sense of that yet; I’m not sure if anyone does!
Indeed. Perhaps your idea of just trying to work on design in a sort of ad hoc way, is the right way to go for the time being:
I do think we should get a community team up and running in the near future, for a variety of other reasons, but the design piece seems like it should wait until we have more experience and a better sense for what we want to do.
Also, in general, please feel free to reach out to me or others on the core team in terms of coordinating design work, or any questions/concerns/needs. We can try to help keep things organized.
Oh, right. As a member; I should have noticed that
In that case I would personally prefer having design on the community subteam (as opposed to having no official design position whatsoever, or an independent design team). As you mentioned it would be a tiny team otherwise.
I’ve mentioned this elsewhere on this forum – I think we should make it explicit that community team members need work on everything the team works on. As the team forms the members can communicate with each other (and publicly) what they intend to focus on. Working outside of one’s focus is of course okay too.
Yes. Lots of RfCs and stuff have cross-cutting concerns. I’m not sure if there will be joint projects , since the teams don’t really have “projects” per se (rather, rfcs might be drafted by individual members the way stuff happens now). I believe that cross-cutting RfCs were brought up at some point during the original discussion on the governance structure.
I don’t think this needs to be a hard rule. The core team, though it handles nontechnical things not in the purview of the subteams, is a technical team. The original governance model had the mod team “special” to avoid conflicts of interest, but I think this specialness can be extended to some or all nontechnical teams. The subteam “leader” is a post that was pretty clearly designed for technical things. Supporting this could require a tweak to the original RfC, but not one that would warrant much discussion or debate I presume.
Rather, I would expect that the community/design/etc teams would have one or more particular core team members that they keep in communication with.
I don’t think anyone does . The responsibilities of subteams were pretty clear for technical stuff. They had to handle a defined technical process in a defined technical way. We didn’t really address how non-technical teams would work because we only had one example (for which we had a concrete design) and while “community team” had been brought up the idea wasn’t explored much.