GitLab

Read this or risk your project being removed without notice. Please do not ask the admins to fix it for you afterwards; we will just delete the project.

You are free to create any project you like, but it should generally be related to research and training in the context of quantum control, in particular, if you intend to make it public. We do not mind some less related projects, if that's clear from the description, does not cause confusion and does not consume a large amount of resources (which would then not be available to the main projects), but it may be better to host these elsewhere. Note that we do reserve the right to remove any project without notice or option to recover the data. Keep your own backups. Backups can easily be automated by syncing the git repositories and similar data export/access mechanisms of the systems on this site, but we do not provide any specific support for it.

We aim to release all projects under a suitable open source license, ideally AGPL, GPL or FDL; some CC licenses and related here or here, etc. may also be appropriate. If this is not suitable, discuss the project with a site admin or find another place for your project. In particular, if the project may be clearly of a commercial nature, we may remove it without notice.

Project titles should start with TYPE - DESCRIPTIVE_PROJECT_TITLE [- {MIRROR, MOD, FIX, FORK}]. TYPE is Code, Data, Paper, PhD, Report, Img, Info, Proposal, Cfg, Test (others only if justified). Add MIRROR at the end if this is a local copy from an external source. Add MOD at the end if this is a modified local copy derived from an external source. Add FIX at the end if this is a project that needs a major revision, is a basis for creating a new project, etc. Add FORK at the end if this is a forked project, especially if it is intended to be merged eventually. Do not include these optional extensions in the slug.

Please carefully choose a project title, as it could cause some problems if it is changed later on (and sometimes it cannot be changed anymore). Ensure the project slug is a string that works easily as a folder/file name for your own convenience (no spaces and characters that need quoting, etc). Also, consider if the project should be part of an existing group, a new group, or under your account. Any of this can be changed later on, if suitable, but ideally, you get this right from the start. If unsure, create a private project under your user account and decide later what to do with it. Initially, it may be best to make your project private or internal before being ready to be published as a public project.

When the project is set up, make sure you complete all the other information of the project in the project settings, including the general section: description, avatar, topics, features, badges, service desk; the CI/CD setup; and other parts of the settings that may apply, in particular when the project is more established. We suggest not to enable any features for the project you are not using (yet). Make sure your project has got a README.md file with a suitable description and a LICENSE file, choosing a licensing option. You can provide detailed documentation of your project in the wiki (this is in a git archive, so it can be handled like the main repository). Projects that are insufficiently documented and whose purpose cannot be clearly identified or whose setup is causing problems for the site may be deleted.

When setting up the project, keep in mind that large files and especially binary files should be added via git LFS to avoid the git repository becomes inefficient. Large data collections are ideally separated into related projects in a (sub-)group, where each project contains one consistent set of data that can be released together, and no smaller unit would make sense to release on its own (as usual).

A project tagged (topic) with "email" will get a simple mailing list PROJECT-SLUG@qyber.black for all its members. The distributor is regularly updated, but this may be delayed by a day or so until it is set up or updated.

Also consider creating related resources, badges, links, groups, etc. to any of the associated sites to link your project into the qyber infrastructure fully; e.g. Qyber\black Mattermost, an SVC site (requires the help of an admin) or the social media presence. Syncing projects with other repositories may also be suitable; e.g. sync the git repository with github.com, gitlab.com, bitbucket.org or release data on figshare.com (can be linked with GitHub), ieee-dataport.org. Such mirrors are useful for backup, accessibility, archival and very long-term availability reasons.

Finally, look at other projects, particularly public ones, to get an idea of how to set up your project.