Skip to content

Commit 43b19f8

Browse files
Apply suggestions from code review
Co-authored-by: Ege Akman <[email protected]>
1 parent 18e56ab commit 43b19f8

File tree

1 file changed

+23
-29
lines changed

1 file changed

+23
-29
lines changed

docs/monthly-meeting/2023-12.md

Lines changed: 23 additions & 29 deletions
Original file line numberDiff line numberDiff line change
@@ -29,51 +29,45 @@ Please take a second to read through it!
2929

3030
## Discussion
3131

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)
3338

34-
most_common(n: int) -> list[tuple[Any, int]]
39+
- [Petr] Use emoji to illustrate good and bad example commit messages
40+
- https://devguide.python.org/getting-started/git-boot-camp/#accepting-and-merging-a-pull-request
41+
- [python/devguide#1235](https://github.com/python/devguide/pull/1235)
42+
- 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.
3545

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
42-
* https://devguide.python.org/getting-started/git-boot-camp/#accepting-and-merging-a-pull-request
43-
* [python/devguide#1235](https://github.com/python/devguide/pull/1235)
44-
* 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)
4947

5048

5149
## Reports and celebrations
5250

5351
- 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)
5452

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.
5654

5755
## Follow-ups from previous meeting(s)
5856

59-
* [Petr] [Railroad diagrams](https://discuss.python.org/t/36709/20)
60-
* Streams have kinda been on other topics too
57+
- [Petr] [Railroad diagrams](https://discuss.python.org/t/36709/20)
58+
- Streams have kind of been on other topics too
6159

62-
* 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... :(
7265

7366
## Next meeting
7467

7568
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.
7771

7872
We have a recurring Google Calendar event for the meeting.
7973
Let Mariatta know your email address and she can invite you.

0 commit comments

Comments
 (0)