How to communicate institutional knowledge in a big physics collaboration? I am a graduate student in a large experimental physics collaboration.  Newcomers to the collaboration invariably complain about excessive use of jargon and insufficient documentation as barriers to their understanding and quick integration into the collaboration.  Of course, jargon is unavoidable in any technical pursuit, and one should not expect to find comprehensive, polished documentation of what is essentially a work-in-progress, but there must be some effective techniques to communicate this stuff to new students with a minimum of frustration?
What are some "best practices" in communicating institutional knowledge to new (graduate student and post-doc) members of a large scientific collaboration?
Alternatively, what is the best way to prepare students for interaction with a big collaboration?  Perhaps a few bits of advice at the beginning could help them become integrated and acquire institutional knowledge much more quickly(?).
 A: Although this is phrased as a management-type question, I have some experience with such a scenario when I was a summer student in CERN as an undergrad. My advisor met me once a day for an hour and most of that time was spent in debugging/checking the elementary simulations I was making in ROOT, which hardly left me with much time to know about all the physics jargon that is prominent there.
Sometimes the issue with professors and senior researches in labs is that they know too much and forget where they learnt the elementary stuff three decades ago. I think it is best to find someone with not too much of an age difference who's been there longer than you, and make them your confidante. People in your age group would tend to explain stuff to you in a much more accessible and informal way and guide you through the introductory literature. The learning curve is usually steep in the beginning, but you'll get past it. Everyone does. 
A: To orient oneself in a large group, now reaching the 3000 number, is formidable. Fortunately it is broken in smaller groups.
My advice for a new student would be to concentrate on the specific area of his/her task, and slowly, step by step, by asking questions of people on shift, searching on the net, get the necessary vocabulary for that task. A small notebook might help,for new jargon and concepts.
After about a month, expand the circle of "knowledge" to a similar group: if you have been working on the hadron calorimeter, find coffee company with electromagnetic calorimetry people, or the trigger group etc.
The data base  will be expanding step by step. By the end of the year reading the technical report will not be an enormous task.
A: Wiki - start with something informal and simple that you and fellow grad students/new-comers use then expand it. 
Combined with informal bag-lunch technical talks by people about their part - preferably about the equipement/software/experiment rather than the science it will do. 
Some massive all encompassing documentation project will either never get started or develop more jargon and convoluted understanding of it's own than it ever explains.
A: My suggestion would be to take the next new student and give them the task of compiling a list of the jargon ("institutional knowledge") that they come across, with definitions. Don't have them go out of their way to do so, since that would detract from their getting "real" work done, but have them make sure to jot down things as they come up (asking more senior members for definitions as necessary).
When the next new student joins, they inherit the list and do the same. In order to add new things, they'll have to learn what's already on the list, which will be handily compiled already (and which they can reference). After a few iterations, if implemented sufficiently across the collaboration, a complete list will exist and can, if necessary, by synthesized into one overarching list. If only subsections interact regularly, the decentralized lists may suffice.
A: i think the solution is to identify a single individual that will serve as a information manager that will ask people if they ought to create a new wiki or contribute/modify an existing one. Since that role only involves redirecting people to where they should contribute, should not be very time consuming
It will take a bit of time to reroute the information this way into a more coherent structure, but it will pay off
