There is still one tab in the global settings menu (which can be found in Administration | Settings) that we have not discussed yet. Yes, it's the Projects tab. Let's check it out now:

A project in Redmine can be either public or private. A public project is visible to everyone, even to unregistered users (unless you restricted access for the whole Redmine by enabling the Authorization required option under the Authentication tab). Of course, access to some of the project pages can be still restricted but even if everything is restricted the public project will still be visible! It will just appear to be empty. A private project is the opposite, it is not seen to non-members whatever you do! You can let unregistered users and non-members see everything but, still, such projects won't be visible to them.

So the New projects are public by default option actually specifies the default value for the Public checkbox of the project form. This option should be checked only if all of your projects are to be public (just to save time by not requiring users to set it). Otherwise it can happen that a project, which was to be private, can be accidentally left public. Even if you want all of your projects to be public, you may still want to uncheck this option to avoid empty projects in the project list as users may need some time to put data into them. Later, when their projects will be ready for publication, they can make them public. You should consider this especially if you position your Redmine installation as a list of active and up-to-date software, so your users won't get confused when they see no data in a project.

The next option is why we have started this chapter with modules review. Now, I believe, you can easily determine what modules you need. But remember that here we select modules which are going to be enabled by default for new projects. Users will still be able to select modules, that you have not selected here, and deselect modules, that you have selected here here.

Each project in Redmine has a unique identifier, a short string with letters, digits, dashes, and underscores in it. The main goal of this identifier is to replace the numerical ID, which is used internally by something more readable and memorable.

For this reason, I'm not sure why one may need to check the next option. Perhaps, it was added for the cases when users did not care about identifiers readability. In other words, if you just don't want users to devise project identifiers and do not care about their memorability, you can set the Generate sequential project identifiers option. When this option is set, Redmine generates sequential identifiers for new projects. Thus, if the identifier of the previous project was redmine the next suggested identifier would be redminf (not very smart, is it?) and if the previous identifier was chapter-1 the next would be chapter-2.

For the Role given to a non-admin user who creates a project option, you should select a role which will be automatically assigned to the user who creates the project. This should be a role with project management permissions, of course. If you don't do this such users will get the first role from the role list (which can be seen in Administration | Roles and permissions), which can miss some important permissions. This way you can avoid confusion when users discover that some things are not available for them in their just created projects.