Friendliness: Difference between revisions
No edit summary |
(Use they instead of he/she, and fix a nearby typo (one ---> once)) |
||
Line 19: | Line 19: | ||
Reviews are not personal attacks. A negative review does NOT mean the reviewer doesn't like you, it just means there are ways to improve your patch. Even our senior developers have to rework their patches from time to time. | Reviews are not personal attacks. A negative review does NOT mean the reviewer doesn't like you, it just means there are ways to improve your patch. Even our senior developers have to rework their patches from time to time. | ||
If you disagree with parts of the review, please provide an explanation why you disagree and resend your patch with the other review comments (those you agree with) addressed. It is entirely possible that the | If you disagree with parts of the review, please provide an explanation why you disagree and resend your patch with the other review comments (those you agree with) addressed. It is entirely possible that the reviewers will agree with you once they see your explanation. If reviewers disagree with each other (happens very rarely), feel free to ask them to agree on a consensus before you address conflicting comments. | ||
Once you have fixed the issues raised in the review, please resend your patch. Most of the time, the new patch will be committed. | Once you have fixed the issues raised in the review, please resend your patch. Most of the time, the new patch will be committed. | ||
Line 44: | Line 44: | ||
* People who intentionally insult others (users, developers, the project itself) will be dealt with. | * People who intentionally insult others (users, developers, the project itself) will be dealt with. | ||
* We're dealing with hardware with lots of undocumented pitfalls. It can happen that you did everything right, but it still does not work for you. | * We're dealing with hardware with lots of undocumented pitfalls. It can happen that you did everything right, but it still does not work for you. | ||
* It's not the user's fault if something goes wrong. Don't blame the user unless | * It's not the user's fault if something goes wrong. Don't blame the user unless they explicitly acted against the advice given. | ||
* If you feel like you have been treated in an unfair way, we want to hear about it so we can fix it. Our arbitration committee (Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> and Stefan Reinauer <reinauer@google.com>) can be contacted directly and will listen to you. If you don't get a response within a few days, your mail was probably lost. Feel free to resend your mail to another member of the arbitration committee in that case. | * If you feel like you have been treated in an unfair way, we want to hear about it so we can fix it. Our arbitration committee (Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> and Stefan Reinauer <reinauer@google.com>) can be contacted directly and will listen to you. If you don't get a response within a few days, your mail was probably lost. Feel free to resend your mail to another member of the arbitration committee in that case. |
Revision as of 15:07, 20 October 2022
The flashrom project is proud of a friendly and encouraging atmosphere.
We welcome participation from every human being, regardless of gender/ethnicity/views/...
This page simply documents what we're doing anyway.
Developers
We welcome every contribution, no matter how small.
There are a few requirements for patches as outlined below. If you follow them, you can speed up inclusion of your patches a lot.
- Include a changelog/explanation with your patch mail. For small/trivial changes, one line is enough. If you're doing something complicated, please explain it so that someone else reading the changelog can understand what you were up to.
- Add a Signed-off-by statement to your mail.
- Read the Development Guidelines or at least the How to contribute section and take them into account when writing your patch.
- Respond to reviews.
Reviews happen for every patch sent to the list. Unless your patch is really small and trivial, a reviewer will usually ask you to fix/change a few things in your patch.
Reviews are not personal attacks. A negative review does NOT mean the reviewer doesn't like you, it just means there are ways to improve your patch. Even our senior developers have to rework their patches from time to time.
If you disagree with parts of the review, please provide an explanation why you disagree and resend your patch with the other review comments (those you agree with) addressed. It is entirely possible that the reviewers will agree with you once they see your explanation. If reviewers disagree with each other (happens very rarely), feel free to ask them to agree on a consensus before you address conflicting comments.
Once you have fixed the issues raised in the review, please resend your patch. Most of the time, the new patch will be committed.
Really big code changes, new drivers and redesigns will lead to multiple review rounds where each round points out things not mentioned in earlier reviews. We try to limit the number of review rounds to 3 before the initial commit, but we may ask you to continue submitting fixes after your patch has been committed.
Users
We are happy to help users of flashrom with any questions they have.
If you are a user, we ask you to include as much information as possible into your mails. That saves us the burden of asking for it explicitly and benefits you because we can answer you sooner. Hints about what you should include in your mail are given below.
- flashrom: TODO
Please remember that flashrom is run by busy volunteers, so it may be possible your mail gets overlooked. If you didn't receive a reply after a few days, please resend your mail (with the same subject) or respond to your mail with a small summary and the comment "ping".
In case of emergency (failed flash etc.), you may want to look for help on Contact#IRC (chat) where quite a few of our developers hang out, but please be patient (and repost your issue every two hours or so if you don't get an answer) as some of us may be asleep or at work.
Mailing list and chat etiquette
- We have a friendly and productive atmosphere at our lists and chatrooms.
- Please refrain from insulting anyone (or the group they belong to).
- Most participants are not English native speakers, so misunderstandings can happen. Always assume that others are friendly and may have picked less-than-stellar wording by accident.
- People who intentionally insult others (users, developers, the project itself) will be dealt with.
- We're dealing with hardware with lots of undocumented pitfalls. It can happen that you did everything right, but it still does not work for you.
- It's not the user's fault if something goes wrong. Don't blame the user unless they explicitly acted against the advice given.
- If you feel like you have been treated in an unfair way, we want to hear about it so we can fix it. Our arbitration committee (Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> and Stefan Reinauer <reinauer@google.com>) can be contacted directly and will listen to you. If you don't get a response within a few days, your mail was probably lost. Feel free to resend your mail to another member of the arbitration committee in that case.