Project Summary
Provide user-created readable, applicable documentation of procedures and software outside of official or non-existent documents.
I've run across a lot of great projects that do not provide great documentation. I feel that in order to have remarkable projects readable, understandable, and applicable documentation should be a standard. This process is often neglected, placed on the back-burner for when a project is complete.
This maybe acceptable for a in-house or closed source project that has yet to be released to the public. But, when you have a project that is being tested by individuals that are not directly included in the development process. Then at the very least, a summary of expected behavior, documentation of procedure and explanations for such should be provided.
Any documentation that I create here is designed to be a supplement to any existing documentation and should not be considered official or definitive. I started this project to clarify some other projects that I take part in.
Quick Reference
- Project Links:
-
Homepage
- Code Locations:
-
http://userguides.googlecode.com...
- Licenses:
- artistic_gpl
- Similar Projects:
-
- Managers:
- Become the first manager for userguides
No recognizable code
Ohloh computes statistics on FOSS projects by examining source code and commit history in source code management systems. This project has code locations but that location contains no recognizable source code for Ohloh to analyze.
Copyright
©
2013
Black Duck Software, Inc.
and its contributors, Some Rights Reserved. Unless otherwise marked, this work is licensed under a
Creative Commons Attribution 3.0 Unported License
. Ohloh
®
and the Ohloh logo are trademarks of
Black Duck Software, Inc.
in the United States and/or other jurisdictions. All other trademarks are the property of their respective holders.