Now, when we have chosen default values for project fields, let's create a project. This can be done in two places, either by clicking the New project link on the project list (click on the Projects top menu item to get there) or by clicking on the link with the same name in the Administration | Projects. In both cases, you will get the following form:

Not much to explain here, is there? However, let's speak about the best practises for filling this form. That's, perhaps, the most important form in Redmine as by using it you actually create the face for 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 this project has been developed for.

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

Taking their implementation into account, I come to the conclusion that subprojects should be projects which are closely related to the main project but still independent. They should not be like repository branches as branches share the source code and subprojects don't (subproject can have their own repositories and do not share the parent ones). They should not be like project modules either (for example, 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 forums here). They can be related to the parent project versions (Redmine supports versions sharing with subprojects). They can share the work flow with the parent project (the roadmap of the parent project can include issues and versions from subprojects). Issues in subprojects can be related to issues in the parent project (the parent project issue list can include issues from subprojects). Different people can work on the parent project, its subprojects (members are not shared), and so on.

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

Redmine users often use project nesting for implementing project categories which are, unfortunately, missing in Redmine. While this helps I would recommend avoiding doing this. The side effect of such "categories" are empty projects with empty tabs and with grand total time spent for all subprojects, activity lists which include activities on subprojects, issues of all subprojects, and with some weird members (users having the Create subprojects permission which were added specially for creating subprojects) and so on.

Generally, the subprojects feature seems to be incomplete as often users face different limitations even when they use it the "right" way (for example, issue categories are not shared). So the decision to create a project as a subproject should be based on available features and not on the visual presentation (which is the main reason for 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 one project a subproject of another one.

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

The meaning of the Identifier field was also discussed in the previous topic. Here I would like to emphasize that the value of this field should be as easy-to-remember as possible, whilst at the same time being informative and similar to the project name. It will be used in project URLs (for example, http://redmine.packtpub.com/projects/mastering-redmine where mastering-redmine is the identifier) and, therefore, will be indexed by search engine bots (for this reason it is recommended to use dashes instead of underscores in the identifier). But also it can be used by users in Wikis to create cross-project Wiki links (see Chapter 7, Text Formatting).

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

The Public field was also discussed in the previous topic. Its value can be changed anytime so in most cases you will want to uncheck this option until the time your project is ready for going public.

Now we come to the modules again. Luckily, we already know what each module stands for so it will be easy to choose. The only thing you should take into account when choosing modules is that you should not enable them unless you plan to use them right away. Do not select modules which you are not sure you will use, it is better to enable them later, before using them. Thus, if you enable Wiki, be sure to add a Wiki page, if you enable News, be sure to write news (for example, about adding the project) and so on. Avoid users' disappointment when they come to an empty module page.

It's a little bit too early to discuss trackers and workflows as they will be reviewed later in this book. Here you see only tracker names, the associated workflows are what you actually need to consider. Also, which trackers you need, depends on the project (for example, I doubt you need the Chapter tracker). So the only thing, I recommend here, is to enable as few trackers as possible because high numbers of trackers may confuse your users. However, it is always a good idea to have trackers for all possible cases in your project. In this case default trackers are unlikely to be very useful and will need customizing. But all these issues will be discussed later in Chapter 8, Access Control and Workflow.