@@ -44,6 +44,33 @@ explicit agreement of, and full disclosure to, the individual developers
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
0 commit comments