1. User-Interface

Note: Not all parts of the user interface may be visible. Features available depend on the settings per-project.

1.1. Tabs

Overview: This tab shows a summary of the current state of issues in the project, members assigned to the project, and summary notes which typically include tracking ticket numbers, locations of production, staging, and development sites, how to access certain things & contact information. The summary information is updated by the project managers.
Activity: This tab shows recent activity ordered by date. This is useful to see what has been done recently.
Roadmap: Shows the completion on each milestone. Issues are only "completed" if they are set to closed.
Issues: This is the main list of issues. By default it shows only "open" issues (that is, issues in any state but closed). However, you can sort and filter issues using the filters & options at the top of the page. Certain pre-set sorts are available from the menu on the right. If you right click on an issue (or select several and right-click), there is a context menu that allows to you perform updates more quickly.
New Issue: Create a new issue
Gantt: A gantt chart, which is an alternative way of visualizing progress towards milestones.
Calendar: Shows the being & due dates of issues and milestones.
News: News related to the project. Rarely used.
Documents: Uploaded documents. Rarely used.
Files: Uploaded files, can be assigned to specific milestones. Preferred over documents. (?)
Wiki: A collaborative wiki for development, user guides, and more. Upload files in the "Files" section then link to the wiki "Friendly Name":"/path/to/file.ext"
Repository: If your project is using source control for difference items, you can view the different repositories on files. If there are multiple repositories, they will be listed in the right-hand side bar.

2. Issues

Represent an item that must be accomplished. It could be an entire feature, or specific tasks. As much as possible, an issue should concern only one thing. It is preferable to have multiple distinct issues than larger monolithic issues.

2.1. Creating

Tracker

Which kind of issue is it? A brief explanation of each follows.

Bug: A problem with an existing feature or implementation.
Functionality: A feature that needs to be accomplished, eg. Build a newsletter
Task: Work that needs to be done, but is not a bug.
Question: A question that someone should answer
Support Request: Requests for support, training, or clarification of how things work

Subject

Enter a brief phrase for the issue

Description

Include as much information as possible. Which pages, how you found the problem, what exactly the problem is. Uploaded screenshots are helpful too.

Status

By default, they should be new. As described below.

Assignee

An issue should be assigned to a specific person. If you're unsure, assign to the project manager.

Category

The category of work that the issue falls into. If unsure, leave blank.

Target Version

The milestone where the issue that the issue should be finished for.

2.2. Issue Statuses

While most of the status are normally self-documenting, I've included a brief phrase about each status below.

New: An issue that has just been created. If you create an issue, this should be the status you use.
In Progress: Work is being done
Can't Reproduce: The bug or issue described cannot be recreated.
Need More Info: Something isn't clear
Needs Client Approval: An issue that hasn't been approved to happen by the client.
Needs Documentation: Documentation for this should be added to the wiki
Needs Testing: The client or product stakeholder should verify the fix applied works.
Needs Deployment: The fix or feature needs to be deployed (usually from a development or staging environment to a production site)
Postponed: Put off for some reason. This issue will remain open, but won't be looked at or worked on.
Rejected: This feature will not be done. It will not appear in a list of open issues.
Resolved: The issue is resolved. The product owner or stakeholder must close the issue when they are satisfied. Resolved issues continue to appear in the list of open issues.
Closed: Everything relating to this issue is done

Typical issue status workflow (where the issue doesn't need approval or already has it):

New -> In Progress -> Needs Documentation (optional) -> Needs Testing -> Needs Deployment (as needed)-> Resolved (by worker) -> Closed (by stakeholder)

3. External Resources

Text formatting on the Redmine wiki

Wiki

Page