This question is too big to answer in detail, especially for this Quick Questions & Answers forum.
I would like to share just a few thoughts.
First and foremost, documentation writing should be a part of the same process as software development. And the first thing you need to use is the
Revision Control System, and certainly the same as the one used for the development, and documentation for the product and its source code should be in the same project of the Revision Control.
For the problem of selection of particular Revisions Control System, please see this discussion:
Revision control systems, which to choose from?[
^].
Please see my past answers:
Needs some words of wisedom to set up and/or use a server[
^],
Make an unclickable form[
^],
How can i structured to arrange source code when i create a new solution[
^].
As to the
Wiki, I think
this is a very good idea.
I did not try many, tried to find something extremely light weight, and all I tried did not work properly. So, I have quite positive experience only with one product, Wiki which was integrated with Trac. Please see:
http://en.wikipedia.org/wiki/Trac[
^],
http://trac.edgewall.org/[
^].
And, as Trac itself had very good integration with Subversion, I had a well integrated bundle which was easy to maintain. I did it all on Ubuntu server I set up specifically to have a development server (for international distributed team). Issue tracking provided by Trac is also a kind of documentation of special sort, but it was also very convenient way to write Wiki and make it bound with issue tracking and parts of projects, via cross references.
See also:
http://en.wikipedia.org/wiki/Subversion_%28software%29[
^],
http://subversion.apache.org/[
^],
http://en.wikipedia.org/wiki/Revision_control[
^],
http://en.wikipedia.org/wiki/Issue_tracking_system[
^].
And one more thing which might look very strange to many, and many will criticize me for that, but all my experience tells me about it. There is one important and robust Visual Studio feature: XML comments which documents the code and shown in Intellisense and while browsing of the referenced .NET assemblies. Here is my advice:
don't overdo it. These comments highly reduce readability of the source code, especially during development. Delay such documentation to the moment when the assembly is mostly used and almost not developed anymore. Comment this way only visible (public) types and members. For all other cases, use lapidary usual comments; make code more self-documenting.
It's possible to keep talking about documenting forever, but let's again remember this is the
Quick Questions & Answers forum. I think, for now it's enough.
—SA
Submit an article or tip