|
**Read this or risk your project being removed without notice. Don't ask the admins to fix it for you afterwards; we will just delete the project.**
|
|
**Read this or risk your project being removed without notice. Please don't ask the admins to fix it for you afterwards; we will 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.
|
|
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](https://www.gnu.org/licenses/agpl-3.0.html), [GPL](https://www.gnu.org/licenses/gpl-3.0.html) or [FDL](https://www.gnu.org/licenses/fdl-1.3.html); some [CC](https://creativecommons.org/share-your-work/) licenses and related [here](https://opensource.org/licenses) or [here](https://choosealicense.com/licenses/), etc. may also be appropriate. If this is not suitable, discuss the project with a site admin first 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, and you will not be able to recover any data.
|
|
We aim to release **all projects under a suitable open source license**, ideally [AGPL](https://www.gnu.org/licenses/agpl-3.0.html), [GPL](https://www.gnu.org/licenses/gpl-3.0.html) or [FDL](https://www.gnu.org/licenses/fdl-1.3.html); some [CC](https://creativecommons.org/share-your-work/) licenses and related [here](https://opensource.org/licenses) or [here](https://choosealicense.com/licenses/), 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.
|
|
|
|
|
|
When setting up the project, also keep in mind that **large files** and especially binary files should be added via [git LFS](https://git-lfs.github.com/) 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 there is no smaller unit that would make sense to release on its own (as usual).
|
|
**Project titles** should start with _TYPE_ - _DESCRIPTIVE_PROJECT_TITLE_ [- {MIRROR,MOD}]. _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.
|
|
|
|
|
|
Please **carefully choose a project title**, as it could cause some problems if it is changed later on (even if this is minor). Make sure the **project slug** is a string that works easily as 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 unclear, create a private project under your user account and decide later what to do with it.
|
|
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.
|
|
|
|
|
|
Initially, it may be best to make your project **private** or **internal**, before being ready to be published as public project. You may also want to create an internal/private project for unreleased development that will later be merged into 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 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. You can provide detailed documentation of your project in the wiki (this is in a git archive, so can be handled like the main repository). Projects that are insufficiently documented and whose purpose cannot be clearly identify 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](https://git-lfs.github.com/) 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).
|
|
|
|
|
|
**Project titles:** Project titles should start with _TYPE_ - _DESCRIPTIVE_PROJECT_TITLE_ [- MIRROR]. TYPE is Code, Paper, PhD, Data, Img, Info, Proposal, Cfg, Test (others only if justified). Add MIRROR at the end if this is a local copy from an external source.
|
|
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.
|
|
|
|
|
|
**Project tags:** 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 may be delayed by a day or so until it is set up or updated, if membership changes.
|
|
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](https://mm.qyber.black/), an [SVC](https://svc.qyber.black/) 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](https://github.com/), [gitlab.com](https://gitlab.com/), [bitbucket.org](https://bitbucket.org/) or release data on [figshare.com](https://figshare.com/) (can be linked with GitHub), [ieee-dataport.org](https://ieee-dataport.org/). Such **mirrors** are useful for backup, accessibility, archival and very long-term availability reasons.
|
|
|
|
|
|
Also consider creating **related resources**, links, groups, etc. to any of the associated sites to fully link your project into the qyber infrastructure; e.g. [Qyber\black Mattermost](https://mm.qyber.black/), an [SVC](https://svc.qyber.black/) site (requires 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](https://github.com/), [gitlab.com](https://gitlab.com/), [bitbucket.org](https://bitbucket.org/) or release data on [figshare.com](https://figshare.com/) (can be linked with GitHub), [ieee-dataport.org](https://ieee-dataport.org/). Links to related sources may be added via badges.
|
|
Finally, look at other projects, particularly public ones, to get an idea of how to set up your project. |
|
|
|
|
|
Look at other projects, in particular public ones, to get an idea of how to set up your project. |
|
|