Lessons from the Impl Period

[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.

[spastorino]

@vorner, sorry because english is not my main language and maybe I expressed myself wrongly. I didn’t meant to propose an agile/scrum process as the ones you do during work days, where you work 40/50hs a week because that’s not doable. I agree with your concerns and think that are completely valid. Anyway, I don’t think that concerns mean that thinking about a more structured process like the ones described is not possible. Note how I’ve said “dailys” in quotes and added a “or with the frequency that works”. I’ve used the word daily because it’s the one used from scrum daily meetings but it’s possible to adapt this kind of stuff to something that works better in this situation. Could be weeklys or something, it all depends on the working team. And also about the timezones, things could be arranged in a way that works and even some stuff could be done in an async mode.

I propose more the spirit and the objectives of those agile/scrum ceremonies rather than the actual known implementation because it clearly has some pitfalls.

[nikomatsakis]

I’ve been reading the thread with interest, but have been traveling so haven’t had to write up much thoughts yet. Just wanted to add a link to this other thread that I just opened, which is specific to documenting the compiler:

"So you want to hack on the Rust compiler?", a plan for a book

In my previous post, I talked about the idea of drafting a “Rust Compiler Book”. I wanted to talk about how we might go about this. I think there are a few interesting questions to discuss: Where to host the book? How to describe and delegate the work? Where to host the book Currently, we have documentation scattered about in various places: The Forge, the source for which lives in this github repo markdown files in the codebase itself, typically (but not always) named README.md: for exa…

[vorner]

Ah, then sorry I misunderstood.

I’m still not sure about going too close to scrum. But I guess some inspiration could be borrowed.

If I think about what the scrum dailies do (make sure people know who works on what, who is blocked and if they need help) is to make sure everyone knows what everyone else does and if they are blocked on something and need help. Something like an aggregation of what is happening.

On the other hand, due to scattered team and people not always having time, some kind of asynchronous communication would be preferred.

How about a dashboard that’d show:

• What the current goal is
• The task each person is working on, with some little details (the last update time, when they expect to have more time to it, a guess of progress), and a green/yellow/red marker (green ‒ all ok, yellow ‒ I think I have little problems, but might solve them, red ‒ I’m stuck).
• The suggested tasks to pick from (subset of all the tasks in backlog, so people are not overloaded with info).

The question is, who would update it. Each person for their own status, but there must be a way to decide on the current goal and current tickets. People usually have to agree on those somehow, but without a meeting it is a bit hard.

That’s just an idea, though.

[retep998]

My big issue with the impl period was the period right before the impl period where a ton of RFCs were rammed through the gate. It made it exceptionally difficult for people to properly voice their opinions on all the RFCs they cared about. RFCs need to be dealt with at a very steady pace, without rushing anything through.

Issue: Limit on number of concurrent FCPs

[ekuber]

That is a shame :-/

On many cases, I would prefer you submit a PR marked as WIP, so that the discussion can happen around the code you’ve written. It’s also less likely to get lost in the shuffle.