How Open Science Practices Can Appear in a Research Environment

When you are looking at a research group or host environment, you may find public data, code, preprints, protocols, or papers that can be read without a subscription. These are useful things to notice. They can show how some parts of the research have been shared and where you can inspect the work yourself.

They are not a score for the group. One public dataset does not prove that every project is open. A university policy does not prove that a particular team follows it. A well-documented code repository does not tell you whether supervision will be good. Read each item for exactly what it shows, then keep the rest as questions.

This is a practical way to do that. It is useful when you are choosing which research environments to investigate further, not when you are trying to rank people or predict an application result.

Start with a narrow question

Open science is wider than open-access papers. UNESCO describes it as a set of practices intended to make scientific knowledge and the way it is produced more accessible, inclusive, and sustainable. Its guidance also makes an important point for applicants: access should be as open as possible, but it can need limits for privacy, confidentiality, intellectual property, safety, or sensitive knowledge. UNESCO's overview of the Recommendation on Open Science is a useful place to understand that wider picture.

When you investigate a research environment, do not try to decide whether a group is "open". Use a smaller question instead: Can I find public evidence of how this team shares research outputs, and what does that evidence let me investigate?

That question keeps the work manageable. You are looking for records tied to real research, not trying to judge a group's values from its website design or a single sentence in a profile.

Begin with recent outputs, not a general claim

Open the group page, the university research portal, or the named researcher's official profile. Find three recent papers, datasets, software releases, or project pages. Then follow the links that those outputs provide.

Use the output itself as the starting point. A recent paper may have a data-availability statement, a code link, a preprint version, a protocol reference, or a repository record. A project page may list a dataset, software package, or public report. A researcher profile may point to a maintained lab repository. These are more useful than a broad statement such as "we support open research" because they give you a record to inspect.

Write down the title, link, date, and the exact type of output. Do not assume that a public link belongs to the group until the authors, project name, or affiliation make the connection clear. Do not assume that a repository is current just because it appears in a search result. Check the latest release, record date, or linked publication.

Look for data evidence with its limits in view

A dataset record can show that data connected with an output has been deposited somewhere findable. Stronger evidence usually includes a clear title, authors or project name, a description, a licence or access condition, a suggested citation, and a link to the related paper. A stable identifier such as a DOI can make the record easier to find again, but it does not tell you whether every file is openly downloadable or suitable for reuse.

University repositories make this distinction visible. The University of Oxford's research data guidance explains that its institutional archive preserves and shares datasets alongside other research outputs. Its current glossary also notes that a repository may be open access or restricted. That is a useful reminder: a visible record can be meaningful evidence of stewardship even when access is controlled.

For biomedical or participant-based work, an absence of downloadable files is not automatically a negative signal. The NIH data management and sharing policy overview requires planning for applicable NIH-supported research, while its privacy guidance explains why controlled access or other limits may be justified. Ask whether the page explains the access condition, rather than expecting every dataset to be public.

Treat code and software as separate research outputs

In computational, engineering, and data-heavy research, code can be part of the method. A public repository can let you see the structure of the work, its documentation, releases, licence, linked publications, and whether there are instructions for reproducing a result. It may also show that a project has made a particular version of software available.

But a code-hosting account is not enough by itself. It may be personal, experimental, old, or unrelated to the advertised research. Look for an explicit link from a paper, project page, data record, or official team page. If a repository is connected to a paper, check whether the paper identifies the version used. If it is software rather than a short analysis script, check whether it has a release note or a separate archive record.

The University of Edinburgh's research data management policy explains that software may be deposited with research data or managed through code repositories, and that documentation matters for transparent reuse. The policy is not evidence that every Edinburgh group does this. It is evidence that the institution describes software and code as part of research-data practice. The Software Heritage documentation is another useful reference point for checking what a persistent source-code archive can contain and how records can be referenced.

Read preprints as a record of public sharing, not a quality mark

A preprint is a manuscript shared before, or alongside, formal peer-reviewed publication. Finding a preprint can help you read a group's recent work, see the author list, and follow the development of a paper through visible versions. It does not tell you whether the final paper reached the same conclusions, and it does not remove the need to read the journal version when one exists.

Preprint use varies a lot. It is established in some research areas, growing in others, and uncommon in others. The UK Research and Innovation guidance on open access explicitly encourages the use of preprints across the disciplines it supports, but it does not make preprints part of its open-access policy. That is a good example of why you should not treat the absence of preprints as proof that an environment is closed.

If you find a preprint, connect it carefully to the right work. Check the authors, title, date, and any link to the published article. If the title changed, use the author names, project description, and DOI links on the publisher page to confirm the relationship. Do not rely on a search snippet alone.

Check whether methods are made usable

Protocols, method papers, detailed supplementary materials, and public workflow pages can make a research process easier to understand. In experimental work, a protocol may cover steps that are only briefly described in an article. In computational work, a workflow description or documented notebook may play a similar role. In field, clinical, industrial, or security-sensitive work, a complete protocol may not be public for sound ethical, legal, safety, or contractual reasons.

The practical question is not "Does this team publish every method?" Ask whether the materials that are public are connected to a genuine output and give enough context to understand what they are. A protocol record should name the method or project, identify its version or date, and link to a related output when possible. A detailed methods section can be just as useful as a separate protocol record.

Services such as protocols.io describe their role as helping researchers create and share research workflows and methods. A record there is evidence of a specific published method. It is not evidence that the whole lab uses the same approach, and it is not a reason to infer how people are trained or supervised.

Separate group evidence from institutional support

An institution may have an open-research statement, a data-management policy, a repository, training, or staff who support research data. This matters because it tells you what formal infrastructure may exist. It still answers a different question from whether a particular group makes use of it.

For example, Oxford's research data guidance describes planning support, repository services, and training. Zenodo's official information explains that the general-purpose repository was launched by CERN and OpenAIRE to support sharing across disciplines. Those pages help you recognise the kind of infrastructure behind a data or software record. They do not establish a group's own habits unless you can connect the group to an actual record.

Keep two columns in your notes: "group-level evidence" and "institutional or funder context." This small distinction prevents a common mistake. A policy can make open practice possible or expected, but it cannot replace evidence from the work you are considering.

Use an evidence-to-question table

Do not turn this into a rating system. The purpose of a table is to stop one observation from carrying too much weight.

The table should end with questions, not conclusions. If you are considering a particular opportunity, a concise question to the named contact can be more useful than further guessing: "I saw the dataset and code linked to your recent paper. Are there similar resources or data-management practices relevant to this project?"

Respect the field and the work itself

Different STEM fields produce different kinds of evidence. A computational group may have software releases and versioned repositories. A laboratory group may have data records, protocol pages, and supplementary files. A research group working with people, confidential industry material, sensitive locations, protected species, or security-relevant methods may publish an access statement rather than the underlying files. A theory-focused group may make preprints, lecture notes, or working papers more visible than data.

The important test is whether the public material is understandable in the context of the research. Do not reward a field for producing the kind of output that is common elsewhere. Do not penalise a team for protecting participants or legitimate confidential material. Instead, see whether the public record is clear about what exists, what can be accessed, and why a limit may apply.

Build a short, honest note

For each environment, keep a note with three sections. Under "evidence", save no more than three links to real outputs. Under "context", add the relevant university or funder policy if it directly relates to those outputs. Under "unknowns", write the questions that the public record cannot answer.

This note is enough to compare environments fairly. It helps you see where you can read the work in depth, where access is controlled, and where you still need a direct conversation. It does not decide where you should apply.

Explore STEM fields

Sources

• UNESCO: Recommendation on Open Science explains open science as a broad set of principles and practices, including the need for appropriate limits on access.
• NIH: Data Management and Sharing Policy Overview explains planning and sharing expectations for applicable NIH-supported research.
• NIH: Principles and Best Practices for Protecting Participant Privacy explains why privacy and controlled access can limit public data sharing.
• UKRI: Making Your Research Article Open Access explains its open-access routes and its position on preprints.
• University of Oxford: Research Data Management describes institutional support and repository-based preservation and sharing of research datasets.
• University of Oxford: Research Data Management Glossary distinguishes open and restricted repository access.
• University of Edinburgh: Research Data Management Policy describes policies around research data, code, documentation, repositories, and legitimate restrictions.
• Zenodo: About explains the CERN and OpenAIRE-backed general-purpose research repository.
• Software Heritage: Documentation explains the purpose and use of a source-code archive.
• protocols.io: About describes its role as a platform for creating and sharing research workflows and protocols.