This page explains how to get involved and help with the FreeSWITCH documentation project.
This is a great opportunity for non-programmers to contribute to FreeSWITCH and ensure that FreeSWITCH has great documentation to match the great code base.
Join the Docs team mailing list http://lists.freeswitch.org/mailman/listinfo/freeswitch-docs
Do you know mod_callcenter inside-out? Have you tricked out the conference bridge to make it do neat, useful things? Are you a perl script wizard?
You can help update the documentation of FreeSWITCH by joining the Docs Team, especially if you are an expert at a particular module or application of FreeSWITCH.
Please watch this video, at least the first 30minutes, it will teach you the basics of Confluence (starting at minute 5:00 )
Your personal Confluence space is a place where you can publish your own pages and play around in a sandbox to see what Confluence can do.
We have moved the last pages from MediaWiki to Confluence. Now comes the task of formatting each page to Confluence specifications and moving it to an appropriate location in the Table of Contents. Note that each page still stands independently regardless of its appearance in the Table of Contents pane, but widgets on the page such as "Child Pages" use their hierarchical relationship in the ToC to present the information properly.
First read carefully our Confluence guidelines : Confluence Wiki Standards and Guidelines
Many of the pages that have been moved still need reformatting; this is an easy way to get started with the FreeSWITCH documentation project.
How to help with formatting and layout? Well, some pages may still need to have code samples placed into the "code macro" (https://confluence.atlassian.com/display/DOC/Code+Block+Macro), long pages may need a proper 'Table of Contents' macro inserted near the top, and basically anything that you can think of to make the page look better.
Confluence should be an up-to-date document presenting best practices and functional descriptions of installing and maintaining FreeSWITCH. Make Confluence closer to a book narrative, remove programmatic stuff from outline. Confluence should always match the current version of code. When a branch is declared to be a release version, a snapshot of the Confluence space will be taken at the same time to document that version of the code as it existed at the time.
anthm wants the documentation to match the currently available software. The term "stable" is deprecated. A "stable" release only means that it is no longer being touched by developers, not that it is free of bugs, so there is nothing magical about that term. Keeping only one documentation knowledge base that matches current code base parallels the idea that JIRA tickets will only be considered if tested against the latest code base. This makes documentation easier because it evolves with the software and there's only one knowledge base to update.