-
-
Notifications
You must be signed in to change notification settings - Fork 43
Guidelines on Namespace Requests
The general concept of namespaces is described in the Managing Namespaces. This page provides guidelines for handling namespace-related requests, which are submitted as issues to github.com/EclipseFdn/open-vsx.org.
Namespace ownership requests are marked with a namespace labekl. After processing the request, we assign either the granted or the denied label (the latter should happen very rarely).
We don't check the legitimacy of ownership requests. We regard the requirement to create a public issue to request ownership as sufficient, as it provides full transparency. Any information provided by the requesting user serves as a public record that can be disputed in case of conflict.
Namespace ownership should not be granted to bots / service accounts, but only to accounts associated with real persons. They will have the opportunity to add more accounts to the namespace by themselves (see below).
The requesting users must have logged in to https://open-vsx.org at least once so we can find them in our database and they must have signed the Publisher Agreement.
In most cases the namespace in question has already been created by the requesting user. If the namespace does not exist yet, the administrator can create it. If unsure whether the spelling of the namespace is correct, the administrator should clarify this in the issue.
Upper and lower case is irrelevant when searching extensions and namespaces. However, the namespace will appear in the UI exactly as it has been created.
The administrator should check all extensions that have been already been published in the requested namespace (these are listed in the dashboard). If they have been published by other users (not requesting ownership), the respective extensions will be displayed with warning signs after ownership has been granted. Those warnings will disappear as soon as the new owner publishes new versions of the extensions. However, the owner has the right to request deletion of the previous versions. Preferably this should happen after publishing new versions in order to avoid breaking downstream users, since deleting all current versions would mean deleting the whole extension.
The authority to publish new extension versions in the requested namespace is exclusive to the new owner. However, there is an exception with the @open-vsx, which publishes extensions from a JSON list. If an extension in the requested namespace is being published from that account, an issue should be created in the publish-extensions repository requesting to remove the extension from the list.
It is ok for multiple users to request ownership of a namespace together. However, they can administrate the namespace in their settings page and add or remove members as they wish. Members can be either owners with full administration access or contributors with publishing access.
Requests to rename a namespace will come in as issues to github.com/EclipseFdn/open-vsx.org. An admin submits to rename a namespace (and optionally merge it with another) through the admin panel. These requests are processed asynchronously. If there are dependencies on any of the extensions in the namspace, the rename will fail.
Requests to delete a namespace will come in as issues to github.com/EclipseFdn/open-vsx.org. Currently, there is no explicit support to delete a namespace. Once there are no extensions in the namespace, an admin can accomplish a delete by 'renaming' the namespace to an existing namespace and marking the converge option.