Getting Started » History » Version 3
Michael Aherne, 2012-11-06 19:54
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 | 3 | Michael Aherne | You'll want to get a few users registered, so that you can assign them to the project. Note that by default, you must activate users manually. So after a user fills out the registration page, you must log in as Admin, navigate to Administration:Users, and set the Filter to All. Activate users as necessary. |
12 | 3 | Michael Aherne | |
13 | 3 | Michael Aherne | Once active, you can assign a user to a project. When you do this you can specify one or more _*roles*_ that they play. The default options for roles are: |
14 | 2 | Michael Aherne | * Manager |
15 | 2 | Michael Aherne | * Developer |
16 | 2 | Michael Aherne | * Reporter |
17 | 2 | Michael Aherne | |
18 | 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. |
19 | 2 | Michael Aherne | |
20 | 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. |
21 | 2 | Michael Aherne | |
22 | 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). |
23 | 2 | Michael Aherne | |
24 | 2 | Michael Aherne | h2. Workflows...You Can't Explain That! |
25 | 2 | Michael Aherne | |
26 | 2 | Michael Aherne | _*Workflows*_ are how Redmine tracks issues from creation through completion. The default Workflow contains the following states: |
27 | 2 | Michael Aherne | * New |
28 | 2 | Michael Aherne | * In Progress |
29 | 2 | Michael Aherne | * Resolved |
30 | 2 | Michael Aherne | * Feedback |
31 | 2 | Michael Aherne | * Closed |
32 | 2 | Michael Aherne | * Rejected |
33 | 2 | Michael Aherne | |
34 | 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. |
35 | 2 | Michael Aherne | |
36 | 2 | Michael Aherne | h3. Resolved vs Closed? |
37 | 2 | Michael Aherne | |
38 | 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/. |
39 | 2 | Michael Aherne | |
40 | 2 | Michael Aherne | h2. Step Three -- Create Issues |
41 | 2 | Michael Aherne | |
42 | 2 | Michael Aherne | TBD |
43 | 2 | Michael Aherne | |
44 | 2 | Michael Aherne | h2. Step Four -- Work on Issues |
45 | 2 | Michael Aherne | |
46 | 2 | Michael Aherne | TBD |
47 | 2 | Michael Aherne | |
48 | 2 | Michael Aherne | h2. Step Five -- Close Issues |
49 | 2 | Michael Aherne | |
50 | 2 | Michael Aherne | TBD |