FAIRiCUBE Hub Issue Tracker
This space is used for issues and discussions on general FAIRiCUBE topics. In addition, issues are being utilized within a few of the other FAIRiCUBE Repos:
- data-requests: in addition to the issues for individual data requests, also used to discuss technical encoding details
- resource-metadata: in addition to the issues providing metadata for resources, also used to discuss technical details on resource metadata
- For UC specific issues, the UC Specific Repos:
Use the Issues tab to report bugs, errors or other topics that must be fixed, use the Discussions tab to start a more discussion on a relevant topic.
Please follow the following Best Practices as well as our Code of Conduct anytime when you interact in this space.
FAIRiCUBE GitHub Best Practices
Create a README file
To make it easier for people to understand and navigate your work, we recommend that you create a README file for every repository.
You can add a README file to a repository to communicate important information about your project. A README, along with a repository license, citation file, contribution guidelines, and a code of conduct, communicates expectations for your project and helps you manage contributions. For more information, see "About READMEs."
Define a structure and use it
Many of the FAIRiCUBE Repos (especially the UC specific Repos) were initialized with a preliminary structure, preconfigured in the code section, and described in the landing page readme. However, this structure has not always proven useful, with alternative structures evolving over time. When this happens, please keep abreast of these development, remove directories that you won't be using, and adjust the documentation on the landing page accordingly.
Favor branching over forking
To streamline collaboration, we recommend that regular collaborators work from a single repository, creating pull requests between branches instead of between repositories. Forking is best suited for accepting contributions from people that are unaffiliated with a project, such as open-source contributors.
To maintain quality of important branches, such as main
, while using a branching workflow, you can use protected branches with required status checks and pull request reviews. For more information, see "About protected branches."
Reference files instead of pasting inline
When discussing a longer piece of code, configuration, data, it is often easier if this artifact is provided as a reference to a file instead of pasting this artifact into the issue discussion. Please create a separate document in the foreseen folder, for this repo Example Files.
Stay on Topic
Issue discussions often throw up new issues, that must also be resolved. In such cases, please create a new issue to handle this new topic, to avoid issue drift.
Resolution description before closing
Before closing an issue, provide a summary of the conclusions reached within the issue discussion. This will enable us to harvest insights gained within these discussions for utilization within the Knowledge Base.
Do not close somebody else's issue
Issues should be closed by the person who initiated the issue, in order to assure that all aspects of the issue have been satisfactorily resolved.
Extended from GitHub Best practices for repositories