Apache projects prefer to use consensus to make decisions, or use voting to more formally record approval (or not) for specific actions. But what happens when a project is at a complete impasse, or when you feel that important issues aren't being taken seriously or fully discussed before action is taken?
If any Apache project participant feels there are serious issues not being addressed, then here is a guide for effective ways to escalate your concern in the right way for the ASF's organization.
When major decisions can't be made in a project, or when individual contributors or part of a PMC believe that the project is not properly discussing critical issues, you may want to escalate the concern to see if there is other mediation help available.
The best way to get help from the rest of the volunteers here at Apache is to follow the steps below.
When communities disagree, it's important to clarify what the root issue is. There have been cases of long and heated discussion threads that turn out to be primarily about irrelevant issues or how proposals were phrased, and aren't actually about the problem at hand. Anytime an issue deserves escalation, it also deserves your time to clearly re-state the question at hand.
Clearly define one specific issue or problem, in terms that even someone outside the project could understand. Keep the conversation focused on one issue per thread. Don't assume that readers know the project history or have read every single mail in the past on the subject - include links where they show valuable discussions.
Provide URL references to Apache policies or best practices that show your case. Unwritten rules in one project may not apply to another project. Without specific references, it's hard to tell if something is truly a problem at Apache, or merely a disagreement wholly within one project (where escalating won't help). If you can't clearly show why the issue is important, or is breaking Apache policies, escalating won't help much.
Draft your email, save it, and wait overnight. Edit your work, and double-check that you're presenting your case in a calm, neutral, and factual manner. You're trying to help the community make the right decision; keep focused on what the right action for the project is, and don't focus on personalities (although sometimes you may need to raise issues about poor behaviors). Discussing the behaviors that may be affecting community health is good; raising issues about specific individuals rarely helps.
These steps may seem frustrating when the problem is recurring or has the obvious answer that you know is right! But in an all-volunteer led organization, re-framing the issue in clear terms with pointers is important so that the whole community has a chance to understand your specific point. We're all volunteers here, and not everyone in the community has the time to keep up on all conversations. Make it easy for the rest of the community to understand your case.
Before escalating outside of the relevant project, Incubator poding, or community, ask yourself: have I truly exhausted all avenues working within this community? Any issues within or about a project should be discussed with the project's own PMC as a whole on the dev@ (or private@) list first, before escalating outside of the project.
Double-check that you've expressed the issue clearly and calmly. Be sure to separate your discussion of what the issue is from what your suggestion for solving it is - it's not always clear to everyone in a busy project what the difference is.
Healthy Apache projects are expected to self-govern in an inclusive manner as much as possible. Whether it's an issue with internal project decisions, or a question of breaking Apache policies or best practices, the right place to start - and continue - the conversation is with the project's PMC.
When a serious issue involves an outside company (perhaps abusing a project's brand or processes), outside help may be needed. But any escalation of outside corporate influence or abuse should still be addressed to the PMC first to give them a chance to review.
Issues of top level PMC behavior, project governance, projects not following Apache policies, and the like should go to the Apache board@ private mailing list and cc: the relevant private@ list.
Issues of Incubator podling behavior, project governance, podlings not following Apache policies, and the like should go to the Apache Incubator general@ or private@ mailing list, and cc: the relevant private@podling list.
Issues with Apache Infra should first be escalated to the Infra Administrator directly. If that is not sufficient, only then escalate to VP, Infrastructure.
Any brand or trademark issues go to the Brand Management Committee on private lists and cc: the relevant private@ list.
Any issues of law or from lawyers go to the Legal Affairs Committee (on a private list if needed!)
Formal privacy, GDPR, or takedown requests go to the VP, Data Privacy.
Operations issues (fundraising, conferences, etc.) should go to the President and EVP; the Org Chart is helpful to see who reports to the President or the Board directly.
For more pointers, see the Services Available To Apache Projects listing. Note that the private members@ mailing list is never the right place to escalate project issues.
There are a few rare cases that may be exceptions to the above guide, depending on severity and urgency:
Any credible threats to personal safety should be escalated immediately to local law enforcement or emergency personnel. If you are at an ApacheCon or other ASF hosted event, contact the conference organizers or Planning committee as soon as practical by asking any event staff; elsewhere, please contact the ASF's President at president@apache.org.
Any legal summons or demands from legal counsel should be escalated immediately to the Legal Affairs Committee, so that the ASF's counsel can review for action.
Serious code of conduct violations where you are not comfortable working with the person in question directly may be escalated to the President or reporting volunteers directly.
The best place to ask general public questions not covered above is ComDev.