Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
docs: Add a section on surveys to the researcher guidelines
It is common for university researchers to want to poll the community with
online surveys, but that approach distracts developers while yielding
little in the way of useful data. Encourage alternatives instead.
Co-developed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/87il9v7u55.fsf@meer.lwn.net
+27
+27
Documentation/process/researcher-guidelines.rst
+27
Documentation/process/researcher-guidelines.rst
···
44
44
involved. Developers cannot be interacted with/experimented on without
45
45
consent; this, too, is standard research ethics.
46
46
47
+
Surveys
48
+
=======
49
+
50
+
Research often takes the form of surveys sent to maintainers or
51
+
contributors. As a general rule, though, the kernel community derives
52
+
little value from these surveys. The kernel development process works
53
+
because every developer benefits from their participation, even working
54
+
with others who have different goals. Responding to a survey, though, is a
55
+
one-way demand placed on busy developers with no corresponding benefit to
56
+
themselves or to the kernel community as a whole. For this reason, this
57
+
method of research is discouraged.
58
+
59
+
Kernel community members already receive far too much email and are likely
60
+
to perceive survey requests as just another demand on their time. Sending
61
+
such requests deprives the community of valuable contributor time and is
62
+
unlikely to yield a statistically useful response.
63
+
64
+
As an alternative, researchers should consider attending developer events,
65
+
hosting sessions where the research project and its benefits to the
66
+
participants can be explained, and interacting directly with the community
67
+
there. The information received will be far richer than that obtained from
68
+
an email survey, and the community will gain from the ability to learn from
69
+
your insights as well.
70
+
71
+
Patches
72
+
=======
73
+
47
74
To help clarify: sending patches to developers *is* interacting
48
75
with them, but they have already consented to receiving *good faith
49
76
contributions*. Sending intentionally flawed/vulnerable patches or