Lessons from the Impl Period

[nikomatsakis]

I just published a blog post with the key lessons I took away from the impl period:

Lessons from the impl period

The TL;DR was as follows:

• Overall, the impl period worked great. Having structure to the year felt liberating and I think we should do more of it.
• We need to grow and restructure the compiler team around the idea of mentoring and inclusion. I think having more focused working groups will be a key part of that.
• We have work to do on making the compiler code base accessible, beginning with top-down documentation but also rustdoc.
• We need to develop skills and strategies for how to split tasks up.
• IRC isn’t great, but Gitter wasn’t either. The search for a better chat solution continues. =)

In a bit more detail:

• Worked well: establishing focus and structure to the year
• Worked well: newcomers developing key, important features
• Worked mostly well: smaller working groups
• Worked well: clear mentoring instructions
• Clear problem: lack of leadership bandwidth
• Clear problem: rustc documentation
• Clear problem: some tasks are hard to subdivide
• Mixed bag: gitter and dedicated chat rooms

I’d like to hear what all of you think.

[jmst]

Has there been any consideration in simply trying to have more paid developers working on Rust?

In particular, trying to persuade other large corporations to employ developers to work on generic Rust tasks or directly fund the Mozilla Rust division or individual members of it.

In exchange they could get some combination of brand visibility, committee seats and consulting/access to core developers (as well as indirect benefits like improved reputation and improved ability to hire top-notch Rust developers and have them also work on internal projects).

For example, Node seems to be successfully doing something like this, and there are probably other examples.

[konstin]

While I like the idea of more employed developers in rust, I don’t think giving influence to large corporations is a good idea. Those companies would naturally try to make rust “entreprise language” instead of striving for technical progress. A main example for the problems with entreprise software is java and its ecosystem.

[bascule]

I’d be a fan of more corporate backing for Rust, and think companies paying people to work on OSS is the primary OSS gets done.

It seems like Rust has gained a lot of large/noteworthy corporations using it, including Google, Apple, Baidu, and Dropbox. It sure would be nice if one or more of those companies could dedicate some employee time towards furthering Rust development.

[aidanhs]

Clear problem: lack of leadership bandwidth

A lesson that I personally learned was that a group that previously has little momentum/interest needs a bunch of effort to get the ball rolling to get to a place where contributors can jump in and get excited about what they’re doing - crater wasn’t realistically runnable locally until about two weeks into the impl period! Attempting to do this for two working groups was a mistake on my part and I only really made progress with one (this is at least partially because of it being a ‘spare time’ thing for me).

Worked well: newcomers developing key, important features

My comment on this relates to the ‘excitement’ thing. For crater I identified a number of beginner issues and higher impact issues…but the beginner issues were low impact and the high impact issues descriptions were a) a touch light on mentoring instruction and b) did a poor job of generating excitement to get involved (other than as an excuse to practice Rust). Part of this feels inherent - for NLL you can (reasonably!) feel some sense of glory that you’ve helped push something forward that people have been crying out for for years, whereas crater has always been a bit more hidden. But part of this is groundwork to raise awareness that should have been happening before the impl period - if you (I ) tell a moderately Rust-aware person about your working group and they go “oh huh I had no idea the Rust project did that” then maybe you (I) should be doing more work to fill people in. And I totally should, crater is a really cool concept! I do have thoughts along these lines that will materialise at some point.

All of this said, I’m very happy with where Crater ended up after the impl period - there’s lots more work to do, but I had some great contributions and was motivated to move the needle somewhat myself as well.

Has there been any consideration in simply trying to have more paid developers working on Rust?

In particular, trying to persuade other large corporations to employ developers to work on generic Rust tasks or directly fund the Mozilla Rust division or individual members of it.

In exchange they could get some combination of brand visibility, committee seats and consulting/access to core developers (as well as indirect benefits like improved reputation and improved ability to hire top-notch Rust developers and have them also work on internal projects).

I know the core team does think about things like this, partially because there’s a very similar important question about funding for Rust infra. There have been various Rust contracts from Mozilla being posted at points as well.

The “In exchange” part had me saying “yikes!” though - foisting someone onto a team because they’ve paid money feels like a…really bad idea. I think it’d also be in very poor taste to effectively “sell” access to voluntary contributors to your open source project. I would be interested in any links to details on how node though.

[kornel]

Lack of prompt responses to technical questions and quick PR reviews is a big turn-off indeed. Rustc is a quickly moving codebase, so if a PR falls through cracks it is going to bitrot.

I’ve written code to improve error messages, but before anybody answered my question about it it as become unmergeable and my work was wasted.

[mark-i-m]

I wanted to contribute but wasn’t able to this impl period. The two biggest reasons were:

1. rustc documentation (which you already mentioned). I eventually discovered the READMEs in librustc, which are a pretty good high-level overview. A good guide to what/where everything is would be really nice. In particular, what functionality of the compiler lives in what stage of the pipeline and where that is in the code. That seems like the fundamentals to be able to modify/add some feature, IMHO.

2. impl period landed right in the middle of the fall semester for me. My free time doesn’t come in the continuous chunks I would need to actually implement something. The summer would be a way better time of the year if that is at all feasible. Of course, I realize that it’s probably really hard to find a time that works for everyone, and I certainly hope to contribute during the non-impl period this summer, too Are there plans to have mentoring instructions on issue in non-impl periods?

---

@nikomatsakis Thanks for the blog post! A few comments:

We also lack documentation on common workflows. How do I build the compiler? How do I debug things and get debug logs? How do I run an individual test? Some of this exists, but not always in an easy-to-find place.

I think we really need to work on this. I’d like to form a working group and focus on it early this year – but more on that later. (If you’re interested in the idea of helping to document the compiler, though, please contact me, or stay tuned!)

I would be interested in helping with this if it’s something a novice can help with

Finally, I found that I personally still wound up doing a lot of mentoring over private messages. This is not ideal, because it doesn’t offer visibility to the rest of the group, and you can wind up repeating things, but – particularly when you’re discussing asynchronously – it’s often the most natural way to set things up.

Why not use the github thread? Or create a public channel/chat room for each issue?

IRC isn’t great, but Gitter wasn’t either. The search for a better chat solution continues. =)

Suggestion for chat: Slack

• allows uploading/linking files pretty easily
• supports preformatted text
• supports channels and DMs, which could be used for working groups, etc.
• easy and intuitive interface
• highly portable (windows, mac, linux, iphone, android)
• free
• has the first two pros of Gitter you mentioned (though not single sign on)

I have a few pretty good experiences with slack in the past on several projects/reading groups.

[matklad]

My main issue with all of IRC, Gitter and Slack is that they are synchronous-only media, and in soviet Russia timezones are different

Have anyone tried using discurs for real-time collaboration?

[djc]

The one time I looked at contributing to rustc I was looking for ways to actually print HIR and MIR, and couldn’t find them easily (had to ask on IRC, I think) and even then the required incantations were pretty obscure. In the past I found that being able to look at the different steps the compiler is doing and being able to debug from there is extremely helpful. In the toy compiler I worked on, I had some infrastructure where I could basically print the MIR before each of the passes, which was a great way to debug.

As for the funding questions, I think a great direction would be to try to setup a Rust grant program that (a) collects money from sponsors (basically ask all the friends of Rust), then (b) funds proposals coming from the Rust community. Much like the MOSS program, in fact, but with a different focus. I think this would be a great way to work around the OSS/funding problem.

[mark-i-m]

My main issue with all of IRC, Gitter and Slack is that they are synchronous-only media, and in soviet Russia timezones are different

Have anyone tried using discurs for real-time collaboration?

I have used Slack with groups/people in Toronto and India a bit (I’m in the USA)… It seemed to work ok. What do you mean by “synchronous only”?

[matklad]

On Gitter and IRC it’s almost impossible to catch up with discussion later. It may be easier with Slack though, because it supports threads to some degree.

Still, I suppose that discourse, which forces threads and promotes somewhat more thorough and rhoughtfull questions and responses, might be easier to use as as source of knowlage of past discussions.

[dhardy]

I want to say that I had a great experience with the impl period, but not quite what I expected. For the rand project there were so many ideas for refactor that most of the “impl” period was spent on design work, and in a way the implementation work has only just started.

What I will say for communication: one long thread on the forum does not work so well, nor does one (or even two) long threads on GitHub. In the end I started opening topical issues within my own fork of rand on GitHub, and that worked much better. Discussions need to be threaded and have a narrow topic if the information is ever going to be found and read later!

We did use Gitter a few times; it has its uses for informal discussion but having a summary post on GitHub appears to be the better way of informing people not in the discussion at the time.

[csoriano1618]

With the move in our organization to GitLab I was considering Gitter as a chat option instead of IRC. You mention it’s not better than IRC, do you have some short points explaining more about that?

[tommyip]

On Gitter and IRC it’s almost impossible to catch up with discussion later. It may be easier with Slack though, because it supports threads to some degree.

Zulip is great in this regard since it is built from the ground up to support channels+threads. Threads are “cheap” so we can simply open a new one for an issue, a question, a PR, etc.

[fabric-and-ink]

Thank you for writing this report!

My two cents regarding the communication topic: I prefer mailing lists. Is there a strong reason to not use one?

[HadrienG]

We use those a lot at my workplace, but from that experience they can become overwhelming when crowded (especially when you spend a bit of time away from your mailbox and must go through the huge backlog on return) and searching their archives isn’t very convenient.

I think they work best for infrequent announcements and complex discussions, but are not so well-suited to rapid-fire everyday chatter.

[KillTheMule]

Maybe it’s just me, but that just sounds like a forum would be the thing? You’d make subforums by topics as you want, you have conversations in the threads, and if you need one-on-one conversation that’s publically accessible, you can just do that in a thread where you talk (if the forum software is featurefull, I’d imagine you could have some kind of access management, if you don’t want others to join your conversation, but keep it readable). Everyone can just read what’s interesting, and it’s just a tad slower than real-time chat like IRC.

[Dylan-DPC]

If you have a lot of dedicated channels on slack, it makes it easier to follow conversations and avoid multiple conversations getting tangled. It does add complexity of policing and redirecting members to different channels. We have done this for a PHP framework which has around 20k members, and a lot of people call it a mess, but a lot of quality discussions take place as well.

It is better to have multiple ways so that people can choose the medium they are comfortable with as long as none of the mediums get diluted.

[spastorino]

Being one of the devs that helped during the impl period with Niko as a lead, I’d like to say a couple of things. First that this was amazing and Niko worked great with us.

Then on improve or try side of things I’d like to suggest trying something like what agile proposes in terms of collaboration and team work. In particular from agile/scrum, defining a clear vision of the work needed to be done, defining a sprint with a clear vision, having plannings and “daily” meetings (or with the frequency that works, there’s no need to be dogmatic here) and retrospectives where you can see what things need to be improved and get feedback quickly, would be great from my point of view. We at wyeworks.com use all this with great success since 2008. Also one of the main things that this could help with is on the team building side. Maybe working more as a team and less as individuals and trying to join forces to build a working thing and adapting to what our objectives are more in a collective way rather than taking invidual efforts. Never seen an OSS project doing something like this but … in case we have people dedicated, why not?. It could also be a good idea to have some Agile/Scrum master, somebody that wants to help on this regard, which could also decompress people like Niko from doing this kind of tasks or even from asking people how are they going with tasks. Never heard also of an “OSS” Agile coach/master, so it would be good and somebody may want to do something like this.

[vorner]

I didn’t join in the impl period in the end, mostly because it already required too much time to even be able to participate. I can find the time to post an occasional PR here and there (but with rustc, where making one is a lot of effort due to the large code base and complexity). But with a day job and several other hobbies, I just couldn’t participate in any daily meetings. I guess many more people would get disqualified as a result of that.

Further problem is this doesn’t work that well across time zones (it can be made to work, I’ve actually done that), but that seems workable if it is your main job, not a side hobby.