1 files changed, 61 insertions, 0 deletions
diff --git a/doc/about_flashrom/team.rst b/doc/about_flashrom/team.rst
new file mode 100644
index 000000000..9d002bb66
--- /dev/null
+++ b/doc/about_flashrom/team.rst
@@ -0,0 +1,61 @@
+=========
+Team
+=========
+
+flashrom development process is happening in Gerrit.
+All contributors and users who have a Gerrit account can send patches,
+add comments to patches and vote +1..-1 on patches.
+
+All contributors and users are expected to follow Development guidelines,
+Code of Conduct and Friendliness guidelines.
+
+There are two special groups in Gerrit.
+
+"flashrom reviewers" group
+==========================
+
+Members of the group can do full approval of patches (i.e. vote +2).
+
+In general, members of the group have some area of responsibility in the MAINTAINERS file,
+and are automatically added as reviewers to patches when the patch touches this area.
+
+The responsibilities are the following.
+
+* React to patches when added as a reviewer.
+
+* Try to respond to technical questions on the mailing list if the topic is something you know about
+  and can provide a useful response.
+
+* Know development guidelines and check the patches you are reviewing align with the guidelines.
+
+"flashrom developers" group
+===========================
+
+Members of the group can merge patches.
+The responsibilities for the members of the group are described in more details below.
+
+There is no expectation on how much time you spend on your duties, some non-zero amount of time,
+whatever capacity you have. But in general, you stay around on flashrom.
+
+If you disappear for some time (life happens), especially for a longer time, like several months,
+especially without a warning: you implicitly agree that the others will handle the duties and make decisions if needed
+(potentially without waiting for you to come back, if the decision is needed quickly).
+
+* Merge all contributors's patches (when they are ready), not just your own.
+
+* Be at least vaguely aware what development efforts are ongoing, this helps to make decisions
+  in what order the patches should be merged, and where could be merge conflicts.
+
+* Know development guidelines, and educate other contributors if needed (e.g. give links).
+
+* React to patches when added as a reviewer.
+
+* Try to respond to technical questions on the mailing list if the topic is something you know about
+  and can provide a useful response.
+
+* From time to time show up in real-time channel(s) and/or dev meetings.
+
+* Follow the Code of Conduct and Friendliness guidelines, be a good example for others.
+
+* Bonus point: if you work in a [software] company, educate and help contributors from your company
+  with upstream culture and dev guidelines.