Google announced Google Summer of Code 2008. MoinMoin was participating and 6 students have been working with us this summer on these projects.

Students and their Mentors

• BastianBlank (mentored by ThomasWaldmann)

• FlorianKrupicka (mentored by ArminRonacher)

• MelitaMihaljevic (mentored by ReimarBauer)

• MoonByeongweon (mentored by AlexanderSchremmer)

• ChristopherDenter (mentored by JohannesBerg)

• PawelPacana (mentored by RadomirDopieralski)

Mentors and students should try to hang on on irc.freenode.net #moin and #moin-dev as much as possible. If you have a flat rate, just don't log out.

As you will have to submit code to Google, have a look at GoogleSoc2006 on how to generate the necessary patch file.

What we expect

• For the SOC project application: use our DeveloperApplicationTemplate

• CODE:

  • Clean (see CodingStyle).

  • Working (try to do small changes, step by step, returning to a working state as often as possible).
  • Tested (setup a local test wiki, write unit tests, ...).

  • Python 2.3 compatible (see MoinMoin.support.python_compatibility for some useful stuff)

• DOCS:
  • For developers (e.g. docstrings)
  • For users (where appropriate - e.g. as CHANGES entries or Help* wiki pages).
• Regular communication:
  • Stay online on #moin-dev.
  • Talk about your plans and what you do.
  • Ask for help if you are blocked.
• Regular work:

  • Keep an eye on the timeline.

  • Citing Google: "your main activity for the summer".
  • There must be at least 1 push to your public repo for each day you worked on your project:
    • Try to do clean commits, 1 commit per feature / per sub task.

    • Please update docs/CHANGES.yourname (see docs/CHANGES and please use exactly same formatting and style so it can later get merged).

    • If you have no code to commit, you should document what you worked on that day. Just condense your thoughts and/or conclusions into docs/CHANGES.yourname so everybody sees you were not idle.

  • Starting at 2008-06-25 there will be a weekly #moin-dev IRC meeting on wednesdays at 11:00-12:00 UTC (13:00 CEST, 20:00 Seoul) for these topics:
    • (Maybe prepare your text you want to tell in an editor so you can easily paste it to the channel)
    • student reporting about progress of that week (what's new, what works, what does not work, ...)
    • student reporting about what blocks him (if anything)
    • mentor and student defining next steps, what to do for unblocking
  • The last meeting will be on August 20. We would like every student report about the last stuff he did and which major things are still missing to make every student aware of general (non-)success. Afterwards the mentors will have an evaluation meeting.

What you can do before starting to code

• create and populate a homepage here on the wiki (see links in first sections)
• subscribe to the moin-user mailing list
• get familiar with the moin community, join our IRC channels
• read and follow the section above and linked pages / referenced files

• get familiar with mercurial (hg), see MoinDev/MercurialGuide

• get familiar with py.test, see http://codespeak.net/py/dist/test.html

• get familiar with moin usage - install it locally, play with it

• get familiar with moin code, checkout from http://hg.moinmo.in/moin/1.7

Some of that stuff is very useful and even nice to use, even in case your project does not get selected.

What you can do in the final days

• copy this to your homepage and use it as a checklist (in our final review of your stuff, we'll notice if you failed to process this list)

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

Submitting your code to google

If you want to create a patch file with just your code contributions, a command like this can do the trick:

hg export `hg log -M --template "#rev# " -k yourname -r SOC2008-START:SOC2008-END`

Maybe also submit the URL to your project repo to google, we will keep them for a while for review.

See also GoogleSoc2007 and GoogleSoc2006.