FAIRiCUBE / FAIRiCUBE-Hub-issue-tracker

FAIRiCUBE HUB issue tracker
Creative Commons Zero v1.0 Universal
0 stars 1 forks source link

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:

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