|
| 1 | +# **Coding Guidelines Subcommittee Meeting on 2026-02-11 @ 1700 CET / 1100 EDT** |
| 2 | + |
| 3 | +[Link](https://www.worldtimebuddy.com/?qm=1&lid=2643743,12,8,5&h=5&date=2026-2-11&sln=11-12&hf=1) to meeting time in common time zones. |
| 4 | + |
| 5 | +| Search Key | Description | |
| 6 | +| :---- | :---- | |
| 7 | +| \[todo\] | Action Item | |
| 8 | +| \[decision\] | Something decided on | |
| 9 | +| \[important\] | Key information | |
| 10 | + |
| 11 | +## **Agenda** |
| 12 | + |
| 13 | +1. Solicitation of notetaker |
| 14 | +2. Acceptance of [Previous Meeting Minutes](https://github.com/rustfoundation/safety-critical-rust-consortium/blob/main/subcommittee/coding-guidelines/meetings/2026-01-21/minutes.md) |
| 15 | +3. Introduction of new members |
| 16 | +4. Mention review/merge workflow issue (See [example](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/pull/302), [example](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/pull/402#issuecomment-3874829138)) |
| 17 | +5. Discuss change to meeting weekly at this time |
| 18 | +6. Discuss how to handle low-quality submissions (AI disclosure policy?) |
| 19 | +7. Review of open issues |
| 20 | +8. Review of open PRs |
| 21 | +9. Round table |
| 22 | + |
| 23 | +## **Check-in area** |
| 24 | + |
| 25 | +* Pete LeVasseur 🦀⛑️ |
| 26 | +* Oreste Bernardi 🥷 |
| 27 | +* Sam Wright 🏃 |
| 28 | +* Max Jacinto ✏️ |
| 29 | +* Markus Hosch 🦄 |
| 30 | +* William Barsse |
| 31 | +* David Svoboda (-: |
| 32 | +* Douglas Deslauriers ❄️ |
| 33 | +* Andreas Weis 👋 |
| 34 | +* Roberto Bagnara |
| 35 | +* Christof Petig 🦀 |
| 36 | + |
| 37 | +**Please add your name, and an emoji that describes your day.** |
| 38 | + |
| 39 | +**Notetaker:** |
| 40 | + |
| 41 | +* Markus Hosch |
| 42 | + |
| 43 | +For tips on how we take notes in the Safety-Critical Rust Consortium, please see the [Meeting Notetaker Role](https://github.com/rustfoundation/safety-critical-rust-consortium/blob/main/docs/notetaker-role.md) doc. |
| 44 | + |
| 45 | +## **Housekeeping section** |
| 46 | + |
| 47 | +* Document space: [coding-guidelines](https://github.com/rustfoundation/safety-critical-rust-consortium/tree/main/subcommittee/coding-guidelines) |
| 48 | +* Zulip: [safety-critical-consortium: Coding Guidelines](https://rust-lang.zulipchat.com/#narrow/channel/445688-safety-critical-consortium/topic/Coding.20Guidelines) |
| 49 | +* [Kanban board](https://github.com/orgs/rustfoundation/projects/1/views/3) |
| 50 | + * [`contributor experience`](https://github.com/orgs/rustfoundation/projects/1/views/4) view |
| 51 | + * [`coding guideline`](https://github.com/orgs/rustfoundation/projects/1/views/5) view |
| 52 | + |
| 53 | +## **Tasks** |
| 54 | + |
| 55 | +* Open PR to make review checklist more measureable |
| 56 | +* Open issue about AI policy |
| 57 | +* Open issue about how to deal with low quality submissions |
| 58 | + |
| 59 | +## **Meeting Minutes** |
| 60 | + |
| 61 | +* Hot potato handed over (aka notetaker) |
| 62 | +* Notes from previous meeting accepted |
| 63 | +* (Not so) new members introducing themselves (2 people) |
| 64 | +* Review of the merge workflow: |
| 65 | + * PR has been merged that documents the workflow, see https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/blob/main/CONTRIBUTING.md |
| 66 | + * Focus on first-time contributors |
| 67 | + * Q: What about the checklist for reviewers? Where will it be? Quick recap on the topic: How does a reviewer know that their duty is done? What’s the minimum standard on PRs? |
| 68 | + * A: Bot will post a review checklist. Example: https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/pull/370#issuecomment-3879379076 |
| 69 | + * Wording needs to be more precise, e.g. when is “appropriately” appropriate enough? Request: Open up a PR to make the wording more precise. |
| 70 | +* Change of meeting schedule. |
| 71 | + * It might be more interesting to have the same spot each week instead of a rotating time slot. Since participation from the Pacific region is rather low, this time slot will most likely be located such that it fits EUR / US. |
| 72 | + * In addition, there will be a meeting for the Pacific timezone once per month. New meeting schedule will be effective ~beginning of March. |
| 73 | + * Opinion: Current schedule emphasizes the global nature of the SCRC, might regress with the suggested schedule. |
| 74 | + * Experience was that attendance didn’t really build up after some month |
| 75 | + * Suggestion: Have a “champion” from the Pacific TZ run the meeting and decide on their own on the frequency. |
| 76 | + * Takeaway: Try to make the voices still audible, look for a champion |
| 77 | +* Low-quality and/or AI contributions: |
| 78 | + * TLDR: Do we need a policy about AI contributions? Some apparent(?) contributions appeared lately, how to deal with them? |
| 79 | + * Opinion: Why does it matter whether it’s AI or not? We should deal with the question how to deal with low-quality contributions |
| 80 | + * Seems that the tag “good-first-issue” is prone to AI bots |
| 81 | + * Opinion: AI is able to “flood” (by number of PRs or PR size), which is time consuming for reviewers, so we need to find a way to quickly deal with new PRs to not drown in slop |
| 82 | + * Opinion: Check how responses from the author look like to see whether we can expect improvements |
| 83 | + * Opinion: Adding the AI-tag doesn’t add a lot of value, since the “bad guys” will not do it anyway. Counteropinion: It helps using AI in a responsible way by having the good guys disclose the AI usage |
| 84 | + * Opinion: Refusing “too chatty” PRs will also remove some people from contributing since its their nature to not be concise. Rather count on “earned trust” when choosing reviews. |
| 85 | + * Opinion: Having to disclose whether AI was used would also “stigmatize” the use of things like grammar checkers |
| 86 | + * Opinion: Have a well-maintained checklist will help fight the flood by being able to quickly refuse things on a well-defined basis |
| 87 | + * Bottom line: Let’s focus on low vs. high quality and enforce this with the help of a good checklist & guidelines |
| 88 | + * Opinion: Labeling won’t be very helpful as “evil AI” won’t label itself anyway |
| 89 | +* Review of open issues |
| 90 | + * It is probably not obvious for reviewers that they have been assigned, as this is only one single comment in the respective PR |
| 91 | + * Not so easy to implement without giving a lot more people elevated rights |
| 92 | + * Suggestion: Use a search query with the bot’s message to find all “assigned” tickets |
| 93 | + * Improvements will be made to make people more aware of assigned reviews |
| 94 | +* Roundtable |
| 95 | + * US / EUR meeting slot will most likely stay Wed afternoon (CET) / late morning (US) |
| 96 | + |
| 97 | +## **Material** |
| 98 | + |
| 99 | +Any material to read before the meeting should be included here. |
| 100 | + |
| 101 | +* Milestone: [Prepare for launch to wider Rust community](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/milestone/1) |
| 102 | + |
0 commit comments