[cbb330]

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

[pcl]

I think it's incredibly healthy to encourage that sort of "visitor" committers in an enterprise codebase, for a couple of reasons.

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.

[singron]

Particularly at Google, programming languages, code styles, common libraries, and tools are incredibly similar between teams. There are really low barriers to jumping into someone else's codebase. It's not uncommon to review changes to your team's codebase from people you have never met (on average, maybe weekly?).

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.

[deklerk]

Others have answered this better than I, but I'll tell you what I've seen:

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

[amf12]

Well, Google values independence and so almost everyone is pretty independent. There is also consistency in the internal tools, libraries and infra used, so onboarding to the new team is just understanding their project. The 20% project that you work on is also usually a task that someone can work on independently and isn't hi-pri stuff which makes it pretty easy.

TL:DR - nobody has to hand hold anybody onboarding 20% - just answer basic questions and point to the right resource.

[lupire]

How does any open source project do it?

[teen]

you only hire 1-2 for your team, and it's a longer term commitment