First off, why document at all? The reasons are almost endless.
- Less Dependence on Individuals. A project (or parts of a project) might rely too heavily on the technical knowledge of an individual, which can result on the downfall of a project once the individual graduates. Documentation ensures the knowledge is spread across the team and for future members, and is not lost throughout the years.
- Central Source of Truth. Ensures everyone has a clear understanding of the projects goals, design, and implementations.
- Learning and Onboarding. Members undertaking new projects, or being introduced to SIPB, can refer to documentations to get up-to-speed on what we have been doing. There's less wasted time explaining every time from scratch how something, and – more importantly – new members gain important context that enables them to ask better, more informed questions.
- Maintenance. A big difference with projects you might do on a semester in 6.101/6.102/etc and projects you do in SIPB or industry, is that you now need to care more about how the project does in the long-run. A SIPB project lasts for years or decades, and hence documentation is important to keep the project evolving as times change.
- Enhance collaboration, encourage best practices, improve usability, save time, ...
Overall, having a robust documentation system allows SIPB to be more productive in all forms imaginable, making it easier to provide quality services to the MIT community and furthering the Goals of SIPB.
These are minimal guidelines to keep in mind while documenting all our SIPB