To-do
- test if your code works with python 2.3 - required for:
- gui editor update/fixing project
- ldap groups/wikidicts refactoring project
- wsgi refactoring project
- "nice to have" (not strictly required, because they will get integrated later) for the projects listed below
- test if your code works with python 2.4 - required for:
- storage refactoring project
- hg storage backend project
- dom formatter project
- regularly run the tests, your goal is 0 failing tests
- do practical/manual tests (you have lots of underlay pages you can click through, just USE your wiki regularly)
- identify and work on problems that essential features of your project still have (do not begin big/completely new stuff) - if you have a long todo still, set priorities
- review your code:
- at least once, completely read your code (including your docstrings/comments) line by line, word by word
- check your XXX / TODO
- remove old code you already replaced by new code, but you did not remove yet (old modules, stuff commented out, ...)
- fix typos, wrong grammar, etc.
- check docstrings if they completely describe the functionality, are clear about data types, params, return values
- add missing docstrings
- update docstrings that do not match the code/functionality any more
- don't describe trivial stuff (like: count += 1 # increment count), but if you are doing something rather non-obvious, there must be a comment
- each module is expected to have the standard header (see _template.py):
- 1 line short description - try to avoid just repeating what can be guessed by looking at module name
- some complete sentences with a long description, clearly telling what it does
- your copyright, GPL license reference
- check for sane names, don't have misleading names or names that don't tell
- check for PEP8 (the unit test helps with that, but doesn't find everything)
- at least once, completely read your code (including your docstrings/comments) line by line, word by word
- documentation
- developer level (docstrings, comments, specification, design documentation, guidelines, up-to-date TODO list, up-to-date KNOWN PROBLEMS list)
- admin level (how to setup/configure moin with the features you worked on, what other software do you require), usually on Help* wiki pages
- user level (how to use your features as a wiki user on the web), usually on Help* wiki pages
- collect the new Help* wiki pages below your project page in the wiki
a fragment for docs/CHANGES exactly formatted in the style/indentation you can see there (we'll use this when merging your stuff into main branch and just copy it to docs/CHANGES). please use docs/CHANGES.<projectname>