This page is intended for students who are newcomers to Zope projects.
Trying to be as detailed as possible, so if you know something that's already described here, just skip over it.
Getting acquainted with the community
- Subscribe to the mailing lists:
- (find all here: http://mail.zope.org/mailman/listinfo)
- zope3-users
- zope-dev
- any other corresponding to your project like grok-dev, ZODB-dev
- listen here for wisdom, ask the appropriate questions when you need.
- make sure you "Reply to all" addressees of emails
- search through the archives for answers before asking on the list (google can be also your friend finding answers)
- be courteous at all times
- be specific (Cite data, references, and use links wherever possible when discussing technical things.)
- be patient (Don't expect an answer within minutes or hours; people often read their mailing-list messages once per day.)
Join the IRC Channel: #zope3-dev at irc.freenode.net Zope gurus and mentors usually hang out there. You can get there instant answers to your questions. Register your nick. In case something blocks your IRC client, try: http://www.mibbit.com
- hang out on the project IRC channels when you're working on the project
- take time to interact with people who are on the IRC channel
AVOID:
- saying things with all capital letters and excessive punctuation
- poor grammar (It makes it harder for other people to understand what you're trying to say.)
- being rude
- getting into heated arguments
People are spread all over the world, timezones could make communication hard. Here is a tool to coordinate times: http://www.timeanddate.com/worldclock/
Learning Zope
Dig yourself into the documentation that's there.
- See http://wiki.zope.org/zope3/Zope3Wiki tutorials section.
- When possible organize yourself a copy of Philipp's book (Web Component Development with Zope 3 http://worldcookery.com/).
- When not, you can read Stephan's book online. (it's a bit outdated but still very good for the basics) http://wiki.zope.org/zope3/Zope3Book
- Make sure you're not sidetracked with fancy things that your project is not about. There is a hell of a lot to learn, focus on what you need.
- Make your way from the bottom up. Learn first basic technologies like Interfaces, adapters, components.
- Might be a good time to start the development of a small application where you explore Zope and learn while doing development. In my view that helps a lot. Talk to your mentor, you should be able to figure out some nice little subject.
- Would be also a good idea to record your track while learning and doing learn-development. Use your blog or a wiki.
Progress reporting
For the actual rules the Zope Foundation has set for communication, see SummerOfCodeCommunication
Suggestions: Open up a blog. Write entries to this blog frequently. It's a good idea to do this each day you do some work. Enter some lines before you finish your day and switch off your PC. Make it a diary. Don't be lazy you'll forget by the end of the week what you did. On the other hand your mentor is not sitting right beside you so this will give him a good idea what you're doing.
Detailed schedule. You ought to have a google ID. Start using google calendar. Keep it up to date.
- Add all milestones of your project
- Add all your times when you'll not be reachable or won't work
Share this calendar with your mentor. Your mentor will share his with you.
Coding
Make sure you are familiar with SVN. You'll use that a lot.
Usually all development will be done at svn.zope.org. svn.zope.org requires that all committed code is licensed under ZPL. You'll have to sign a committer agreement before you'll get write access to the repo, but your mentor will help with that.
Some pointers
Get acquainted with doctests. http://docs.python.org/lib/module-doctest.html
Read the Zope repository rules at maintaining-software.txt
- watch out for your coding style
- commit-early/commit-often. OK, to be specific: if you're working on a branch at least daily. As with your blog, before you switch off. You can reuse svn comments in your blog and vice-versa.
- use quality commit messages
- the history in version control is frequently the best timeline log of what happened, why, and who did it.
AVOID:
- checking in multiple non-related changes in one big commit
- checking in changes that haven't been tested
Parts are taken from the Python expectations: http://wiki.python.org/moin/SummerOfCode/Expectations Read it too!