The systems method is an approach to collaborative development and documentation. It divides desired results into systems.
Systems have defined borders and interfaces. Functionality can be owned only by one system. One person owns each system. System interfaces and architecture decisions are documented in the wiki.
Visit the project's wiki page for documentation of it's exisiting systems.
If a functionality is common across two systems (say player and enemy) than that functionality must be in its own system.
If modifying the system, read Architecture. If integrating with the system read Integration.
Any changes to architecture or interfaces should be documented by the system owner.
Wiki pages editable by any contributor is used to document system. Each system should have its own page with the following sections.
What functionality is in the system boundary.
How-to guides on common integration efforts.
By reading the architecture, one should be able to figure out how to modify the system. How to guides can clarify what is necessary to document in the architecture, but require time to maintain. Don't duplicate information.
Current architecture should be present tense, not future. Future tense can be used to clarify intent moving forwared.
Architecture captures the why of how the systems designed. Architectural decisions can be logged to show considered options and defend decision.
Dependencies change based on the architecture. For example, one architecture choice might rely on another systems functionaliy, whereas another arhitecutre choice builds its own copy. Kind of like make-buy decisions.
Documenting conventions in use allow for consistency throughout the system.
Not only to give credit but also provide points of contact for any missing details.