Documentation/process/researcher-guidelines.rst

Source file repositories/reference/linux-study-clean/Documentation/process/researcher-guidelines.rst

File Facts

System
Linux kernel
Corpus path
Documentation/process/researcher-guidelines.rst
Extension
.rst
Size
8279 bytes
Lines
171
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. SPDX-License-Identifier: GPL-2.0

.. _researcher_guidelines:

Researcher Guidelines
+++++++++++++++++++++

The Linux kernel community welcomes transparent research on the Linux
kernel, the activities involved in producing it, and any other byproducts
of its development. Linux benefits greatly from this kind of research, and
most aspects of Linux are driven by research in one form or another.

The community greatly appreciates if researchers can share preliminary
findings before making their results public, especially if such research
involves security. Getting involved early helps both improve the quality
of research and ability for Linux to improve from it. In any case,
sharing open access copies of the published research with the community
is recommended.

This document seeks to clarify what the Linux kernel community considers
acceptable and non-acceptable practices when conducting such research. At
the very least, such research and related activities should follow
standard research ethics rules. For more background on research ethics
generally, ethics in technology, and research of developer communities
in particular, see:

* `History of Research Ethics <https://www.unlv.edu/research/ORI-HSR/history-ethics>`_
* `IEEE Ethics <https://www.ieee.org/about/ethics/index.html>`_
* `Developer and Researcher Views on the Ethics of Experiments on Open-Source Projects <https://arxiv.org/pdf/2112.13217.pdf>`_

The Linux kernel community expects that everyone interacting with the
project is participating in good faith to make Linux better. Research on
any publicly-available artifact (including, but not limited to source
code) produced by the Linux kernel community is welcome, though research
on developers must be distinctly opt-in.

Passive research that is based entirely on publicly available sources,
including posts to public mailing lists and commits to public
repositories, is clearly permissible. Though, as with any research,
standard ethics must still be followed.

Active research on developer behavior, however, must be done with the
explicit agreement of, and full disclosure to, the individual developers
involved. Developers cannot be interacted with/experimented on without
consent; this, too, is standard research ethics.

Surveys
=======

Research often takes the form of surveys sent to maintainers or
contributors.  As a general rule, though, the kernel community derives
little value from these surveys.  The kernel development process works
because every developer benefits from their participation, even working
with others who have different goals.  Responding to a survey, though, is a
one-way demand placed on busy developers with no corresponding benefit to
themselves or to the kernel community as a whole.  For this reason, this
method of research is discouraged.

Kernel community members already receive far too much email and are likely
to perceive survey requests as just another demand on their time.  Sending
such requests deprives the community of valuable contributor time and is
unlikely to yield a statistically useful response.

As an alternative, researchers should consider attending developer events,
hosting sessions where the research project and its benefits to the
participants can be explained, and interacting directly with the community
there.  The information received will be far richer than that obtained from
an email survey, and the community will gain from the ability to learn from
your insights as well.

Annotation

Implementation Notes