Now that we have chosen the default values for some project fields, let's create a project. This can be done in two ways: using the New project link on the project list (click on the Projects top menu item to get there), or using the link with the same name on the Projects page of the Administration menu. The latter is available only for administrators, however. In both cases, you will get the following form:

Not much to explain here, right? But let's speak about the best practices for filling this form. It's perhaps the most important form in Redmine because it is where you actually create the face of your project.

The value of the Name field, which is required, should be as short as possible but still descriptive. Usually, you will want it to be identical to the project name. However, if your project is a part of another system, you may also want to prefix it with the name of that system, for example, Redmine SCM Creator, where SCM Creator is the project name and Redmine is the name of the system the project was created for.

The Description field should contain a short summary of the project. While this field is actually optional, it is highly recommended that you specify it, as it is going to be the first source of information about your project (as it is shown on the start page of the project, which will be reviewed soon, and in the project list). While writing the description, remember about the target audience. Thus, for customers, you should specify the main features of the project as well as its requirements. However, if your Redmine installation is used only by developers and other employees, there is no need to list its features. Instead, you can write about the location of the team, mention the technologies that are used, and so on.

The meaning of the Identifier field was discussed in the previous section. Here, I would like to emphasize that the value of this field should be as easy to remember as possible, while at the same time be informative and similar to the project name. This value is going to be used in all URLs of the project, and therefore, it will be indexed by search engines (for this reason, it is recommended that you use dashes instead of underscores here). But it can also be used by users to create cross-project links in the Wiki system (see Chapter 7, Text Formatting).

The Homepage field is optional and can be skipped safely. If you specify a value for it (which should start with http:// or https://), it will just be shown on the start page of the project.

The Public field was discussed in the previous section too. Its value can be changed anytime, so in most cases, you will want to disable this option until your project is ready to go public.

Each project in Redmine can have any number of subprojects, each subproject can have any number of its own subprojects, and so on down to any nesting level. But in what cases should subprojects be used?

Taking into account their implementation, I come to the conclusion that subprojects should be projects that are closely related to the main project but still independent. They should not be like repository branches, as branches share source code and subprojects don't. They should not be like project modules either (like Forums for Redmine), as the latter can't be used or distributed separately. (Subprojects can have their own files under the Files tab, so plugins for Redmine fit better than modules here.) They can be related to versions of the parent project (as Redmine can share versions with subprojects). They can share the workflow with the parent project (and the roadmap of the parent project can include issues and versions of subprojects). Issues in subprojects can be related to issues in the parent project (and the issue list of the parent project can include issues from subprojects). Different people can work on the parent project and on its subprojects (but members can be "inherited"—see the next option of this form). And so on.

These are not rules or official recommendations (and I'm not aware of any official recommendations, by the way). These are implementation limitations and features that you should consider while using subprojects. I just wanted to give you a general idea of what can be put into subprojects.

Redmine users often use this feature to implement project categories, which are unfortunately missing in Redmine. While this works, I would recommend that you avoid doing this. The side effect of such "categories" are empty projects with empty tabs, with a huge grand total time (it's about time tracking) that was spent on all subprojects, with activity lists (which include activities on subprojects), with issues of all subprojects, with some weird members (for example, users who have Create subprojects permission and were added especially for the purpose of creating subprojects), and so on.

Generally, the subprojects feature seems to be incomplete, as users often face different limitations, even when they use it in the right way (for example, issue categories are not shared). So, the decision to create a project as a subproject should be based on the available features and not the visual representation (which is the main reason behind using parent projects as categories).

But why did I write all this? All this is about the Subproject of option, which can be used to make the project a subproject of another one.

Subprojects can't share members of the parent project, but they can "inherit" them. That's what the Inherit members option was added for. When you enable it for a new project, all members of the parent project (if any) are copied to the new project. When you disable it for an existing project, all "inherited" members will be removed from the project.

Now, we come to the modules again. Luckily, we already know what each module does, so it should be easy to choose which modules to enabled for the project. The only thing that you should take into account while doing this is that you should not enable them unless you are going to use them right away. It is better to enable a project module later—right before using it. Thus, if you have enabled Wiki, be sure to add a Wiki page; if you've enabled News, be sure to write news (for example, about creating the project); and so on. Avoid users' disappointment when they reach an empty page of an unused module.

In the new project form, you should also choose trackers for your project. Here, you can see just their names, but the associated workflows are what you actually need to consider. However, it's a bit too early to discuss these things, as they are going to be reviewed later in this book (in Chapter 7, Access Control and Workflow). Also, which trackers you need depends on the project (for example, I doubt that you will need the Chapter tracker for your projects). So, the only thing that I can recommend right now is enabling as few trackers as possible, because a large number of trackers may confuse your users.