Reporting

Contents

1. About
2. If it is not on GitHub, it does not exist
3. Check existing issues before submitting
4. Describe concrete steps how to reproduce a problem
5. Tag issues with appropriate labels
6. Next steps

About

This wiki page summarises our principles and practices as to reporting bugs and making new feature requests.

If it is not on GitHub, it does not exist

We are using GitHub issues for everything. This means all bug reports and feature requests should be opened as GitHub issues. The conversation happening in chat rooms or by email may get lost; in order to keep track, please always open an issue in our tracker.

Check existing issues before submitting

It can happen that somebody else stumbled across a problem before and already opened an issue about it. There could be a valuable discussion there that might perhaps help you to solve the problem already. Please always check existing issues before opening new ones.

Describe concrete steps how to reproduce a problem

The best bug reports are the ones that are most actionable already from their description. Please always describe (i) what you did, (ii) what was the outcome, and (iii) what you expected instead. If we know the concrete steps how to arrive at a certain problem, the chances are we can reproduce and fix it sooner.

Tag issues with appropriate labels

REANA uses a rich set of labels that are useful to facilitate research.

• If you are interested in a certain workflow system such as Snakemake, look for label workflow/snakemake.

• If you are interested in a certain compute backend platform such as Slurm, look for label compute/slurm.

• If you are interested in issues specific to ATLAS collaboration, look for label community/atlas.

We are using unique label prefixes to identify topics of interest. Here is the overview of all REANA issue label prefixes:

• auth/* - labels related to authorisation and authentication (Kerberos, etc.)
• cli/* - labels related to command-line clients
• community/* - labels related to issues specific to certain user communities (ATLAS, CMS, etc.)
• compute/* - labels related to compute backends (HTCondor, Kubernetes, Slurm, etc.)
• container/* - labels related to certain container technologies (Docker, Singularity, etc.)
• deployment/* - labels related to deployment on various platforms (AWS, CERN, GKE, etc.)
• integration/* - labels related to integration with other systems (GitLab, etc.)
• size/* - labels related to the estimated complexity of the issues (s - small, m - median, etc.)
• storage/* - labels related to supported storage systems (Ceph, CVMFS, EOS, NFS, etc.)
• system/* - labels related to internal REANA matters (API, CI, design, docs etc.)
• triage/* - labels related to issue triaging (attributing priority, etc.)
• type/* - labels specifying issue types (bug report, feature enhancement, etc.)
• ui/* - labels related to web user interfaces
• workflow/* - labels related to specific supported workflow engines (CWL, Snakemake, Yadage, etc.)

You can see the list of all labels.

Please don't hesitate to label issues heavily; it helps to better organise and find the information.

Next steps

Now that the issue is submitted, what happens to it? The next step of the issue life cycle is Triaging.