When you have a set of changes to checkin, consider whether you need a CodeReview.
If you think a CodeReview would be valuable, ask for a volunteer reviewer from the pool of CoreDevelopers.
Depending on how important you think the code review is, you can checkin first and get the review after the fact or you could choose to wait for the review to be completed before checking in.
While a code review for every checkin is desirable, it's currently not practical for the FlexWiki project. This puts the burden for making the judgement call about the importantance of a CodeReview on the shoulders of the CoreDeveloper making the changes.
All bug fixes should have a corresponding unit test to check for regressions.
Post-build activities:
Document changes/new features on the wiki with a ChangeNote.
Be sure to add a comment indicating the build number where the item was addressed.
These are people who have experience with the FlexWiki code base and are trusted by the community to make sure that the changes they commit are safe and won't damage the integrity of the project
9/11/2007 2:13:31 PM - -74.12.234.30
These are people who have experience with the FlexWiki code base and are trusted by the community to make sure that the changes they commit are safe and won't damage the integrity of the project
9/11/2007 2:13:31 PM - -74.12.234.30
background information about FlexWiki
8/19/2007 10:36:06 AM - -66.78.124.101
These are people who have experience with the FlexWiki code base and are trusted by the community to make sure that the changes they commit are safe and won't damage the integrity of the project
9/11/2007 2:13:31 PM - -74.12.234.30
When a change is checked in to the the FlexWiki sources, a ChangeNote is often posted here on FlexWiki.com
9/11/2007 3:03:59 PM - -74.12.234.30
There are a number of mailing lists for people who are interested in FlexWiki.
