MoinMoin: MelitaMihaljevic/ToDo

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)
• 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>