docs(governance): add access review policy and community onboarding documents

[m-hajjo]

Summary

Adds one policy and three community documents under Governance/, closing the governance gaps tracked in #1501, #1502, #1503, and #1504.

Document	Closes	Covers
policies/ACCESS_REVIEW.md	#1501	Review cadence, scope per review, revocation process
community/MENTORSHIP_PROGRAM.md	#1502	Matching, expectations, duration and review
community/AMBASSADOR_PROGRAM.md	#1503	Responsibilities, selection, recognition
community/WELCOME_GUIDE.md	#1504	First steps, key resources, where to get help

What these documents add

Access review as a scheduled job. Access is granted to people who need it and then kept because removing it is nobody's job; a review with a cadence is that job. The cadence varies by consequence — repository admin, store accounts, EAS credentials, workflow secrets, and service accounts are reviewed quarterly, elevated roles every six months, ordinary contributor access annually — with dormancy as an off-cycle trigger. Each review asks whether the person is still in the project, whether the level still matches the role, and whether the grant had authority behind it. Two points worth flagging: the review works from the Access Register, and a resource not in the register is treated as a finding, because either the register is incomplete or the access is unowned. And the review checks the reverse case too — that nobody lacks access their role requires, since a person blocked from doing their job is as much a defect as one who can do too much.

Revocation is applied at the source. Access is removed on the platform, not merely annotated in the register; any credential the person held is rotated because they may still hold a copy; and the reviewer confirms the access no longer works rather than assuming the platform honoured the change. An account with no activity and no owner is removed rather than retained "in case it is needed" — that phrase is called out as the mechanism by which unowned access persists for years.

Mentorship with defined ends. Matching is driven by the mentee's stated need, with language and timezone as accessibility considerations rather than afterthoughts, and both parties confirm the match. Expectations are stated for both sides, including what a mentee can expect from the first review — more explanation than a standard maintainer review — and what neither side can expect: unpaid production work, authority, or a guaranteed outcome. The program has a four-week initial cycle extending to three months, with structured written check-ins at week 4 and month 3. The check-in deliberately asks whether a blocker is a mentoring gap or something else, because when it is something else the fix is an environment problem or a language barrier, not a better mentor. A high rematch rate is named as a defect in matching rather than in the people matched.

Ambassadors with explicit limits. The value here is the "may and may not" table. Ambassadors can answer from the documentation, describe the project accurately, and say "I do not know"; they cannot promise a feature or a date, disclose non-public information, handle a conduct report, or speak on the project in a personal dispute. Selection is on demonstrated helpfulness with evidence cited — explicitly not on reach or follower count — and the program states plainly that it pays nothing and absorbs no obligation to support the project. Two safeguards are called out: withdrawal of the title is a decision under the existing Privilege Revocation Policy and is recorded, and a genuine good-faith conduct report about an ambassador goes through the reporting process rather than quietly removing the title.

A welcome guide that is honest. First steps in order, then resources worth reading before starting — with NON_GOALS.md placed early, because a well-written contribution that does something the project decided not to do will be declined, and knowing that first is kinder than finding out at review. It sets expectations directly: review takes time, the first pull request will get comments, some requests will be declined, merging is not the only useful outcome, and no permission is needed to start. Security concerns are routed to the private channel from the guide itself, before a newcomer's first issue.

Notes for reviewers

• The mentorship program extends rather than contradicts existing onboarding. processes/ONBOARDING.md#mentor-program already specifies a volunteer basis, one hour per week for four weeks, matching by interest area, and extra care on a mentee's first three pull requests. MENTORSHIP_PROGRAM.md builds the full program on those commitments and links back to them, rather than restating them with different numbers.
• Cross-references keep existing governance authoritative. Contribution norms stay in the Contributor Agreement, DCO, and sign-off policies; press enquiries in the Press and Media Policy; governance representation in the Representation and Speaking Policy; moderation authority in the Moderator Role — none of which ambassador status implies.
• Forward references. WELCOME_GUIDE.md links to REVIEW_ETIQUETTE.md, which is being added in the companion community-and-assurance pull request, and to ../policies/SUPPORT.md from the lifecycle pull request. The links resolve once those land; they are included so the newcomer path is navigable end to end, and can be dropped if you prefer each pull request to stand alone.
• Enforcement status is stated in the policy. No automation enumerates access across systems or tracks review dates; the register is the evidence base. The community documents are human arrangements with no automated component, and the welcome guide is reviewed every 12 months or whenever onboarding changes — a welcome guide describing the old process is an obstacle rather than a welcome.
• Scope. Each issue adds exactly one new file inside Governance/. No application code, CI, or configuration is touched, and no tests are added or changed.

Closes #1501
Closes #1502
Closes #1503
Closes #1504

[drips-wave]

@m-hajjo Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[RUKAYAT-CODER]

Thank you for contributing to the project