Getting Started » History » Version 2

Michael Aherne, 2012-11-06 19:51

1 1 Michael Aherne
h1. Getting Started
2 1 Michael Aherne
3 2 Michael Aherne
This is a guide to the basics of Redmine, written from a new user's perspective.  We'll avoid the fancy stuff for now and just go over *_creating a project_*, _*working with issues*_ and _*the basic workflow*_.
4 2 Michael Aherne
5 2 Michael Aherne
h2. Step One -- Creating a project
6 2 Michael Aherne
7 2 Michael Aherne
Before you let loose your development team, you'll want to set up a project for them to work on.  This can be done as the Admin user (username and password are both "admin").  Click on _*Projects*_ (upper left), then on _*New Project*_ (upper right).  Fill in all the data.  A description of some of the fields can be found [[RedmineProjectSettings|here]]. The only box that might be confusing is the Project Identifier -- this is used internally by Redmine (for URLs and other things).
8 2 Michael Aherne
9 2 Michael Aherne
h2. Step Two -- Get some Users
10 2 Michael Aherne
11 2 Michael Aherne
You'll want to get a few users registered, so that you can assign them to the project.  When you assign someone to a project, you can specify one or more _*roles*_ that they play. The default options for roles are:
12 2 Michael Aherne
* Manager
13 2 Michael Aherne
* Developer
14 2 Michael Aherne
* Reporter
15 2 Michael Aherne
16 2 Michael Aherne
These roles affect what each user is allowed to do within each project.  It should be noted that assigning a role affects permissions in two different areas.  
17 2 Michael Aherne
18 2 Michael Aherne
First, a role will affect permissions across all aspects of a project.  For example, the Manager role will allow a user to create new (sub)projects, to manage the Forums, the Wiki, the Repository and anything else (in general) within a project.  By contrast, the Developer role will not be able to edit the Project or delete messages from the Forums.
19 2 Michael Aherne
20 2 Michael Aherne
Second, a role will affect permissions on the Workflow.  In general, a new Issue progresses through various states from *New* to *In Progress* to *Resolved* to *Closed*.  One of the key differences between Managers and Developers is that Managers are allowed to Reject issues, but Developers are not. (More on this below in the explanation of Workflow).
21 2 Michael Aherne
22 2 Michael Aherne
h2. Workflows...You Can't Explain That!
23 2 Michael Aherne
24 2 Michael Aherne
_*Workflows*_ are how Redmine tracks issues from creation through completion.  The default Workflow contains the following states:
25 2 Michael Aherne
* New
26 2 Michael Aherne
* In Progress
27 2 Michael Aherne
* Resolved
28 2 Michael Aherne
* Feedback
29 2 Michael Aherne
* Closed
30 2 Michael Aherne
* Rejected
31 2 Michael Aherne
32 2 Michael Aherne
By default, anyone who's logged in can create an issue (Bug or Feature), but only Managers can Reject them or Reopen a closed issue.
33 2 Michael Aherne
34 2 Michael Aherne
h3. Resolved vs Closed?
35 2 Michael Aherne
36 2 Michael Aherne
There's a lot of discussion on the internet about this, but the general consensus is that Resolved means a Developer thinks he's fixed the bug, and Closed means the original reporter or a Manager has signed off on it.  Many blogs talk about this -- such as http://journal.sifterapp.com/blog/2011/07/resolved-vs-closed/.
37 2 Michael Aherne
38 2 Michael Aherne
h2. Step Three -- Create Issues
39 2 Michael Aherne
40 2 Michael Aherne
TBD
41 2 Michael Aherne
42 2 Michael Aherne
h2. Step Four -- Work on Issues
43 2 Michael Aherne
44 2 Michael Aherne
TBD
45 2 Michael Aherne
46 2 Michael Aherne
h2. Step Five -- Close Issues
47 2 Michael Aherne
48 2 Michael Aherne
TBD