To provide "Advisors" - volunteers who come alongside a PMC to offer an outsider's perspective on the project, and advice to build their community.

This WG is in the STARTUP stage. No actual work has started, we're just debating what that work might look like. Please come join the conversation.

Meanwhile, there seems to be considerable objection to the name. The ComDev list has been asked to decide on a better name.

An Advisor must be an ASF member. They are preferably a member who has been around a while, and has some reason to be trusted as a mentor. You must not already be a member of the PMC you wish to sharpen. You must not have any adversarial reason to take on the role - a bone to pick, a corporate entanglement, or whatever.

An Advisor will subscribe to the project's mailing lists and mostly listen. They will comment constructively when they see something that may be improved or when they have useful suggestions for the community.

There may be rare situations in which specific unaddressed concerns may be escalated to the board.

See use-cases for possible categories of interest/involvement. See also red-flags for common signs of potential problems in a project.

Interactions by Advisors are at the pleasure of the PMC. You do not have any authority over the PMC.

The PMC must be allowed to say "no thank you" without providing any reason, and you must respect that decision, and not offer again unless invited.

When you subscribe to the private@ list, you MUST introduce yourself and state your purpose, complete with a link to THIS document. You MUST tell the PMC when you intend to report something back to either ComDev or the Board. You MAY announce yourself on the dev@ and other lists, a PMC member may introduce you, or you may just start participating.

We will also track, here, in this repository, which Advisor is observing which project.

All feedback must be a polite, positive, actionable suggestion, not merely a criticism or a "you're doing it wrong." You must suggest what the community should do, providing links to policy or best practice documents where applicable. Simply criticising is not welcome.

If you cannot operate in this fashion, then this role isn't for you.

(No, this isn't a contradiction to Transparent. Different audiences.)

All communications on private@ mailing lists are confidential. Sharing information you learned on those lists to anyone outside of the membership of the ASF is a severe breach of trust. Whenever possible, discussion should be on public lists; but sensitive issues need to remain confidential.

Do not ever cross-post between private lists with disjoint audiences. In general, this means don't forward content from a private list to anyone who is not an ASF member.

All reports on Advisors activity must be in sections, unless you have coordinated with the PMC to include it in their report.

You are a colleague - a peer. You are not in a position of authority. You cannot tell the PMC what to do. You are only an observer, and, at the indulgence of the PMC, advisor. Do not abuse this relationship.

Advisors are not just there to provide advice based on the best practices and rules of the Foundation. They are also there to learn from the project, and to bring back to ComDev and the Board the ways how many of the projects apply the rules and best practices in their practices and culture, taking into accounts individual project's needs and circumstances. This might lead to updating and adjusting the common understanding of the best practices and rules and how they apply in various circumstances, bringing the useful feedback to the Board and ComDev.

Advisors are encouraged to share their experiences and exchange best practices and ideas with each other, and to collaborate on the best ways to help the projects and to transfer best practices and experiences of the various PMCs between each other. They comdev mailing list and this repository where "whys" and a little "hows" of the best practices and rules are discussed and documented serve as as platform of this collaboration.

Just subscribe to dev@community.apache.org and add yourself to the list of advisors in this repository and describe your experience, skill and interests. Introduce yourself as a prospect Advisor in the dev@community.apache.org mailing list.

An Advisor must be an ASF member. This is because doing this job requires access to a projects private@ PMC mailing list. All ASF members already have this access.

Furthermore, an ASF member has already earned trust in the context of the ASF. Trust is transitive - that is, you may not know all members personally, but each member was nominated and elected by people that you, in turn, nominated and elected.

There is no real formal process for this. As an advisor, you may simply start participating in the project's mailing lists (dev and/or private) after introducing yourself and asking if this is fine for you to become an Advisor.

The relationship is between the PMC and Advisor, no other offices are involved except the Board letting the PMC know that they can have an Advisor if they want one and the usual way Advisors or PMCs can reach out to other offices and groups (Trademarks, Legal, etc.) if they need to understand specific policies or procedures.

The PMC must be allowed to say "no thank you" without providing any reason, and you must respect that decision, and not offer again unless invited. The Advisor role is not a formal advised PMC role, it's a ComDev role and the PMC is not obliged to have an Advisor.

You can also be invited by the PMC to become an Advisor. In this case just add the PMC to the list of PMCs you advise.

The ASF Board can also - during regular Board project review process - identify a project that could benefit from an Advisor, and ask the PMC to consider inviting an Advisor, and cc: dev@community.apache.org mailing list to make the advisors aware of such a project (which might also initiate a voluntary Advisor to step up and offer their help). In general the PMC should be allowed to decide whether they want an Advisor, and who that Advisor could bem but if any Advisor is interested in a project, they are encouraged to reach out to the PMC and offer their help.

In neither case, the Board is appointing an Advisor. The Board is only asking the PMC to consider inviting an Advisor, and cc: the dev@community.apache.org mailing list to give the opportunity for the interested Advisors to step up and volunteer to help the project.

The side-effect of an Advisor being involved in a project is that it might make it easier for the Board Members who review project activity to understand the project's context and health by looking at the discussions that the Advisor is involved in - hence the list of Advisors in this repository can be a helpful guideline for the Board Directors when they are reviewing project reports.

You may stop being an Advisor at any time. You should let the PMC know on their list - usually with a [NOTICE] email. You do not need to provide any reason for stepping down, however usually by that time you will have built up a relationship with the PMC and it would be polite to explain why you are stepping down. It's up to PMC if they want to ask for another Advisor, also you might suggest another Advisor to take over your role if you see a good fit among your peers and you discussed it with them.