+++
title = "Local Project Documentation Setup"
date = 2024-08-24T09:00:00Z
draft = false
summary="Learning Foundry VTT Module Development from the very start. In this session: setting up the local project dcumentation system."
categories = ['Technical', 'FoundryVTT', 'Foundry VTT for Module Developers']
prev = ['/post/fvtt-mod-dev-local-project-setup/']
+++

Continuing our Foundry VTT module development journey. Having set up some basic tooling on our project we now want to keep our project well documented.

{{< youtube _p_1ItoDo8U >}}

In this session we set up a system for creating a documentation website. We cover:

* Creating a 'starter' set of documentation'
* Create a system for transforming that source into a web site.
* Putting all this into our project version control system.

# Why go to all this trouble?

## For users...

Firstly, our users will likely want some documentation helping them to use the module.

It make sense to keep this alongside the module code to make it easier to keep the documentation in line with each release of the module. (There is little more annoying, as a user, than checking documentation to find it is only relevant to some version of the module that you are not, or worse cannot, use.)

## For Foundry administrators/game masters...

Adminstrators will appreciate it if we produce clear, concise release notes explaining changes we make to the module. This is especially true if the changes are likely to change their players' experience (or worse, break their current setup).

The objective here is to provide just enough infomation so that administators can make the decision about updating a module (and what work might be involved to adopt a more complex update).

## For developers...

Finally, it is nice for developers to have docmentation for our code. While I believe that code should be (so far as practicable) self-documenting there is certainly a need in anything but the most trivial module, for documentation that:

* orients the developer, letting them know the broad architecture and function of the module, and
* documents *why* certain design decisions where taken.

While some of this can, and should, be in comments in the code, there is a lot of useful information that belongs in external documentation.
