-
Notifications
You must be signed in to change notification settings - Fork 1
Add Board Roles and Projects pages #41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,91 @@ | ||
| --- | ||
| title: "Board Expectations & Roles" | ||
| url: "/expectations" | ||
| summary: "What we expect of Editorial Board members, and how the board operates." | ||
| hideMeta: true | ||
| ShowToc: true | ||
| TocOpen: true | ||
| --- | ||
|
|
||
| > **Status: Draft.** This page is a work in progress, started following the | ||
| > [June 2026 meeting](/updates/2026-06-09/). It describes what we expect of | ||
| > Editorial Board members and how the board chooses to operate. Comments and | ||
| > suggestions are welcome via an [issue](https://github.com/python/editorial-board/issues/new/choose). | ||
|
|
||
| ## Purpose | ||
|
|
||
| The Python Documentation Editorial Board exists to maintain and improve the | ||
| quality of Python's documentation, as established in | ||
| [PEP 732](https://peps.python.org/pep-0732/). PEP 732 defines our mandate, | ||
| scope, responsibilities, and membership rules; this page does not restate the | ||
| PEP but instead records how the board chooses to work within it. | ||
|
|
||
| ## How we work: proactive, not just reactive | ||
|
|
||
| The board considered three possible stances for how members spend their time: | ||
|
|
||
| 1. **Reactive** — be available to make big decisions when asked (act like a | ||
| "Steering Council for docs"). | ||
| 2. **Hands-on** — start and personally carry out significant work (closer to a | ||
| core-team contributor role than a council role). | ||
| 3. **Proactive** — identify big documentation projects, reach out to find | ||
| people to do the work, and lead/shepherd those efforts. | ||
|
|
||
| **We have chosen to focus on stance 3.** Rather than waiting for issues to be escalated to | ||
| us, the board will actively identify significant documentation work, find and | ||
| support contributors to take it on, and project-manage those efforts to | ||
| completion. | ||
|
|
||
| We remain available for the reactive decision-making in stance 1 — when the | ||
| community needs the board to make a big-picture or tie-breaking decision about | ||
| the docs, we are here to do so. In practice, though, this has rarely been | ||
| needed: most documentation questions resolve without the board having to step | ||
| in. Because that reactive load is light, our primary focus is the proactive | ||
| work described above. | ||
|
|
||
| What this means in practice: | ||
|
|
||
| - We maintain a [list of projects](/projects/) that we believe are worth doing. | ||
| - A project is listed **only if there is a committed lead** for it. The list is | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. When we say that all listed projects must have a committed lead, do we mean that we require all listed projects to have a project manager or just an EB board member associated with it? I like the idea of only requiring listed projects to have an EB member committed to it. That way, potential project leads have something concrete to say yes to. |
||
| not a wish list — every entry has someone accountable for moving it forward. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this contradicts the above, is it not the EB that is going to "lead/shepherd [these] efforts," or am I misunderstanding the above?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a good question. In our discussion, we meant that the EB members would lead projects themselves, but this sentence doesn't actually say that. I'm not sure we should require an EB member to be the lead. Whatever we decide, we should be clear. How about: Perhaps we should also say that someone from the EB will be associated with each active project, if only as an "executive sponsor" or something.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I also would agree that non EB members can be project lead and have an EB member to be a sponsor, and that there should also be regular checkins between the sponsoree and the EB sponsor. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree that it makes most sense that each project will have an EB member associated with it, either as a sponsor or a project lead. |
||
| - Each project is described with enough detail to be actionable, including the | ||
| challenges and risks involved, not just the desired outcome. | ||
| - We hold ourselves to project-managing these efforts, not merely naming them. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Here is where the EB member is described as the project lead. Whatever we decide above, this sentence needs to match. |
||
|
|
||
| ## Member expectations | ||
|
|
||
| Members of the Editorial Board are expected to: | ||
|
|
||
| - Attend the monthly board meeting (second Tuesday, 1:30pm Pacific) where | ||
| possible, and stay engaged asynchronously on Discord between meetings. | ||
| - Help identify and prioritize documentation projects. | ||
| - Lead or actively shepherd at least one project, or support fellow members | ||
| who are leading projects. | ||
| - Engage constructively with the wider documentation community (the | ||
| [Documentation Working Group](https://github.com/python/docs-community), | ||
| translation teams, and contributors). | ||
| - Confirm annually whether they wish to continue serving, per PEP 732. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. At the top: "this page does not restate the But this sentence is restating the PEP. Perhaps delete? |
||
|
|
||
| ### What it means to lead a project | ||
|
|
||
| _TODO: define the commitment expected of a project lead — e.g. defining scope, | ||
| breaking the work into contributable pieces, recruiting and supporting | ||
| contributors, reporting progress to the board, and seeing the work through._ | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also: recognizing when a project isn't working out, and wrapping it up even though it wasn't done. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would add these tasks to the beginning of the list of tasks owned by an EB member associated with a project:
I'm thinking that someone could come up with an idea, come to a general consensus with the rest of the EB on the broad strokes, and then go off to make it happen with docs community members. After that, the EB member who owns the project could keep the rest of the EB in the loop or ask for input as issues arise. |
||
|
|
||
| ## Joining the board | ||
|
|
||
| The process for filling a vacancy is defined in PEP 732 under | ||
| [Editorial Board Member Qualifications](https://peps.python.org/pep-0732/#editorial-board-member-qualifications): | ||
|
|
||
| > If a vacancy exists on the board for any reason, the Documentation Editorial | ||
| > Board will publicly announce a call for prospective board members. | ||
| > Prospective board members would submit a brief document stating | ||
| > qualifications and their motivation to serve. The sitting members of the | ||
| > Editorial Board will select new board members by a simple majority where | ||
| > quorum is 80% of the current board. | ||
|
|
||
| Before opening a call for new members, the board will publish clear | ||
| expectations (this page) so prospective members understand what they are | ||
| signing up for. | ||
|
|
||
| _TODO: link to the application form / call for members once it is open._ | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,84 @@ | ||
| --- | ||
| title: "Projects" | ||
| url: "/projects" | ||
| summary: "Documentation projects the Editorial Board is leading or shepherding." | ||
| hideMeta: true | ||
| ShowToc: true | ||
| TocOpen: true | ||
| --- | ||
|
|
||
| > **Status: Draft.** This page is a work in progress, started following the | ||
| > [June 2026 meeting](/updates/2026-06-09/). | ||
| This is the Editorial Board's list of significant documentation projects we are | ||
| actively leading or shepherding. It reflects our | ||
| [proactive stance](/expectations/#how-we-work-proactive-not-just-reactive): | ||
| rather than only reacting to requests, we identify important work and find | ||
| people to carry it out. | ||
|
|
||
| ## How this list works | ||
|
|
||
| - **Every project has a committed lead.** This is not a wish list. A project is | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. When we say that all listed projects must have a committed lead, do we mean that we require all listed projects to have a project manager or just an EB board member associated with it? I like the idea of only requiring listed projects to have an EB member committed to it. That way, potential project leads have something concrete to say yes to. |
||
| added only when someone has agreed to lead it. If a project loses its lead, it | ||
| moves to [Parking lot](#parking-lot) until a new lead steps up. | ||
| - **Each project names its challenges**, not just the goal. Describing the | ||
| hard parts up front helps contributors know what they are taking on. | ||
| - **We keep the list short and prioritized** rather than long and | ||
| aspirational, so we can give each project real oversight. | ||
|
|
||
| Want to help with a project, or propose a new one? Open an | ||
| [issue on this repo](https://github.com/python/editorial-board/issues/new/choose) | ||
| or reach out in the [Python Docs Discord](https://discord.gg/nXkJ2JYvCu). | ||
|
|
||
| ## Project template | ||
|
|
||
| Once a project is approved by the Editorial Board, copy this block to add a new project. | ||
|
|
||
| ```markdown | ||
| ### <Project name> | ||
|
|
||
| - **Lead:** <name — required; no lead, no listing> | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We'll need to change this to "EB sponsor" if we decide that having an EB sponsor is enough to start a project. We could follow this process:
That way, when an EB member commits to a project, they are committing to be a project lead if necessary but will first try to recruit a project lead from the community. We would need to set a time limit for recruiting a project lead from the community. |
||
| - **Status:** Proposed | Active | Blocked | Done | ||
| - **Summary:** One or two sentences on what this project delivers. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't see a reason to limit this to two sentences. Or leave this as-is, but also add a "Description" section that can be longer with as much detail as needed. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like the idea of having both a short summary and a complete description. The short summary shows that there is a "there" there. The complete description lets contributors know what they're in for. |
||
| - **Why it matters:** Who benefits and why this is worth doing now. | ||
| - **Challenges / risks:** The hard parts — technical blockers, dependencies, | ||
| unknowns, things that could derail it. | ||
| - **How to help:** Concrete ways a contributor can get involved. | ||
| - **Links:** Relevant issues, PRs, discussions, or docs. | ||
| ``` | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we want to add acceptance criteria to the project definition? It could make the project definition more concrete and helpful for people who haven't yet osmosed enough information about Python's docs to fill in the gaps themselves. |
||
|
|
||
| ## Active projects | ||
|
|
||
| _None listed yet. Add projects here using the template above._ | ||
|
|
||
| <!-- | ||
| Example seeded from recent meetings — fill in a committed lead before promoting | ||
| to "Active": | ||
| ### Split up the datetime documentation | ||
| - **Lead:** _TBD — needs a committed lead_ | ||
| - **Status:** Proposed | ||
| - **Summary:** Break the large `datetime` reference page into more focused | ||
| pages, and move the strftime/strptime format codes to their own page. | ||
| - **Why it matters:** `datetime.rst` is among the ten largest files in the docs; | ||
| it mixes reference and tutorial-style content. More focused pages improve | ||
| navigation, SEO, and discoverability (including by LLMs). | ||
| - **Challenges / risks:** Existing external links will break — depends on the | ||
| redirect mechanism being worked on in the Docs WG (Petr). Some readers value | ||
| a single page they can Ctrl-F (per feedback from Paul Ganssle). Needs | ||
| coordination with in-flight PRs (#125009, #132524) and with Stan. | ||
| - **How to help:** Help define the page split, draft an overall tutorial, | ||
| separate reference from tutorial content. | ||
|
Comment on lines
+62
to
+72
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Leaving this note here since there isn't an issue or other clear place to do it. I've also been thinking about this for a while, especially with the recent update to the format codes.
This is interesting, but it would disconnect them from their APIs, which I would find a little odd. However, the table also applies to
I think the current structure is reasonable: we introduce an object, cover its API in detail, and follow with a small cookbook
I opened a PR for this: python/cpython#151113 :-)
I'm not sure a tutorial is the best use of our limited time. There are many tutorials on the internet already, I don't think an "official" one will be particularly special.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a great example of the kinds of difficult decisions that have to be made for projects that seem simple at first glance. I'm a proponent of doing the work a few times and being thoughtful about the decisions being made along the way, then ideally codifying those decisions as guidelines that others can follow to make future changes easier. |
||
| - **Links:** | ||
| - https://docs.python.org/3/library/datetime.html | ||
| - https://github.com/python/cpython/pull/125009 | ||
| - https://github.com/python/cpython/pull/132524 | ||
| --> | ||
|
|
||
| ## Parking lot | ||
|
|
||
| Ideas worth doing that do **not** yet have a committed lead. These are not | ||
| active projects until someone steps up to lead them. | ||
|
|
||
| _Empty for now._ | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"and either sponsor or project-manage those efforts"