Welcome, New Committers!We'd like formal permission to distribute your code contributions. To make this process easy, we'll accept an emailed copy of your signed CLA. For further instructions, see the Fedora Commons Licenses Page. Getting Started
How We Keep In TouchThe team keeps in touch on a day-to-day basis via the development list and Skype. We generally try to keep significant discussions on the list, but prefer Skype for higher-bandwidth discussions. We also have bi-weekly, virtual Committer Meetings where we share what we're working on as it relates to the FCRepo project. This also gives us a way to share what we're working on with interested members of the community (the meeting minutes are public). Generally, committers employed by Fedora Commons are present at these meetings, and committers from other organizations may attend as their time allows. What To Work OnWhile we collectively prefer the high-priority tracker items (as determined by the user community and committers) to be worked on first, all contributions are appreciated. Please only work on unclaimed items that exist in the FCREPO tracker in JIRA. If you have verified a pre-existing bug in the Community Support tracker, please move it to the FCREPO tracker before starting the work. If you have identified and verified a new issue, you may submit it directly to the FCREPO tracker. Claiming an IssueOnce you've found an issue to work on, simply assign yourself as the owner in JIRA. This lets everyone know that you plan to begin working on the issue soon. If you find that you cannot complete an issue, please remove yourself as the owner to give other developers an opportunity to work on it. Coding Guidelines
Working in a BranchIf you're a new committer, or you're working on a substantial body of code, you should create a branch to work on it. Here's a guide to branching in subversionif you're not already familiar. Branches should be created as fedora/branches/fcrepo-123, where "fcrepo-123 is the JIRA id of the issue you're working on. Sometimes it's convenient to work on multiple issues in a single development branch. In these cases, you should make sure you've claimed each issue in JIRA, and create a "Code Task" in JIRA that links to each issue via the "addresses" relationship. This helps us keep track of who is working on what, and where. When it's time to merge your branch down to trunk, you may request a review by another committer. Request a review via email, then assign them as the reviewer for the issue (or Code Task) in JIRA and click "Start Review". When the reviewer is finished, they'll let you know so you can merge your branch down to trunk. Committing to TrunkWhether you're merging down from a branch or making changes directly to the trunk, you should be reasonably certain that your change won't break existing code. One way to quickly check is to run "ant junit" prior to check-in. If you're paranoid, you may also run several of the system tests as described in the readme.txt in the root of the source tree. Soon after you commit a change to the trunk, a set of automated tests will begin running on our test server. You should get an email within an hour indicating whether the test succeeded or failed. If the tests failed, other developers will be notified via the codewatch list so that they know not to do a "svn update" until you have committed a fix. Closing an IssueOnce the relevant code has been committed and passes the automated tests, you can resolve the issue in JIRA. Prior to resolving an issue, double check to make sure the metadata is accurate in the tracker. |