The Apache Software Foundation (ASF) and our many Apache projects welcome all participants who are willing to respect our community guidelines. There are many behavior or etiquette guides for online communities out there; we have a few Apache-specific tips below.
The ASF has adopted a Code of Conduct which covers interactions in all the online spaces that Apache projects use - email, issue trackers, wikis, websites, IRC, and the like. Apache projects are made up of volunteers, and we work to ensure that all productive contributions are welcomed. Every Apache PMC is expected to ensure their project's lists show proper behavior.
Apache projects are made up of communities of volunteers from around the world. When you are sending email to an Apache project mailing list, there may be software developers in this country, marketing managers in that country, and homemakers in another country reading your email. They will be reading your mail at all hours of the day, and both at work, at home, and on the go. If you want a response to your questions or suggestions, be sure to be polite and sensible when writing.
There are many amazing people helping out on Apache project mailing lists - but they are all volunteers. Being respectful of the time and culture of others on the list is a key start to making productive contributions.
The ASF as a corporation is run by several hundred Members, who have deep and lasting experience in helping to build and run long-term successful open source projects here at Apache. This is just one member's take on how to approach communicating in any particular Apache project.
Some General Guidelines
Assume that the other party agrees more than disagrees with you. We tend to leave out agreements and focus on differences. Sometime this is forgotten and escalation becomes absurd for no rational reason.
When in doubt, assume that you are interpreting the message wrongly and kindly ask for verification that you understood a particular topic well.
When writing, assume that every sentence will be misinterpreted. Review and try to reformulate to be as clear as possible.
Use a submissive tone in all writing. Instead of the strong "In my opinion, we must..." or the quite neutral "I think we should...", try to use "Maybe we should consider..." or "Another idea that we could..."
If you disagree strongly with an email sent, tag it Important, then put it aside. Read it half a day later again. Put it aside. Read it again next day, and then it is easier to write a balanced and inviting response, instead of the initial vitriol that flows through us when we get upset. I found that sometimes a response wouldn't be necessary, as the importance was actually much lower than originally perceived, and I would be able to work "with", instead of "against", a given change.
Be forgiving and accept different priorities. The other person is not out to get you or attack your work. More often than not, it is one of the above (a-d) that are failing, or that the other person prioritize some aspect higher than you do. Sometimes, this requires compromises, sometimes not and the different priorities can co-exist.
Remember that everyone works on Apache projects as a volunteer. People have jobs and lives outside of their Apache projects, and may need more time to even read messages on the list or respond. Be patient.
Most communities at Apache consists of level-headed, reasonable people, who have a strong vested interest in their Apache project. This interest, often passion, is both the source of tension, but it is also what unites the people within the community. It is easy to forget the vast amount of agreement that exists, and get upset over relatively small disagreements. Ability to put that aside, or downplay the importance, will ensure a harmonious project.
Face-to-Face is excellent way to eliminate disagreements, but that is often not practical. Consider Skype or Google Hangout, just for the social aspect of being part of this community. It should not be formal, and the invitation should go out to everyone, perhaps someone want to make a short presentation of what he/she is doing, to have some "structure", but that might not be needed either. Once we have a face to the words, and a general idea how that person is socially, we are much more capable to interact by email.
Project decisions must always be made on mailing lists.
It's great to have a synchronous online chat to work through some questions, but
be sure to bring the results of the chat - and any proposals for the
project community to consider - back to the mailing list. People who
weren't able to attend the chat or call might also have ideas on the topic.
Be sure to allow at least 72 hours for others to read the proposals and
comment before closing out the issue.