You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/monthly-meeting/2023-12.md
+23-29Lines changed: 23 additions & 29 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,51 +29,45 @@ Please take a second to read through it!
29
29
30
30
## Discussion
31
31
32
-
*[Ryan] standard library documentation reference and adding types to it in a structured way. For example, `collections.Counter.most_common` could be written
32
+
-[Ryan] Standard library documentation reference and adding types to it in a structured way. For example, `collections.Counter.most_common` could be written as `most_common(n: int) -> list[tuple[Any, int]]`.
33
+
-[Petr] ... or `list[tuple[KeyType, int]]`?
34
+
- This has been discussed. There was opposition to adding the types to the stdlib code itself.
35
+
-[Jim] I sometimes wish for more normative, less chatty module documentation:
36
+
- e.g. [*heapq* module](https://docs.python.org/3/library/heapq.html)
37
+
- e.g. old issue 29428 [*Doctest documentation unclear about multi-line fixtures*](https://bugs.python.org/issue29428)
33
38
34
-
most_common(n: int) -> list[tuple[Any, int]]
39
+
-[Petr] Use emoji to illustrate good and bad example commit messages
- Should we do this for PEPs? See [python/docs-community#22](https://github.com/python/docs-community/issues/22)
43
+
-[Hugo] See also [python/peps#3567](https://github.com/python/peps/pull/3567) for green/red sidebars for good/bad example code in PEPs
44
+
-[Jim] don't forget accessibility constraints when coming up with the style guide. For example, some readers are red/green colorblind. ✅/❌ are good in that they are legible even without color.
35
45
36
-
[Petr] ... or `list[tuple[KeyType, int]]`?
37
-
38
-
- this has been discussed. There was opposition to adding the types to the stdlib code itself.
39
-
-[JDLH] I sometimes wish for more normative, less chatty module documentation. e.g. [*heapq* module](https://docs.python.org/3/library/heapq.html). e.g. old issue 29428 [*Doctest documentation unclear about multi-line fixtures*](https://bugs.python.org/issue29428).
40
-
41
-
*[Petr] Use emoji to illustrate good and bad example commit messages
* Should we do this for PEPs? see [python/docs-community#22](https://github.com/python/docs-community/issues/22)
45
-
*[Hugo] See also [python/peps#3567](https://github.com/python/peps/pull/3567) for green/red sidebars for good/bad example code in PEPs
46
-
*[JDLH] don't forget accessibility constraints when coming up with the style guide. e.g. some readers are red/green colorblind. ✅❌ are good in that they are legible even without color.
47
-
48
-
*[Ryan] Thoughts about completing TOML->JSON conversion table: https://docs.python.org/3/library/tomllib.html#conversion-table and the TOML spec: https://toml.io/en/v1.0.0#spec
46
+
-[Ryan] Thoughts about completing TOML->JSON [conversion table](https://docs.python.org/3/library/tomllib.html#conversion-table) and [the TOML spec](https://toml.io/en/v1.0.0#spec)
49
47
50
48
51
49
## Reports and celebrations
52
50
53
51
- PEP 732 ("The Python Documentation Editorial Board") has been submitted to the steering council [python/steering-council#220](https://github.com/python/steering-council/issues/220)
54
52
55
-
-[Jim] FYI, Unicode Standard is changing form of authoritative standard documents from PDF to HTML, with corresponding change to document production tooling. If this is interesting I can provide more info. I am in the working group which is working on the new tooling.
53
+
-[Jim] FYI, Unicode Standard is changing form of authoritative standard documents from PDF to HTML, with corresponding change to document production tooling. If this is interesting I can provide more information. I am in the working group which is working on the new tooling.
* Analytics (Plausible) - CAM sent an e-mail, no reply yet
63
-
* CAM sent multiple follow-ups
64
-
* Hugo sent a follow-up two weeks ago
65
-
* Discussion on core dev Discord that is supportive
66
-
* Still no reply... :(
67
-
68
-
* As a beginner, what's a good starting point?
69
-
* There are some "easy" issues, although they can occasionally not be actually-easy.
70
-
* Interested in documentation, look at Diátaxis and make changes?
71
-
* Diátaxis is kinda abstract for newcomers.
60
+
-[Ege/Hugo/CAM] Analytics (Plausible) - CAM sent an e-mail (around late October), no reply yet
61
+
- CAM sent multiple follow-ups
62
+
- Hugo sent a follow-up two weeks ago
63
+
- Discussion on core dev Discord that is supportive
64
+
- Still no reply... :(
72
65
73
66
## Next meeting
74
67
75
68
The docs team generally meets on the first Tuesday of every month around 20:00-ish UTC.
76
-
*[JDLH] The first Tuesday of next month is 2 January. Will we be ready for this meeting on the day after New Year's Day? Answer: Basically yes; those who are ready will show up, others won't.
69
+
70
+
-[Jim] The first Tuesday of next month is 2 January. Will we be ready for this meeting on the day after New Year's Day? Answer: Basically yes; those who are ready will show up, others won't.
77
71
78
72
We have a recurring Google Calendar event for the meeting.
79
73
Let Mariatta know your email address and she can invite you.
0 commit comments