Stuff we decided we need to look into for documentation during the summit (and derived tasks):
Location and tools
Where do we host the docs? We want to host static pages and are considering hosting the docs on Github, either as a GSoC or using an existing platform (like readthedocs or the GNOME tools)
If the Brainz sites are translated, we need the documentation to be translated too. We need to figure out the options to do this (and it's important to consider it when picking a way to host the docs).
Picard documentation is in static pages, but kind of out of date. A way is needed to keep it all current.
Documentation system for all Brainz
The documentation system we choose should be available to share between all Brainz, having a centralized source of docs and info for all projects.
Docs are not linked in particularly useful ways right now. It's very hard for people to find their way from a release to the specific docs and guidelines for releases, for example, unless they know where they are beforehand.
Streamlining docs and topics
Consistent documentation guidelines
GIFs are much better than static images at showing people what to do in guides - we should try to have more of them.
For specially complicated topics, we will want to offer a step by step video tutorial instead of or (ideally) in addition to a text + GIFs guide.
We should figure out what kind of things people have problems with and write specific how to guides for those when reasonable.
Musician’s guide to MusicBrainz
We should write specific guides for artists who only come to MB to add or improve their own info, but have no time or desire to learn about all the details of how MB works since they won't be using it often in the future.
Webservice doc improvements
Our current docs for the WS aren't particularly great, especially for examples, and someone who has worked with the WS quite a bit should improve them and make the most useful info more readily available.