Propose project goal to add a rustdoc team charter

src/2025h2/rustdoc-team-charter.md

@@ -0,0 +1,64 @@
+# Add a team charter for rustdoc team
+
+| Metadata         |                                                |
+|:-----------------|------------------------------------------------|
+| Point of contact | @GuillaumeGomez                                |
+| Teams            | <!-- TEAMS WITH ASKS -->                       |
+| Task owners      | <!-- TASK OWNERS -->                           |
+| Status           | Proposed                                       |
+| Zulip channel    | [#t-rustdoc][t-rustdoc]                        |
+
+[t-rustdoc]: https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc
+
+## Summary
+
+Over the next six months, we will do the following:
+
+ * Write the team charter in the rust-forge
+
+## Motivation
+
+Having a team charter will allow both rustdoc team members and non-members to have a document of reference when they want to know how to do something. It would also allow the rustdoc team to have well defined rules about what is expected of its members. And for non-members, it gives them indication on what's expected to be able to join the team.
+
+### The status quo
+
+Not having well defined written expectations leaves a grey area for everyone: non-members don't know what are the processes and members could potentially all have different ways to handle similar situations.
+
+### The next 6 months
+
+Writing the team charter.
+
+## Ownership and team asks
+
+> *This section lists out the work to be done and the asks from Rust teams. Every row in the table should either correspond to something done by a contributor or something asked of a team.*
+>
+> *For most goals, a single table will suffice, but you can also add subsections with `###`. We give several example subsections below that also demonstrate the most common kinds of goals. Remember that the items in the table only corresponds to what you plan to do over the next 6 months.*
+>
+> *For items done by a contributor, list the contributor, or ![Heap wanted][] if you don't yet know who will do it. The owner is ideally identified as a github username like `@ghost`.*
+>
+> *For items asked of teams, list ![Team][] and the name of the team, e.g. `![Team][] [compiler]` or `![Team][] [compiler], [lang]` (note the trailing `[]` in `![Team][]`, that is needed for markdown to parse correctly). For team asks, the "task" must be one of the tasks defined in [rust-project-goals.toml](../rust-project-goals.toml) or `cargo rpg check` will error.*
+
+| Task                          | Owner(s) or team(s) | Notes |
+|-------------------------------|---------------------|-------|
+| Write team charter            | rustdoc             |       |
+
+### Definitions
+
+For definitions for terms used above, see the [About > Team Asks](https://rust-lang.github.io/rust-project-goals/about/team_asks.html) page.
+
+* *Discussion and moral support* is the lowest level offering, basically committing the team to nothing but good vibes and general support for this endeavor.
+* *Author RFC* and *Implementation* means actually writing the code, document, whatever.
+* *Design meeting* means holding a synchronous meeting to review a proposal and provide feedback (no decision expected).
+* *RFC decisions* means reviewing an RFC and deciding whether to accept.
+* *Org decisions* means reaching a decision on an organizational or policy matter.
+* *Secondary review* of an RFC means that the team is "tangentially" involved in the RFC and should be expected to briefly review.
+* *Stabilizations* means reviewing a stabilization and report and deciding whether to stabilize.
+* *Standard reviews* refers to reviews for PRs against the repository; these PRs are not expected to be unduly large or complicated.
+* *Prioritized nominations* refers to prioritized lang-team response to nominated issues, with the expectation that there will be *some* response from the next weekly triage meeting.
+* *Dedicated review* means identifying an individual (or group of individuals) who will review the changes, as they're expected to require significant context.
+* Other kinds of decisions:
+    * [Lang team experiments](https://lang-team.rust-lang.org/how_to/experiment.html) are used to add nightly features that do not yet have an RFC. They are limited to trusted contributors and are used to resolve design details such that an RFC can be written.
+    * Compiler [Major Change Proposal (MCP)](https://forge.rust-lang.org/compiler/mcp.html) is used to propose a 'larger than average' change and get feedback from the compiler team.
+    * Library [API Change Proposal (ACP)](https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html) describes a change to the standard library.
+
+## Frequently asked questions