I've recently made a few significant changes to the FCREPO Tracker and thought it would be good to share them here. Some of this info will eventually work it's way into the Developer's Wiki, but for now it's a blog post.
Improvements
- Wider Access: The FCREPO Tracker now allows issues to be submitted from anyone in the community. Formerly, we experimented with having a dedicated tracker for community-submitted issues, but decided it'd be best to track everything in one place and improve the issue workflow instead (see below).
- Wider Scope: Fedora, GSearch, OAIProvider, and DirIngest are now listed as "Components" within the FCREPO tracker. These are all releasable products within the Fedora Repository Project. As part of this change, I made the JIRA "Versions" for the project product-specific (e.g. "GSearch 2.2"). This makes sense because each product has it's own release schedule.
- Improved Workflow: Issues now start in the new Received state, rather than the Open state. The distinction is that Open issues have been validated and determined by the committers to be in-scope. More specifics below.
Issue Lifecycle
Received
All new issues begin in this state. If it's clearly in scope for the project, it will be moved to "Open" by one of the committers. If it's not in scope or is a duplicate, etc, it will closed. If an issue remains in the recieved state for a longer than a couple weeks, it means we think it deserves more discussion before making a determination.
Open
Issues in this state are in scope for a future release. The target release may not have been determined yet. Generally higher-priority items will worked on first. The committers will take our best guess on the initial priority of issues, but the priority may be increased or decreased based on input we receive (votes, comments) from the community.
Issues that are not yet assigned can be worked on by anyone in the community. Attaching a good quality patch to an open issue is the best way to vote 
In Progress
This state means a developer is currently working on the issue. Small issues will usually bypass the review step and be Closed (and resolved as "Fixed") once the changes are committed to trunk and pass automated tests. Larger issues will be moved to the "In Review" state at the discretion of the developer.
In Review
The assignee has asked someone to take a look at the solution before closing the issue.
Reopened
The issue was thought to be resolved, but isn't.
Closed
The issue has been resolved. Possible resolutions are:
- Fixed
- Won't Fix (out of scope)
- Incomplete (not completely described)
- Cannot Reproduce (for Bugs)