1========= 2Team 3========= 4 5flashrom development process is happening in Gerrit. 6All contributors and users who have a Gerrit account can send patches, 7add comments to patches and vote +1..-1 on patches. 8 9All contributors and users are expected to follow :doc:`/dev_guide/development_guide` and 10:doc:`code_of_conduct`. 11 12There are two special groups in Gerrit. 13 14"flashrom reviewers" group 15========================== 16 17Members of the group (see `flashrom reviewers <https://review.coreboot.org/admin/groups/25cadc351dd0492fd2a2a1b1a8e5bb08c29e411f,members>`_) 18can do full approval of patches (i.e. vote +2). 19 20In general, members of the group have some area of responsibility in the 21`MAINTAINERS <https://github.com/flashrom/flashrom/blob/main/MAINTAINERS>`_ file, 22and are automatically added as reviewers to patches when the patch touches this area. 23 24The responsibilities are the following. 25 26* React to patches when added as a reviewer. 27 28* Try to respond to technical questions on the mailing list if the topic is something you know about 29 and can provide a useful response. 30 31* Know development guidelines and check the patches you are reviewing align with the guidelines. 32 33"flashrom developers" group 34=========================== 35 36Members of the group (see `flashrom developers <https://review.coreboot.org/admin/groups/db95ce11b379445ac8c5806ea0b61195555b338d,members>`_) 37can merge patches. 38The responsibilities for the members of the group are described in more details below. 39 40There is no expectation on how much time you spend on your duties, some non-zero amount of time, 41whatever capacity you have. But in general, you stay around on flashrom. 42 43If you disappear for some time (life happens), especially for a longer time, like several months, 44especially without a warning: you implicitly agree that the others will handle the duties and make decisions if needed 45(potentially without waiting for you to come back, if the decision is needed quickly). 46 47* Merge all contributors's patches (when they are ready), not just your own. 48 49* Be at least vaguely aware what development efforts are ongoing, this helps to make decisions 50 in what order the patches should be merged, and where could be merge conflicts. 51 52* Know development guidelines, and educate other contributors if needed (e.g. give links). 53 54* React to patches when added as a reviewer. 55 56* Try to respond to technical questions on the mailing list if the topic is something you know about 57 and can provide a useful response. 58 59* From time to time show up in real-time channel(s) and/or dev meetings. 60 61* Follow the :doc:`code_of_conduct`, be a good example for others. 62 63* Bonus point: if you work in a [software] company, educate and help contributors from your company 64 with upstream culture and dev guidelines. 65