T-style triage meeting 2023-10-04

--- title: T-style triage meeting 2023-10-04 tags: T-style, triage-meeting, minutes date: 2023-10-04 discussion: https://rust-lang.zulipchat.com/#narrow/stream/346005-t-style/topic/meeting.202023-10-4 url: https://hackmd.io/FNY_eJwyRMCcbC-tMo2B5w --- # T-style meeting agenda - Meeting date: 2023-10-04 ## Attendance - Team members: Jane, Caleb, CE - Others: TC ## Meeting roles - Facilitator: Jane - Minutes: TC ## Check-in (Not minuted.) ## Scheduled design meetings None. Update these [here](https://github.com/orgs/rust-lang/projects/38/views/1). ## Proposed design meetings None. Update these [here](https://github.com/orgs/rust-lang/projects/38/views/1). ## Announcements or custom items (Meeting attendees, feel free to add items here!) ### Talk about system for agenda setting Caleb: I'd like to request a 5 minute timebox addition to the meeting agenda for orientation around how this works (though I won't be offended if i'm the only one in the dark and folks would prefer we use the 5 minutes for something else). Caleb: ...and to be clear, the question is not how the bot works, but what the flow/process is for going into these meetings as we move forward. TC: (Discussion of the structure and intent of this agenda, the triagebot system, how this is used by other teams, etc.) Caleb: No objections. Makes sense how this would play out and connect to prior discussions. CE: +1. Jane: No objections. Maybe the format is harder to engage with because it's spread out over the document. I'm excited about automated agendas. TC: Note that HackMD can collapse headings. There are some tradeoffs here. Having it a bit more spread out is better for the minutes; both for taking them and for the end result. Caleb: What's the process for using triagebot to generate this? Jane: It'd be hitting a URL. Caleb: Should we update the policy documents? Jane: We could wait until the triagebot changes are merged so we can include the URL in the policy. But yes, the policy has a lot of language that will be out of date, so we should update that. Caleb: Could some else clone the repo and run it locally? TC: Yes, the branch is linked in Zulip, and it can be run. Caleb: We may want to revisit the roles for coming up with an agenda. Jane: +1. Caleb: Echoing what Jane mentioned, it'd be nice to have a bullet-point list. But that may be difficult technically. Caleb: Do we still need the other HackMD document? TC: No. That will be a historical document once we cover the TODO items in the agenda here to ensure that all of the action items and backlog items are converted to issues and nominations. *Consensus*: Let's move forward with this system. ### Confirm backlog items are in GitHub issues TC: We wanted to move all backlog items to GitHub issues. Do we have anything more to do here? https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A?both#Backlog Jane: I propose we do this async. Caleb: How do we make sure this doesn't slip through the cracks if we do it async? Caleb: I'll go through all the backlog items and make a suggestion on Zulip on whether it's something that should be converted or dropped. TC/Jane: +1. *Consensus*: Caleb will go through the backlog items and post to Zulip suggestions about what should be converted to issues or dropped. ## Action items review https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A?both#Action-Items (TODO: Move remaining items to GitHub issues.) Jane: I'm hoping I should be able to follow-up with Jack today. Jane: Creating a tracking issue for the 2024 style edition, I still need to do that. Caleb: The RFC to create the WG for the edition probably supersedes the action item for me. Let's drop it. Caleb: The other two, PRs are not opened yet. TC: How do we move these to action items? Caleb: I'll handle it along with the backlog items. All: Thanks Caleb. *Consensus*: Caleb will go through the action items and convert them to issues or raise them for discussion on Zulip. ### Completed * Caleb: Ask Jack to determine when the project is planning to ship 2024 edition and share info back with T-style * Jane asked/communicated this synchronously with Jack, answer/result pending ## Nominated RFCs, PRs, and issues ### "[style edition 2024] Combine all delimited exprs as last argument" rust#114764 **Link:** https://github.com/rust-lang/rust/pull/114764 Caleb: When people have checked their boxes when there are open questions on the PR, what does that mean? Jane: For my part, I checked my box before the questions, and I haven't checked in recently. TC: As a matter of process, if a team member feels that a question raised on the PR rises to the level that the PR should not move forward until that point is addressed, a team member can adopt that point by raising a **concern** on the PR. The PR can't move forward when there are open concerns from team members. Caleb: I'll do that. I think there concerns are addressable with some small changes. Jane: Do we want to unnominate? Caleb: What are the implications? TC: If we want to see this again next week and keep this on our radar, then it should remain nominated. Otherwise, it should be unnominated. Caleb: We can keep track of this some other way. *Consensus*: Let's remove the nomination. ## Pending PRs on the style-team repo ### "Clarify empty match arm format" style-team#147 **Link:** https://github.com/rust-lang/style-team/pull/147 Caleb: I feel like we can close this. We have duplicate items on this. Caleb: I'll close it. *Consensus*: We'll close this issue. ### "Add team membership characteristics section" style-team#182 **Link:** https://github.com/rust-lang/style-team/pull/182 Jane: This is blocked on me talking with Josh. CE: I'm disappointed that this has taken so long. This goes back to what I want to write about expectations of team members. What can we do to move this forward? Caleb: I hear you. I've had similar feeling in the past. I do want to prioritize these issues about the team itself. Jane: I hear your frustration also. CE: To clarify, it's OK to have strong opinions, and it's OK to be unavailable, but it's less OK to do both at the same time. TC: In open source, as in many things, decisions get made by the people that show up. That's often a virtue. Of course there are limits; some things do need the attention of everyone even if that means waiting. But on the T-lang side, reversible decisions about the handling of many things are often taken based on the meeting consensus as long as 2-3 out of 5 team members are there. It may be worth adopting a similar process. (The meeting ended here.) ### "Clarify muliti-line chain elements" style-team#163 **Link:** https://github.com/rust-lang/style-team/pull/163 ## RFCs waiting to be merged None. ## `S-waiting-on-team` None. ## Proposed FCPs **Check your boxes!** ### "[style edition 2024] Combine all delimited exprs as last argument" rust#114764 **Link:** https://github.com/rust-lang/rust/pull/114764 ## Active FCPs None. ## P-critical issues None. ## Check-out (Not minuted.)