| 6 | | - Description of requirements |
| 7 | | - Functional description (design document) |
| 8 | | - Architecture (e.g. UML) |
| 9 | | - In-code documentation |
| 10 | | - API documentation |
| 11 | | - Bundled documents |
| 12 | | - Readme (brief project description) |
| 13 | | - Installation (setup and configuration) |
| 14 | | - Licence |
| 15 | | - Wiki page? |
| 16 | | - Issue tracking |
| 17 | | - Known issues |
| 18 | | - Potential enhancements |
| 19 | | - Milestones/priority! |
| | 6 | |
| | 7 | * Make sure that a '''description of the requirements''' of the developed software is available. This will often be part of the project description, but this description may not always be sufficiently descriptive. Ideally, '''functional and technical design documents''' are prepared and made available. |
| | 8 | * Provide a '''description of the architecture''' of the software, either in prose or by means of (a) UML diagram(s) |
| | 9 | * Provide good quality '''in-code documentation'''. Follow the conventions associated with the language, framework or platform that you are using (e.g. use [http://www.oracle.com/technetwork/articles/java/index-137868.html Javadoc] for Java rather than just inline comments). |
| | 10 | * If applicable, '''document your API''', especially if its public facing. There are tools that make this easy, such as [http://swagger.io/ Swagger] (for Java) |
| | 11 | * Bundle some basic documentation with your sources 'and' distribution packages. Include at least the following: |
| | 12 | *`README` (brief project description) |
| | 13 | * `INSTALL` (setup and configuration) |
| | 14 | * `LICENSE` (source code licencing information) |
| | 15 | * Make a '''wiki page''' in the [https://trac.clarin.eu CLARIN Trac] for the software project or make a section for it in another page if that is more appropriate. This page can serve as a hub to find sources and technical, administrative and other information. |
| | 16 | * Make use of an '''issue tracking system''', such as the [https://trac.clarin.eu CLARIN Trac] or the 'Issues' section of a !GitHub repository. Make separate tickets for all known issues as well as potential enhancements. Use milestones or priorities to indicate which issues should be addressed first or which features should be included in a single release. |
