Guidelines for administration of your own content in projects and groups

Getting started: Create a project or a group of projects

As an VIRTUAL project member (and therefore INTERNAL user of this platform), you can create your own project repository and groups which serve as folders containing different projects. Just click on the "new project" or "new group" button in the "explore groups" or "explore projects" screen, the rest is rather self explanatory (and explained in the user documentation).

Projects and groups: visibility levels

Every project and group has one of three visibility levels:

• PRIVATE -- the project is only visible to project members.
• INTERNAL -- the project is visible to all INTERNAL users (that is, essentially, VIRTUAL members).
• PUBLIC -- the project is publicly visible on the internet.

Each of these levels has different requirements concerning content quality. On a PRIVATE project, you may upload any work-in-progress content that you want to collaborate on with your colleagues. The content on INTERNAL projects should more or less meet the publication requirements as specified in the Content guidelines sections (e.g., file headers, documentation, license agreements etc.). However, this is only controlled by the project owner and not enforced by the administrators. To a certain extent, not-publication-ready content can be tolerated if it is useful for the development process. On a PUBLIC repository, on the other hand, only publication-quality content may be uploaded.

If you start a project or a group, you can choose whether it is PRIVATE or INTERNAL. For a project meant for development collaboration, you most likely want to start with a PRIVATE one and, once the content has reached a certain VIRTUAL-wide impact, re-check that it roughly meets the content requirements and then make it INTERNAL. This check-up is your own responsibility, there is no double-check by the platform administrators. If finally the project is ready to be released to the public, the project can be converted to PUBLIC. This can only be done by the administrators. Before release as PUBLIC, the content quality is double checked in collaboration of the project owner and the administrator. If the content is subject to an internal review within VIRTUAL, it may make sense to include the reviewer in the quality check process.

Inviting project and group members: access permissions

If you start a project or a group, you can invite other platform users to become members of your project/group, where you can decide the level of access rights that member is granted:

• Owner
• Maintainer
• Developer
• Reporter
• Guest

By default, if you start the project, you are its Owner, and have full administrator rights (up to deleting the whole repository). You should not appoint any further Owners; further project administrators should be Maintainer (who have almost the same privileges). "Normal" collaborators should be Developers, whereas the levels Reporter and Guest are essentially read-only contributors. The detailed privileges for all levels can be found here. As a project owner, you can change member privileges at any time. Everyone who can see your project (depending on its visibility level) can ask you to become project member. Be careful with EXTERNAL users: By default, only VIRTUAL members should collaborate on VIRTUAL content, thus EXTERNAL users should generally not be granted access rights beyond Reporter.