grow your wiki
I work in an IT department that controls and maintains the servers for a large variety of websites that are all owned by different 'parts' of the company. Some sites are apart of radio stations, others are tv stations, and other are magazines (and the rest are just online sources of information). Each of these types of sites owned by different business units, and although they operate in a similar way, their own sites have specific coding and knowledge requirements that others don't utilize.
A bucket is as it is, a container that holds things. Much like the layout of this wiki (wikipatterns.com) although the whole website/wiki is its own bucket, it has smaller buckets inside where information and knowledge resides, all in the form of personal spaces.
I utilize this method towards distributing buckets for different teams to store their information and knowledge, however ensure that permissions are set accordingly so that other business units/teams can view information in other buckets without tampering with it. Allowing each bucket to fully browse and search information from other buckets creates the beneficial result of not re-inventing the wheel when new coding practices or ideas are required. For example, one business unit may have solved the problem of incorporating the weather display code into their site, something another business unit is having trouble with.
This [EntryLevel] pattern strikes a balance between collaboration and protectionism in a organizational culture where there is still some mistrust. People can feel secure thier work will sustain over time without interference from groups or silo's in the organization they do not yet fully trust, but still permits cross-polination of ideas. With time, as trust and value is realized, the organization may transition to a more open and collaborative Permission Granted pattern, where editing and cross-silo collaboration is encouraged where and when deemed appropriate by the contributors themselves.
As mentioned above, the layout is quite simple as giving each business unit or team their own 'playground' to do whatever in. Others can look in from time to time, but most of the time people will stick to their own information. As time progresses, and as people become more reluctant to share information, and use this shared information, not only could the proper information be implemented the first time around in projects, but relationships between business units and teams can be created