faq.md

@@ -116,11 +116,11 @@ If you still want something similar to the old commit email hooks, then in your
 
 ## How to rewrite history
 
-As documented in https://gitlab.inria.fr/help/user/permissions project members with roles Developer or Master or Owner are allowed to force push to non protected branches. If you want to rewrite history of a protected branch, You need first to switch the branch to non-protected (only Master or Owner can do that), do the force-push, then revert the branch to protected.
+As documented in https://gitlab.inria.fr/help/user/permissions project members with roles Developer or Maintainer or Owner are allowed to force push to non protected branches. If you want to rewrite history of a protected branch, You need first to switch the branch to non-protected (only Maintainer or Owner can do that), do the force-push, then revert the branch to protected.
 
 ## How to add users of an INRIA ildap group (eg. team members) to a gitlab group
 
-Open a ticket, specifying the INRIA ildap group name, the gitlab group name, and the access level (GUEST, REPORTER, DEVELOPER, MASTER, OWNER) that you wish to give to added members. We will run a script which adds _existing gitlab users_ matching the ildap group members to the gitlab group. Be aware that inria members need to connect at least one time to gitlab for their account to be created.
+Open a ticket, specifying the INRIA ildap group name, the gitlab group name, and the access level (GUEST, REPORTER, DEVELOPER, MAINTAINER, OWNER) that you wish to give to added members. We will run a script which adds _existing gitlab users_ matching the ildap group members to the gitlab group. Be aware that inria members need to connect at least one time to gitlab for their account to be created.
 
 Provided you are in the INRIA network and have access to ldap://ildap.inria.fr, you can search for a groupname with a command such as:
 
@@ -473,10 +473,10 @@ So, here are some possible workarounds to this development model when using the
 - Use pull-requests mechanisms at the git level, rather than at the Gitlab level. This is the way that the Linux kernel has been developed for a long time now. Instead of submitting a MR with the Gitlab interface, contributors send patches by email.
 - For projects with few known external contributors, it is possible for Inria members to create forks on behalf of the external contributors, then transfer ownership of these forks to the contributors. Here is a possible worklow:
 - create a new group to handle the forks of your external collaborators
-- take care to remain the only owner/master of the group in order to control the creation/destruction of forks
+- take care to remain the only owner/maintainer of the group in order to control the creation/destruction of forks
 - create a fork from the original project with as destination the newly created group. By default the name of the project will be the same as the original project, e.g. `https://gitlab.inria.fr/ForksOfFoo/bar`
 - then rename this forked project through Settings -\> General -\> Advanced Settings, e.g. `https://gitlab.inria.fr/ForksOfFoo/bar-jdoe`
-- finally add your collaborator master on that fork
+- finally add your collaborator maintainer on that fork
 - For projects with few known and trusted external contributors, these contributors can be added to the project but develop in their own branches. There are some basic mechanisms in Gitlab to ensure they don't override their permissions: if these users have role developer, they won't be allowed to push to protected branches (master, by default). Details on Gitlab permissions can be found here: https://gitlab.inria.fr/help/user/permissions.md.
 
 If these workarounds do not fit well with what you need and you absolutely want to use the standard MR development model with external contributors, the only solution is to use another tool than the Inria Gitlab.