A use case was presented. There is value in having show and tell of code and process review with a small group of people. Most people don’t have diagrams but have their processes in their heads and there is value in explaining the process to someone that is not on your team who has a different perspective. There are a lot of people in this group working in small teams on initial project stages with new ideas and smallish projects and it is hard to know how much to document. The use case presented is an example of a collection of scripts in a repository that people could pick up and use if the original engineer or developer is gone, and for other purposes. A good script repository organization is helpful for repurposing script for various purposes - like one script per dataset, a few hundred lines with nicely commented format. GitHub with good commit practices is important. You should work like one of your collaborators are the the future you. There is a need to share diagrams and descriptions of the data architectures and processes to non-developers, so network diagrams are useful (and can be done in a variety of ways like a link to a google draw document), but are always going to be out of date. But can be useful for keeping on track and also for making pretty and asking for funding and communicating with project managers who communicate with customers/community. Put it in GitHub. @kylerlaird, @brianwdavis, @chrowe