Member roles are used to differentiate users by declaring sets of permissions. In other words, the goal of the role is not just to hold the set of permissions but also, often, to make sure that some of the permissions are not granted to other roles. In fact, the role name should not just be the same as the real-life position, but also it should reflect granted permissions. This way, it will be easier to manage Redmine, to determine which role should be given to the user, and so on. Thus, access to project settings may be granted to "Project manager" or "Project administrator", editing permissions to "Moderator" or "Content editor", and so on. It's ok to assign several roles to a project member. So, you can name roles by their goals and assign different roles to a single user.

In such cases, it would be hard to keep all the role names and goals in mind while editing permissions using the previously described role page. Perhaps, for this reason, in practice, experienced Redmine administrators prefer the Permissions report page instead, as shown in the following screenshot:

As you can see, on the Permissions report page permissions are listed in columns, the titles of which are role names. The green check marks in column and row titles can be used to check or uncheck all the permissions in the column or row correspondingly. Like on the role editing page, the report page is divided into blocks by project modules, where each block can be collapsed or expanded by clicking on the plus or the minus icon to the left-hand side from the block title.

On this page, you can also clearly see that some permissions are not available for all types of users. To remind you what has been mentioned, Acquisition Editor, Project Coordinator, and Author roles are for project members, the Non member role is for registered users but not project members, and the Anonymous role is for not logged in users.