Stay positive. You will get a lot of feedback and most of it will be negative. It takes many people a while to learn how to give useful feedback. Stay positive. Remember, this is a learning process for you and for the rest of your team.
Prepare the project, don’t prepare for the meeting. A peer review meeting is not a presentation. The way to get ready for it meeting is by improving your existing code and documentation. It isn’t by creating a complex presentation. Just focus on improving the features and the code itself.
Keep the group small. The first peer review meeting should be fewer than six people including you. The group can get larger later.
Watch out for groupthink. The loudest person will probably speak first. Don’t let them dominate the conversation. Solicit feedback from everyone in the group.
Don’t try to impress people with complexity. Choose something simple for your first peer review. Don’t try to impress people with something complicated; it will only make the peer review more difficult.
Start with an interface. It is much easier to review an interface rather than an implementation. Jim Blandy from the Subversion and Mozilla teams poses a simple questions, “Talking about interfaces is a proxy for talking about design. Is that something that [you] could imagine implementing?”
Once you have finished your first peer review meeting you must incorporate some of the feedback you got. Then call a second meeting. Get the process started and make it clear that this wasn’t a one-time event.