REFSQ 2027
Mon 12 - Thu 15 April 2027 Basel, Switzerland

Open Science is a movement that promotes transparency, accessibility, and reproducibility in scientific research. By making research processes and artefacts openly available, it enhances the rigour and credibility of scientific work while enabling broader participation, validation, and reuse by the community. Open Science plays an important role in strengthening collaboration between academia and industry, increasing the impact of research, and facilitating cumulative knowledge building in requirements engineering.

At REFSQ 2027, we continue the tradition of fostering Open Science practices within the requirements engineering community. The conference encourages authors to make their research outputs, such as data, models, tools, and study materials, accessible and reusable, thereby supporting more transparent and verifiable research.

REFSQ 2027 Open Science Policy

To foster open science and promote the accessibility, reusability, and long-term preservation of research artifacts in Requirements Engineering, REFSQ 2027 encourages authors to make the materials supporting their research openly available whenever possible.

Openly shared artifacts facilitate the verification of published results, enable replication and extension of existing work, support educational activities, and reduce duplication of effort across the community. At the same time, REFSQ recognises that legal, ethical, privacy, confidentiality, or intellectual property constraints may prevent the release of some materials. Authors are therefore encouraged to share as much as reasonably possible and to clearly explain any limitations preventing disclosure.

Data Availability Statement

Every submission must include a Data Availability Statement at the end of the paper, similarly to the acknowledgements section.

The statement should:

  • describe the research artiacts accompanying the paper, such as datasets, source code, scripts, models, questionnaires, experimental material, or documentation;
  • indicate where these artifacts can be accessed;
  • specify any access restrictions, if applicable;
  • explain why certain artifacts cannot be shared, when this is the case.

Examples of acceptable positive supporting statements

  1. Full disclosure, quantitative study

    The dataset supporting this study, including the mining scripts, raw repository data, and analysis notebooks, is openly available on Zenodo at https://doi.org/10.5281/zenodo.XXXXXXX under a CC-BY 4.0 license. The replication package contains all materials necessary to reproduce our findings.

  2. Partial disclosure, interview study with shareable artifacts

    Due to participant confidentiality agreements, interview transcripts cannot be shared publicly. However, the following materials are available on Zenodo at https://doi.org/10.5281/zenodo.XXXXXXX: (1) the interview protocol with all questions, (2) the complete coding schema with code definitions and examples, (3) anonymised illustrative quotes organised by theme, and (4) the inter-rater reliability calculations. Researchers seeking access to redacted transcripts for verification purposes may contact the corresponding author; access will be granted subject to ethics board approval and a data use agreement.

  3. Partial disclosure, industrial case study with mixed data

    This study combines publicly available and proprietary data. The open-source repository analysis scripts and aggregated metrics are available at https://doi.org/10.5281/zenodo.XXXXXXX. The proprietary defect data from Company X were obtained under a research agreement that permits publication of aggregated findings but prohibits disclosure of raw data. We provide: (1) the data collection instruments, (2) the statistical analysis scripts (which can be applied to similar datasets), and (3) summary statistics sufficient for meta-analysis inclusion.

Examples of acceptable negative supporting statements

  1. Industry NDA

    The data supporting this study were obtained under non-disclosure agreements with three enterprise software companies. These agreements prohibit sharing of source code, internal documents, meeting recordings, and derived artifacts. We have provided detailed methodological descriptions in Section 3 to support conceptual replication in other organisational contexts. The interview protocol is available on Zenodo at https://doi.org/10.5281/zenodo.XXXXXXX. Researchers interested in conducting similar studies in industry settings may contact the corresponding author for guidance on negotiating research access agreements.

  2. Participant privacy, sensitive population

    This study involved interviews with software developers discussing workplace conflicts, mental health challenges, and multiple problems of private matters. Due to the sensitive nature of disclosures and the small, identifiable population of senior engineers at the studied companies, we determined that even heavily redacted transcripts pose unacceptable re-identification risks. Following consultation with our ethics board, we do not share the raw data. We make the following available on Zenodo at https://doi.org/10.5281/zenodo.XXXXXXX: (1) the complete study protocol, (2) the theoretical framework and coding schema, and (3) detailed descriptions of findings with carefully anonymised composite vignettes.

  3. Proprietary tooling and metrics, commercial sensitivity

    This study analysed code quality metrics and developer productivity data from a proprietary development environment at Company Y. The raw data contain trade secrets regarding internal tooling, performance benchmarks, and staffing levels that the company considers commercially sensitive. Data sharing was explicitly excluded from our research agreement. We report aggregated statistics and effect sizes to enable comparison with future studies. The survey instrument and our analysis methodology are fully available on Zenodo at https://doi.org/10.5281/zenodo.XXXXXXX to support replication with similar data from other organisations.

Recommendations for Shared Artifacts

Whenever possible, authors are encouraged to:

  • deposit artifacts in a stable, publicly accessible repository that provides long-term preservation, such as Zenodo or Figshare;
  • assign a persistent identifier to the artifact, such as a DOI provided by archival repositories including Zenodo or Figshare, and reference the artifact in the paper;
  • organise the repository so that readers can easily locate the material supporting the paper;
  • include an open-source license or clearly specify the conditions under which the artifacts may be reused (detailed information on applicable licenses is available here).

Anonymous Artifacts for Double-Blind Review

REFSQ 2027 follows a double-blind review process. Consequently, any artefacts made available to reviewers during the review phase must preserve the anonymity of the authors, using the anonymisation features supported by the selected platform, where available.

Authors should ensure that:

  • the data availability statement does not contain identifying information;
  • repositories, archived artifacts, and supplementary material do not reveal author identities or affiliations;
  • repository names, URLs, metadata, commit histories, documentation, and file properties do not contain identifying information;
  • README files and other documentation avoid references that could reveal the identity of the authors or their institutions.

After acceptance, authors are encouraged to update the repository with complete metadata, authorship information, and any additional documentation suitable for long-term dissemination.

Authors can find further guidance on how to make artifacts available for double-blind review and convert them into archived open data once the paper is accepted here.

Documentation

To maximise the usefulness of shared artifacts, repositories should include a README file.

A good README should, where applicable:

  • describe the purpose and contents of the repository;
  • explain the repository structure;
  • list the software requirements and dependencies;
  • provide installation instructions, including platform-specific requirements when relevant;
  • explain how to reproduce the analyses or experiments reported in the paper;
  • indicate the expected outputs;
  • explain how the provided scripts or configuration files can be adapted to execute the analyses on different datasets or inputs, when applicable.

The documentation should enable researchers outside the original project to understand how the artifacts are organised and how they can be reused.

Open Science Assessment

REFSQ 2027 adopts a lightweight Open Science assessment focused on the accessibility and documentation of shared artifacts.

The Open Science assessment verifies the presence of the declared artifacts and evaluates aspects such as:

  • availability through a stable public repository;
  • accessibility of the repository and files;
  • presence of documentation, such as a README;
  • sufficient information to understand the repository contents and how the artifacts are intended to be used.

The Open Science assessment does not attempt to independently reproduce or validate the experimental results reported in the paper.

Further Resources

Authors can find further support in the artifact management guideline established in the Requirements Engineering community, which includes practical, hands-on recommendations for authors who engage in open science. The guideline can be found here.