Skip to content

Commit 691d208

Browse files
StanFromIrelandhugovkezio-melotti
authored
Add September 2025 meeting minutes (#162)
Co-authored-by: Hugo van Kemenade <[email protected]> Co-authored-by: Ezio Melotti <[email protected]>
1 parent 9a45899 commit 691d208

File tree

2 files changed

+166
-0
lines changed

2 files changed

+166
-0
lines changed

‎docs/monthly-meeting/2025-09.md‎

Lines changed: 165 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,165 @@
1+
# Documentation Community Team Meeting (September 2, 2025)
2+
3+
## Roll call
4+
5+
(Name / `@GitHubUsername` *[/ Discord, if different]*)
6+
7+
- Ryan Duve / `@ryan-duve`
8+
- Hugo van Kemenade / `@hugovk`
9+
- Carol Willing / `@willingc`
10+
- Adam Turner / `@AA-Turner`
11+
- Lufti Zuchri
12+
- Irvan Putra / `@irvan-putra` / `irvan.putra`
13+
- Jacob Coffee / `@JacobCoffee`
14+
- Stan Ulbrych / `@StanFromIreland`
15+
16+
17+
## Discussion
18+
19+
- [Hugo] What's the latest on the language mix-up? Do we know any translations
20+
that still have the wrong language? Are there remaining languages that need
21+
updating and CI unpausing?
22+
23+
- [Adam] At least Japanese not yet unpaused. No update on
24+
[python-docs-translations/transifex-automations#155](https://github.com/python-docs-translations/transifex-automations/issues/155).
25+
26+
- [Hugo] Let's follow up on Discord.
27+
28+
- [Carol] Let's have an hour session at the core sprint in two weeks so we all
29+
understand the workflow.
30+
31+
- [Petr] Paid Transifex plan for translations: [python/steering-council#297](https://github.com/python/steering-council/issues/297)
32+
33+
- [Hugo] Transifex is approved for one year. How can we evaluate its use towards the end of the year?
34+
35+
- [Hugo] Pycon Greece had a good talk. Not using any web tools.
36+
Teaching people how to use Git/GitHub and get involved in open source.
37+
Spanish is similar.
38+
39+
**Action: Hugo to share link**
40+
41+
- [Adam] Also evaluated Weblate, it was around 5% less, but would involve
42+
migrating all translations to a new platform, with added social cost.
43+
44+
- [Carol] Suggests that by the end of the year evaluate CIs, and by PyCon US
45+
evaluate if there are improvements for users, are they finding value,
46+
and in what. Compare paid vs. unpaid. Gives us another quarter to evaluate
47+
whether to go back to unpaid.
48+
49+
- [Adam] Yes, each team has been working independently. There are benefits of
50+
translating with similar tools and tech, for reducing workload and sharing
51+
things. For teams that are currently using Transifex, hope we can evaluate
52+
and see if we can bring in other teams to see if Transifex helps them.
53+
54+
- [Carol] Lysandros from the Greek team spoke at the last
55+
[Language Summit](https://pyfound.blogspot.com/2025/06/python-language-summit-2025-docs-editorial-board.html>)
56+
about it and how to come up with best practices.
57+
58+
- [Adam] Stan's recent split in the devguide really helped.
59+
60+
- [Indonesian docs coordinators] We're trying to work out how to add a workflow
61+
to support contributions via both Transifex and GitHub. Have any other
62+
communities done this, or does it tend to be an all or nothing approach with Transifex?
63+
64+
- [Stan] This has not been done yet, successfully.
65+
66+
- [Lufti] Cannot sync two ways. What's the best practice?
67+
68+
- [Stan] No existing solution - will need to set up a workflow, but could cause problems.
69+
70+
- [Lufti] Not mandatory, so can do own thing for now.
71+
72+
- [Stan] [Transifex documentation](https://developers.transifex.com/docs/cli) describes commands for pushing translations
73+
74+
- [Irvan] When adding new translators, 50% like to use GitHub, and 50% like to use Transifex.
75+
Those using Transifex are not communicating with others.
76+
User experience at Transifex is not that good, but still looking to use.
77+
Haven't decided which approach yet.
78+
The diff conflicts if people modify the same file in different places.
79+
80+
- [Stan] To contact translators on Transifex, you can use the [built-in forum](https://app.transifex.com/python-doc/teams/5390/discussions/)
81+
82+
- [Hugo] Recommends using just GitHub or Transifex.
83+
Recommends coordinators decide which works best for them, can include the
84+
translation team, but coordinators decide.
85+
Then they communicate it to the team.
86+
Find a way of communicating that works, maybe the forum Stan mentions,
87+
or mailing list, or Discord, or whatever.
88+
We can create a dedicated channel if needed.
89+
90+
- [Irvan] Someone just joined Transifex and contributed, we don't know who they are.
91+
92+
- [Stan] This is also a benefit of Transifex, it advertises the project for us.
93+
There are many people who translate open source projects on the platform.
94+
95+
96+
- [Hugo] [Removing non-HTML (PDF, EPUB, etc) documentation downloads](https://discuss.python.org/t/removing-non-html-pdf-epub-etc-documentation-downloads/101343)
97+
98+
120 voters:
99+
100+
| Option | Percentage |
101+
|--------------------------------------------------|------------|
102+
| I don’t care / I only use HTML / show results | 47% |
103+
| Remove all non-HTML downloads | 36% |
104+
| Keep the status quo (HTML, PDF, EPUB, and so on) | 12% |
105+
| Remove PDF downloads | 5% |
106+
| I don’t read/use Python’s documentation | 0% |
107+
108+
If we bucket the top result as happy to remove any non-HTML
109+
(because there's a separate button to show results):
110+
111+
| Option | Percentage |
112+
|--------------------------------------------------|------------|
113+
| Remove all non-HTML downloads | 87% |
114+
| Remove PDF downloads | 52% |
115+
| Keep the status quo (HTML, PDF, EPUB, and so on) | 12% |
116+
117+
- [Adam] Thinks we should discount the 47%.
118+
Reticent to entirely remove PDF because there have been notionally valid use
119+
cases, although skeptical of some — some said the PDF is a single file, but it's not.
120+
Don't want to remove and cause unnecessary harm.
121+
By far PDF is the biggest drain. The other one is for emacs.
122+
From a resource perspective, I would like to remove them. But I am in two minds.
123+
Releases also include these docs.
124+
Find most docs bugs normal build, don't want to run into those on release day.
125+
126+
- [Carol] Could see PDF or EPUB being useful in certain circumstances.
127+
Is it ok just to build it when something is released? To not do backports on them?
128+
In the science world, many have been dropping PDFs as they are time-consuming
129+
and a pain.
130+
For the dev branch, maybe build nightly or what the Release Manager thinks
131+
is most useful.
132+
133+
- [Adam] Now built three times per month. PDF and EPUB are kind of similar,
134+
EPUB is much simpler, it is a load of XHTML in a zip, and takes like two mins.
135+
PDF is hours for latex stuff. Potentially drop it, and 3.15 or 3.16 will have
136+
no PDFs, and we can see if people complain. If genuinely useful in places
137+
with worse internet, don't want to force people to create environments for
138+
PDF generation — it's not easy.
139+
140+
- [Adam] Suggestion: for beta, turn off PDF for what will become 3.16.
141+
If we are to announce now, that's at least six months of lead time.
142+
Don't know if we are overthinking the fallout of doing it.
143+
Discourse/poll is populated by very online people and is not going to capture real users.
144+
145+
**ACTION: hook up Plausible to downloads**
146+
147+
- [Jacob] Docs nightly load avg has started causing outages ~nightly around
148+
01:00CST (~0500, 0600 UTC). Would like to work with someone to remediate.
149+
Shared in Datadog with those that had accounts available (Adam, Hugo, Carol).
150+
Started on Aug. 5th, continues sporadically (sometimes every 2 days, sometimes 9 days.)
151+
152+
- **ACTION: Hugo+Adam to help**
153+
154+
155+
- [Adam] discussion about splitting pages. Any opposition to just starting with
156+
simpler, standalone sections? Had a start a couple of times, never gotten to the PR stage.
157+
158+
- [Carol] Do we have a list of target pages?
159+
160+
- [Adam] Going by longest pages. Start with stdtypes and functions.
161+
For example, could move all the string methods to their own page.
162+
163+
- [Adam] Long ones: datamodel, typing, logging cookbook, and so on.
164+
165+
- [Carol] Maybe logging cookbook could be a good start?

‎docs/monthly-meeting/index.rst‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -25,3 +25,4 @@ Monthly reports in chronological order.
2525
Jun 2025 <2025-06.md>
2626
Jul 2025 <2025-07.md>
2727
Aug 2025 <2025-08.md>
28+
Sep 2025 <2025-09.md>

0 commit comments

Comments
 (0)