According to the statement of support, namespaces may be released when they meet the appropriate criteria, and requested by a paid customer (member of a paid namespace or a self-managed customer migrating to SaaS) or sales approved prospects. You can identify a sales approved prospect by the following properties:
PRIORITY PROSPECT
PP:
IMPORTANT NOTE: If you have any situation that is unusual, or does not fall under the workflow below, open an Issue with Security Operations. Describe the situation and request them to review and provide guidance.
NOTE: When applying any of the macros ensure to replace the placeholder “REQUESTEDNAME” with the namespace requested.
Support::SaaS::Name Squatting Policy::Internal Checklist
macro in Zendesk. Please remember, impersonating a user will reset the Last Sign-In values on the user account such as Last Sign-In IP
and Last Sign-in at
(Impersonation should be avoided when reviewing activity on Personal Namespace).Contact Owner:
Support::SaaS::Name Squatting Policy::Contact Namespace Owner
macro and mark the ticket as On-hold.Requester's Ticket:
Support::SaaS::Name Squatting Policy::First Response
macro and mark ticket as On-hold.If the namespace owner makes a response (don’t remove my namespace) follow these steps:
solved
:Hi,
Thank you for confirming that you wish to maintain control of the requested namespace. Per our [Name Squatting Policy](https://about.gitlab.com/handbook/support/workflows/namesquatting_policy.html#namespace-owner-responded), we have cancelled this request and will not release your namespace.
I'll mark this ticket as solved, please reach out if you have any further questions.
Support::SaaS::Name Squatting Policy::Failed Namespace Request
to the namespace requester's ticket.If after one week there has been no response, apply the Support::SaaS::Name Squatting Policy::Contact Namespace Owner
macro a second time (replace within 2 weeks
in the macro with the due date. Eg. **before the 25th of March**
) and mark the ticket as On-hold.
After two weeks, the ticket will be automatically marked as open and an email sent to the assigned engineer.
If the namespace owner has made no response, follow the Request successful steps.
If the request is successful, follow these steps:
For users, change the owner's username with Chatops:
/chatops run user idle <owner_username>
.If you'd prefer to use admin, or for groups, rename the owner's namespace with these steps:
In Zendesk:
Support::SaaS::Name Squatting Policy::Successful Namespace Request
macro to the Namespace requesters ticket and mark the ticket as Solved.Support::SaaS::Name Squatting Policy::Failed Namespace Request
macro and mark ticket as Solved.Does a login in response to a name squatting request mean that the account is active?
No, the user has to explicitly reply to the name squatting request saying "I want to keep my namespace". If the user hasn't responded and has just logged in, send a final message saying something like, "I see you logged in at X, but you need to let us know here if you want to keep your namespace".
What constitutes data in the account?
A group, a project, etc. means data. Unless the project or group is empty, or there's been no activity for 2 or more years.
Is namespace squatting permitted?
Namespace squatting is not permitted as explicitly stated in our terms. User and group names are provided on a first-come, first-served basis and may not be reserved.
Does using a trademark in a way that has nothing to do with the product or service for which the trademark was granted considered a violation of trademark policy?
Using another's trademark in a way that has nothing to do with the product or service for which the trademark was granted is not a violation of trademark policy. Claiming trademark infringement is a legal process, and we will not release a namespace for trademark violation without a court order.
Should we release a namespace even if the request might seem questionable?
Yes, we should always release the namespace as long as it meets the release criteria. Trust and Safety will take the necessary steps to mitigate any abusive activity which may subsequently originate from the namespace. See Support Team Meta issue 3145 for discussion and additional context from Support, Legal, and Trust and Safety.
Macros
Support::SaaS::Name Squatting Policy::Failed Namespace Request
Support::SaaS::Name Squatting Policy::Internal Checklist
Support::SaaS::Name Squatting Policy::First Response
Support::SaaS::Name Squatting Policy::Contact Namespace Owner
Support::SaaS::Name Squatting Policy::Successful Namespace Request
Automations