Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
M
manual_and_guidelines
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • platform_manual_and_guidelines
  • manual_and_guidelines
  • Wiki
  • guidelines for public repositories

Last edited by Arne Keller Nov 23, 2020
Page history

guidelines for public repositories

Public groups and projects

Groups and projects on visibility level PUBLIC contain the content that the VIRTUAL project shares with external users. They are part of the dissemination strategy of the project, and therefore have to be handled with particular care.

Creating public groups/projects

Generally, only the platform admins can set the visibility level of groups and projects to PUBLIC. Therefore, upgrading a project to visibility level PUBLIC can only be done with their help and approval.

Content quality in public projects

The content on public repositories is publication content by VIRTUAL and needs to meet certain quality critera. In very brief, the content should be ready to use for external users, equipped with a documentation, clearly marked as VIRTUAL content and licence and copyright have to be made clear. More in detail, the following points must be checked by content owners and admins:

  • Does the content actually work as it comes on the repository? e.g., is the model running with the required solver version, does the code run, etc.
  • Is is clear for external users how to get started? e.g., a README can give instructions for first steps or how to use the content. Alternatively, a documentation including clear instructions how to use the content from the beginning on can be given.
  • Is there a documentation? the minimal version of the documentation, again, is a README with instructions to new users. It depends on the target group and the clearness of the content (e.g., well-commented and readeable code) to what extent further documentation has to be given.
  • Do the files come with headers? Ideally, all ASCII or other human readeable files (or at least the files that are meant for the users to look at) should have a header, stationg licence, copyright and affiliation with VIRTUAL. A header example can be found in this repository.
  • Are the licence and copyright clear? They should be stated ideally in all files as headers, at least in the README. The licence agreement should be uploaded via Gitlab's licence option. There can also be different copyrights for different files.
  • Is the affiliation with VIRTUAL and funding by the EC stated? again, either in each header or in the README.
  • Do we actually have the right to publish the content? as most contents are developped within VIRTUAL, there should be no questions about that. However, if there are parts of the content that have been developed by others, it has to be verified that the copyright owners allow us to publish the content under the given licence terms (e.g., by releasing their content under a licence permitting modification and redistribution) and that there are no licence conflicts. This point should particularly be checked with the VIRTUAL partner DmN, as they host the server.
Clone repository
  • FAQ and trouble shooting
  • General guideline for all file types
  • Getting started with Git
  • Installing Git: Linux
  • Installing git: Windows
  • OpenVT Gitlab
  • SSL workaround
  • Submodules
  • Upload guidelines
  • administration guidelines
  • file types
    • Data files
    • Documentation
    • headers
    • version numbering
  • guidelines for public repositories
View All Pages