How do the teams working full time on a project onboard contributors who are doing it with their 20% time?
Naively, I imagine developers would get annoyed or bogged down having to skill up these contributors rather than viewing it as a “free hand”.
Naively, I imagine developers would get annoyed or bogged down having to skill up these contributors rather than viewing it as a “free hand”.
The problems of getting an existing employee up to speed with the codebase are a subset of what you need to do to get a new hire up and running. And so you really should have a decent story for this regardless.
And culturally, it's super-valuable to have a certain percentage of visitors, since it helps break down the silos, one commit at a time.
The counterpoints, of course, are that no team really wants to have to maintain a bunch of crap written by someone who's moved on after a quick stab at something, and it sorta sucks for the sustaining team if all the "rockstar feature requests" (as the GP put it so succinctly) are picked up by folks in their 20% time.
The former can be mitigated with a good model for managing incoming pull requests, in my experience. The latter is a tougher nut to crack.
Anecdotally I also think a lot of code was generally really well documented. There is some effort to document things for a general Googler audience (i.e. you should understand most of the documentation on any given page without having to read all the other docs).
All in all, once you have onboarded into the Google ecosystem, it's fairly painless to jump around the codebase.
- grpc-go and gopls had great "Contributors welcome" issues set up. For both of them, I had to email/chat various people for help getting used to the code, but everyone was extremely pleasant and helpful (and happy to help). - Drive treated it like an internship, where a TL curated a set of low-priority issues and I just went and chatted with folks when I had questions. Again, everyone was very helpful. - Other Go tools I've worked on have had really intuitive codebases, or were quite small, and have been easy to dive right in. That's helpful too, though I do end up chatting with people a lot.
If I had to make a general statement I guess I would say: don't allow 20%ers if you don't have the time for an intern. Treat the 20% like an internship: free labour with a little bit of extra onboarding. It's ok to not have that time, but I think most people are usually happy and excited to provide that help! =)
Oh, actual tip: having a myproject-users@ / myproject-devs@ mailing list, or a #myproject-devs chat channel, goes a long way. Then, chatting and asking questions can be informal and ad-hoc.
TL:DR - nobody has to hand hold anybody onboarding 20% - just answer basic questions and point to the right resource.