T-Style Minutes

--- title: T-Style Minutes tags: minutes, T-style url: https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A --- # T-Style Minutes ###### tags: `minutes` Meeting Link: https://meet.jit.si/t-style-style-team-task-force <details> <summary>Earlier minutes:</summary> - [2023-09-20](https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A?both#2023-09-20) - [2023-09-13](https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A#2023-09-13) - [2023-09-06](https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A#2023-09-06) - [2023-08-30](https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A#2023-08-30) - [2023-08-16](https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A#2023-08-16) - [2023-08-09](https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A#2023-08-09) - [2023-08-02](https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A#2023-08-02) - [2023-07-26](https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A#2023-07-26) - [2023-07-19](https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A#2023-07-19) - [2023-07-12](https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A#2023-07-12) - [2023-07-05](https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A#2023-07-05) - [2023-06-28](https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A#2023-06-28) - [2023-06-21](https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A#2023-06-21) - [2023-06-14](https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A#2023-06-14) - [2023-06-07](https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A#2023-06-07) - [2023-05-24](https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A#2023-05-24) - [2023-05-17](https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A#2023-05-17) - [2023-05-10](https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A#2023-05-10) - [2023-05-03](https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A#2023-05-03) - [2023-04-26](https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A#2023-04-26) - [2023-04-12](https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A#2023-04-12) - [2023-04-05](https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A#2023-04-05) - [2023-03-29](https://hackmd.io/nl-3kKGYTL-TGG8DWJ8fgA#2023-03-29) - [2023-03-22](https://hackmd.io/nl-3kKGYTL-TGG8DWJ8fgA#2023-03-22) - [2023-03-14](https://hackmd.io/nl-3kKGYTL-TGG8DWJ8fgA#2023-03-14) - [2023-03-08](https://hackmd.io/nl-3kKGYTL-TGG8DWJ8fgA#2023-03-08) - [2023-03-01](https://hackmd.io/nl-3kKGYTL-TGG8DWJ8fgA#2023-03-01) - [2023-02-22](https://hackmd.io/nl-3kKGYTL-TGG8DWJ8fgA#2023-02-22) - [2023-02-15](https://hackmd.io/nl-3kKGYTL-TGG8DWJ8fgA#2023-02-15) - [2023-02-08](https://hackmd.io/nl-3kKGYTL-TGG8DWJ8fgA#2023-02-08) - [2023-02-01](https://hackmd.io/nl-3kKGYTL-TGG8DWJ8fgA#2023-02-01) - [2023-01-25](https://hackmd.io/nl-3kKGYTL-TGG8DWJ8fgA#2023-01-25) - [2023-01-18](https://hackmd.io/nl-3kKGYTL-TGG8DWJ8fgA#2023-01-18) - [2023-01-11](https://hackmd.io/nl-3kKGYTL-TGG8DWJ8fgA#2023-01-11) - [2023-01-04](https://hackmd.io/nl-3kKGYTL-TGG8DWJ8fgA#2023-01-04) - [2022-12-07](https://hackmd.io/nl-3kKGYTL-TGG8DWJ8fgA#2022-12-07) - [2022-11-30](https://hackmd.io/nl-3kKGYTL-TGG8DWJ8fgA#2022-11-30) - [2022-11-23](https://hackmd.io/nl-3kKGYTL-TGG8DWJ8fgA#2022-11-23) - [2022-11-16](https://hackmd.io/nl-3kKGYTL-TGG8DWJ8fgA#2022-11-16) - [2022-11-09](https://hackmd.io/nl-3kKGYTL-TGG8DWJ8fgA#2022-11-02) - [2022-11-02](https://hackmd.io/nl-3kKGYTL-TGG8DWJ8fgA#2022-11-02) - [2022-10-26](https://hackmd.io/nl-3kKGYTL-TGG8DWJ8fgA#2022-10-26) </details> ## Action Items ### Pending/In Progress * Josh to review [Membership criteria policy proposal](https://github.com/rust-lang/style-team/pull/182) * Josh to update style-team repo README (it's currently still the fmt-rfcs README) * Done: https://github.com/rust-lang/style-team/pull/185 * Caleb to open PR updating style guide with proposal for assembly formatting based on https://github.com/rust-lang/style-team/issues/152 * Caleb to open PR articulating procedure around timelines/targets for capturing vNext Style Edition changes (https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A?view#2024-style-edition) * Jane: create tracking issue for 2024 style edition with follow up steps for publishing info about feature cutoffs and determining edition ship date ### Backlog #### (Explore) Style team membership growth #urgent #important (#blocked on membership criteria/policy) https://github.com/rust-lang/style-team/pull/182 This is pending a discussion between Jane and Josh. #### Talk about pending PRs and getting them merged, and what processes we should follow (action items, pings, etc) #important #urgent * Agenda generator? #important (subitem, but has implications beyond parent item, and independent value) #### Policy about preferring async decision-making This was proposed by CE in the 2023-08-30 meeting. #### Policy about expectations of team members in terms of making forward progress on decisions This was proposed by CE in the 2023-08-30 meeting. #### (Decide) Review formatting changes for restrictions RFC https://github.com/rust-lang/rust/pull/106074 #important #urgent #blocked #### (Decide) Style rules for empty match arms - https://github.com/rust-lang/style-team/pull/147 #important (goal: 2024 style edition) * Josh: proposal to block wait on the style edition framework and then a concrete style proposal #### (Explore) review formatting changes for next edition proposed by @Josh Triplett in https://hackmd.io/SKGaTg6lSs6sBjANQKBmBA #important (goal: shipping 2024 style edition) (Mostly done) * May have a few more to discuss * First discuss and consent to process #### (Explore/Decide) Decide about handling formatting for inline assembly (all editions, or 2024+) - https://github.com/rust-lang/style-team/issues/152 #important #### (Explore/Decide) Formatting proposal for inline assembly - https://github.com/rust-lang/style-team/issues/152 #important #blocked(on writing a proposal) #### (Explore) code string literal RFC https://github.com/rust-lang/rfcs/pull/3450 #urgent-ish (time sensitive, but not important. some implementation proposals create more freedom/less time dependency on t-style) #blocked (on updated proposal/RFC from RFC author) * After we have a new proposal, evaluate if we have style-based objections to the proposal #### (Explore) General discussion of if/when/how the Style Guide should account for comments within formatting prescriptions ### Deadlines * (Explore) Revisit T-style nightly policy doc (https://github.com/rust-lang/style-team/pull/180) (date: June 5, 2024) ## 2023-10-18 ## 2023-10-11 Skipped ## 2023-10-04 https://hackmd.io/FNY_eJwyRMCcbC-tMo2B5w ## 2023-09-27 Triage Meeting Minutes: https://hackmd.io/CMDjHFWKQpiMP4LcS24nGA ## 2023-09-20 ### Attendance Members: Caleb, Jane, Michael (late) Guests: TC Minutes: TC ### Agenda * Check-in + Agenda Consent * Review Prior Action Items * Backlog triage * TC: I propose that we go through the backlog in order and see for each item whether we can make any incremental progress. * Check-out #### Review Prior Action Items ###### Completed * [x] Caleb to open thread confirming decision to gate assembly formatting behind 2024 edition w/ michael - https://rust-lang.zulipchat.com/#narrow/stream/346005-t-style/topic/punting.20inline.20asm.20formatting.20to.202024.20edition * [x] Jane to review https://github.com/rust-lang/rust/pull/114901 Jane: We seem to have handled much of this async. Jane: We asked Jack about the edition planning. Caleb: Is it done just because we asked Jack, or do we have more to do and track about this? Jane: There was some discussion in the council Zulip stream. I'll double-check with Jack today. Caleb: I'll move the action item back up to the top. Message me if it's done. TC: What was the answer from the first time we asked? Jane: He may still be chasing that down. ### Backlog review #### (Explore) Style team membership growth #urgent #important (#blocked on membership criteria/policy) TC: Are we still blocked on this. Jane: We're still blocked on that probably. Caleb: This relates to the PR 182 that Jane authored. Jane and Josh need to iron out some points. We're waiting on that. *Consensus*: Jane and Josh will connect to iron out final points. #### (Explore) Setting target/timeline to finalize 2024 Style Edition changes #urgent #important Caleb: I think we can remove this as a resolved item, https://rust-lang.zulipchat.com/#narrow/stream/346005-t-style/topic/meeting.202023-08-30/near/388377720 Caleb: I feel like this backlog item is done. We came to an agreement on next steps, so there are action items here. Jane: We did agree to the offset element. One is going to be the cutoff for major changes and one will be the cutoff for bug fixes. But those things are dependent on the clear date of when the style edition will ship. Jane: It's fine to mark this item as resolved in so far as the other action item we have open will result in writing up a policy for the plan for when the style edition will ship. TC: What I'm hearing is a question of whether this is blocked on setting a policy or on setting a date. Caleb: Agree with Jane here. And I don't think this is an explore item any longer. Jane: Do we have a 2024 style edition tracking issue? Maybe persisting it there would be the correct next step. TC: +1 Caleb: We don't currently have a tracking issue. If we want to shift to an issue to capture some of the other TODO items, I don't have any objections to that. But there may be some bifurcation of where we're tracking things. Jane: Agree. But we have a plan to migrate to the issues. Maybe next week we could have everything ported to issues. TC: +1. Caleb: No objections. Let's capture an action item for someone to create the issue. Jane: I'll take the action item. *Consensus*: We'll remove this as a backlog item. We'll create an GH issue for it, and we'll create a action item for creating that issue. #### Talk about pending PRs and getting them merged, and what processes we should follow (action items, pings, etc) #important #urgent * Agenda generator? #important (subitem, but has implications beyond parent item, and independent value) Jane: We made the decision to do two different things. We'll use the issue tracker exclusively, and we'll use tooling to pull from those into the agenda. And we setup highfive on the repos. Jane: There may not be more to do than to make sure the follow-ups happen. Caleb: I'm curious if part of this was intended to talk about specific open PRs, or whether it was just process. Jane: We had issues piling up on the style team repo. We synthesized those into a set of solutions that covers all of it. *Consensus*: We'll leave this as a backlog item. #### Policy about preferring async decision-making This was proposed by CE in the 2023-08-30 meeting. CE: What is worth filing as an FCP? That might have been what the context was. *Consensus*: We'll come back to this after we remember the context. #### Policy about expectations of team members in terms of making forward progress on decisions This was proposed by CE in the 2023-08-30 meeting. CE: Once we start an FCP, it'd be nice if we had some internal expectations about when team members would move forward and when it would be OK to ping people. *Consensus*: CE will open a PR about this. #### Talk about strategy for where to file and track style issues (style-team repo vs rust-lang/rust) #urgent TC: The context here is as follows. Issues related to the style guide will of course be filed in the main Rust repo because that's where the style guide lives. But there are other issues, e.g. those related to our team policy, to meetings, etc. The question is whether we want those to live in the style-team repo or whether we want to push them all to the main Rust repo. Most other teams accept this bifurcation and put team-related matters in a separate repo. E.g., T-lang does it this way. Jane: The prompt here is: in what ways would this affect the ability of the style team to achieve our goals? Caleb: I don't feel any issues or pain points. It works for me to put things in the Rust repo if it's related to the style guide and to put things in our repo if it's related to us, to our team, or to our policies. CE: +1. Someone should just write down the rules that we should follow. TC: +1 to how Caleb phrased it. Jane: I don't see any issues other than that we don't have the same integration with the tools in our repo. I agree with CE that writing this down is a good idea. *Consensus*: Things related to the style guide go into the Rust repo. Things otherwise related to our team go in our repo. We'll remove this as a backlog item. Caleb will take action item to write the policy PR. Jane will ping Josh to make sure he's aware. #### (Decide) Review formatting changes for restrictions RFC https://github.com/rust-lang/rust/pull/106074 #important #urgent CE: This PR hasn't been rebased in 3 months. We should wait until it lands in the compiler. I'm not sure why it's marked as urgent or important. But now the author needs to make the code happen before we worry about syntax that doesn't exist at all yet. Jane: I propose that we mark this as blocked. TC: I propose actually we remove this from the backlog. Jane: OK. CE: We should leave a comment letting the author know to tell us when it's merged. Caleb: I'm a bit concerned about dropping it from the backlog. It gives me a feeling of comfort to know about what's in the pipeline. So it may depend on how likely it is to move forward. TC: The downside is that we need to keep pulling it forard and reviewing it. We could tag the issue as T-style. And as CE said, we could ask the author to nominate it for us when it is ready. Jane: We're on the checklist for stabilization, and this seems rather far from stabilization at the moment. Caleb: I'm not sure whether there are process gaps. The model that you're describing TC sounds reasonable to me. The way that style-related issues are applied today is maybe not rigorous. How would we notice new PRs though? We don't want to let things slip until stabilization. TC: This brings up a great issue. When exactly, as a process, do we want to be informed? Caleb: Agreed. I don't have an answer. But it's the right question, and we should track it down. CE: Not sure I have a good answer either. How teams become aware of things in general is ad-hoc. I wish we had a checklist for feature implementation. Jane: I have an idea. The time that seems the right time to be informed is once implementations of a feature have hit nightly. If we had tooling support for when feature flags hit nightly, that would be helpful. I'm wondering how far off that tooling might be. TC: +1 to that. There are two plausible places. One is when RFCs are merged, the other is on the implementation landing. We could look at the RFCs when they're merged and decide whether they have bearing on T-style at that point. If they do, we could track them more carefully and await the implementation. If they don't, then we know that the implementation is unlikely to be relevant to us anyway. Caleb: Agree with you both. And maybe we should raise this with the council about how we could better communicate between teams when certain events happen. Caleb: As you were talking through it, TC. There are probably a couple of levels to it for us. There are things that should be on our radar. And there are things that are more important. There of course can be some nuance. E.g. the code string literals is an example where we may want to be involved as part of the RFC. Jane: Most of that nuance can be handled as part of the social process. If something is outside of the standard process, we can rely on that to catch things. The concern on doing it on RFC merge is that it can take a long time for RFCs to be implements and there can be large differences between the RFC and the implementation. So that leads me toward preferring the merge of the implementation. TC: Maybe we look at the RFC in-so-far as to decide whether to tag the tracking issue as T-style or not. *Consensus*: This needs more discussion. (The meeting ended here.) #### (Decide) Style rules for empty match arms - https://github.com/rust-lang/style-team/pull/147 #important (goal: 2024 style edition) * Josh: proposal to block wait on the style edition framework and then a concrete style proposal #### (Explore) review formatting changes for next edition proposed by @Josh Triplett in https://hackmd.io/SKGaTg6lSs6sBjANQKBmBA #important (goal: shipping 2024 style edition) (Mostly done) * May have a few more to discuss * First discuss and consent to process #### (Explore/Decide) Decide about handling formatting for inline assembly (all editions, or 2024+) - https://github.com/rust-lang/style-team/issues/152 #important #### (Explore/Decide) Formatting proposal for inline assembly - https://github.com/rust-lang/style-team/issues/152 #important #blocked(on writing a proposal) #### (Explore) code string literal RFC https://github.com/rust-lang/rfcs/pull/3450 #urgent-ish (time sensitive, but not important. some implementation proposals create more freedom/less time dependency on t-style) #blocked (on updated proposal/RFC from RFC author) * After we have a new proposal, evaluate if we have style-based objections to the proposal ## 2023-09-13 ### Attendance Members: Josh Guests: TC Minutes: TC ### Agenda TC: We went through the backlog last time. What would we want to cover? Josh: We should touch issue management. Where do we want issues filed? Josh: The other obvious question would be which formatting proposals are the most important. We should make sure we're not blockers on any proposals. I don't think we are right now. ### TOML v1.1 Josh: TOML v1.1 is about to be published. It includes the ability to break inline tables across lines. We should have a look at the style implications of this if it were to be included in Rust / Cargo. TC: +1. (The meeting ended here.) ## 2023-09-06 ### Attendance Members: Josh, Caleb, Jane Guests: TC Minutes: TC ### Agenda - Check-in - Agenda consent - Backlog review ### Agenda consent TC: I propose we discuss the remaining backlog items that we did not get to last week. All: +1 ### Action item review Jane: There's one for me... checkbox on something. Will get to that. Jane: One for Caleb... Caleb: No updates. Jane: One for Josh, membership criteria, rustbot, others. Josh: On rustbot, I got someone to enable it, added it to our repo, and got the config added. Jane: Do we have highfive? Josh: Yes, but we should confirm it's working on new PRs. Josh: On membership criteria, I've done a full review. Jane and I need to work out how to get on the same page on some remaining wording. Caleb: I saw some of the dialog, but I haven't read thoroughly. Josh: We'd all still sign-off. TC: If you're both not that far apart, maybe we could resolve it quickly here. Josh: Skimming the issue, we're probably not that far apart at this point. Jane: When I had last touched it, I felt like we were building a basis on which we could build. *Consensus*: Jane and Josh will discuss async and bring something back to the group. ### Backlog review #### (Explore) review formatting changes for next edition proposed by @Josh Triplett in https://hackmd.io/SKGaTg6lSs6sBjANQKBmBA #important (goal: shipping 2024 style edition) (Mostly done) Jane: What is left to do on this? Caleb: Maybe let's create an action item to figure out what is left. We had gone through most of these, but some needed async review, and that fell off the radar. Josh: I think we got through almost all of them async. We need to make a document that we can check off as we go. These need to become style guide changes, which I'm happy to help do (but won't have time for the next few weeks). Jane: Let's convert this into the next step. Caleb: There are a number of things that note more discussion is needed and that consensus had not been achieved yet. Jane: We should probably start with the ones on which we have consensus. On the other ones, we should add them to the backlog so that they can be discussed. TC: Should we create GitHub issues for each of the ones that we want to move forward on? Jane: Maybe if we're flipping feature flags, we could put those in one issue? Caleb: We'd want to communicate and allow the community to weigh in. Some of these we'll hear strong opinions on. Jane: To summarize, we'll split all of the things into issues. And we'll tag these with whether we achieved consensus or whether more discussion is needed. TC: (In text:) Proposal, we should use the FCP process to confirm consensus. Josh: We should use FCP to confirm consensus. We could also use that to draw attention to these so the community can provide feedback. (For instance, we could arrange for the FCPs to end up in TWiR.) Caleb: +1. But we don't need to capture anything `rustfmt` related in the style guide. Jane: I was expecting that changes to `rustfmt` will come out of the style guide changes. Want to make sure nothing falls through the cracks between our teams. Caleb: It's just important to not try to track the `rustfmt` work on the style-team side. Josh: +1 for not tracking `rustfmt` work in the style team repo/backlog. *Consensus 1*: We'll create separate issues/PRs for each 2024 item in the main Rust repo against the style guide. Josh is willing to do this, but it will take some weeks, so volunteers are welcome. *Consensus 2*: For things where we know we have consensus, those are better for PRs. For things where we're not sure, an issue is better so that time isn't spent writing up text. Then the FCP process on the issue helps us to know whether to invest in writing the PR. #### (Explore/Decide) Decide about handling formatting for inline assembly (all editions, or 2024+) - https://github.com/rust-lang/style-team/issues/152 #important Caleb: This and the next item are probbaly duplicates. Jane: One is decide which edition, and the other is decide which formatting. Caleb: Don't know if they can be decoupled completed, but fair enough. Josh: The first one was because we've gone so long without formatting, is it breaking to do it now? We hadn't made a call on that. It is orthogonal to writing the style guide text. Josh: For the next one, it says blocked on writing a proposal, but it's only half blocked. There is text there, but it has to be turned into style guide text. Jane: There was a lot of alignment on 2024 only, that was my recollection. Josh: I had a mild opinion, but I don't feel as strongly as that would suggest. I would like to see it formatted universally, even though I am worried about the churn. I could go either way. Caleb: It was discussed at the 2023-07-19 meeting. Jane: It says there was a decision. Is there anything more to discuss then? TC: It seems the question is whether a call was actually made, e.g. given Josh's recollection. The minutes for that meeting are a bit too sparse to see what really happened. Jane: Let's double-check async so that we get CE's view. Caleb: I'll start the thread. *Consensus*: We'll check our consensus async. #### (Explore/Decide) Formatting proposal for inline assembly - https://github.com/rust-lang/style-team/issues/152 #important #blocked(on writing a proposal) Caleb: Let's convert this into an action-item. Maybe we should discuss in private before going public with it. Caleb: Since this is an explore, instead of reviewing in a meeting the language already proposed, I propose we do this async. Jane: Someone needs to open a PR that adds text to the style guide based on the existing language, and then we'll review that. And you're volunteering to do that. Caleb: Correct. *Consensus*: Caleb will convert the existing proposed language into a PR, and when that's ready we'll review it as a team. We'll remove this and the previous item from the backlog and add them as action items. #### (Explore) Setting target/timeline to finalize 2024 Style Edition changes #urgent #important TC: Last week we had discussed we needed to talk with Caleb about this. Jane: This received discussion async. Caleb: The timeline one can be removed. And the one about macros can be removed. Josh: What was the actual answer on the timeline? Caleb: It was 6 months from the edition. Josh: The goal was to find our offset from the project timeline. But we don't know yet the project timeline. Caleb: Not sure who to ask. Josh: There's been maybe some council discussion. Jane: We should reach out to Jack, our council rep. Caleb: Makes sense. Let's capture an explicit action item. *Consensus*: We'll remove this from the backlog and we'll add an action item to check with Jack about what the project-wide edition timeline is. #### (Explore) Style Guide prescriptions for macros? #important Caleb: I think we can remove this as a resolved item, https://rust-lang.zulipchat.com/#narrow/stream/346005-t-style/topic/meeting.202023-08-30/near/388377720 All: +1 *Consensus*: Let's remove that from the backlog. (The meeting ended here.) #### (Explore) code string literal RFC https://github.com/rust-lang/rfcs/pull/3450 #urgent-ish (time sensitive, but not important. some implementation proposals create more freedom/less time dependency on t-style) #blocked (on updated proposal/RFC from RFC author) ## 2023-08-30 ### Attendance Members: Michael, Jane (facilitator) Guests: TC Minutes: TC ### Agenda * Agenda consent + Check-in * Review backlog * Meeting Check-out ### Agenda consent Jane: We had wanted to talk about style prescriptions for macros, but that probably needs Caleb. Jane: So unless there's objection, let's maybe go through the backlog and pick out some items to discuss. TC: I propose that we go through the backlog top-to-bottom as the agenda. TC: For each item, we'll discuss where we are and whether any steps toward forward progress are possible. Otherwise, we'll document what we're blocked on. (Discussion...) Consensus: Let's do that. ### Backlog review #### (Explore) Style team membership growth #urgent #important (#blocked on membership criteria/policy) Jane: This is blocked on the membership criteria PR. Josh has reviewed it, and I've merged a number of those changes. So when Josh gets back, hopefully we can make progress on it. TC: Has this reached consensus with the rest of the team? CE: Right, what's the next action item on this? Are we doing an FCP on this? Jane: Feels to me that we should default to async decision-making, so we should probably FCP it. But I'm comfortable checking the boxes of people who have clearly agreed to it. Consensus: We'll FCP this after finishing the discussion with Josh. #### (Explore) Setting target/timeline to finalize 2024 Style Edition changes #urgent #important Jane: I feel like we talked about this a couple of weeks ago. There was discussion about the date and interaction with the `rustfmt` team. Maybe we're waiting on them. TC: Are we sure that they know that this is in their court? Jane: This does seem to be an action item... TC: What's the specific question that we're waiting on `rustfmt` to answer? (Discussion about what that might be and a review of the minutes of earlier meetings...) (We were unclear about the question being asked.) TC: The action item here is probably to double check with Caleb what he wanted to do here. Jane/CE: Agreed. Consensus: We'll check with Caleb what question he wanted to have the `rustfmt` team answer before we move forward. #### Talk about pending PRs and getting them merged, and what processes we should follow (action items, pings, etc) #important #urgent Subitem: Agenda generator? #important (subitem, but has implications beyond parent item, and independent value) Jane: We agreed to set-up these tools on our repo. Josh is working on the tooling side. TC is going to make a PR for the policy. Someone needs to make a template for the triagebot generator. Seems those would resolve this item. This will hopefully get us quicker reviews on open PRs, which was my concern. TC: Agreed with that summary. And doing that PR is on my list. CE: We may want to codify that we prefer async decisions. But that raises the question of how to ping people who aren't making decisions. Especially when other people and teams are waiting on us, we have to have a way to move forward. We should have more clear expectations about, e.g., decision timelines. Jane: I'm hearing an action item to write a policy for async decision-making and a policy about timelines for decision-making. CE: I'm happy to write those up. TC: Question. That latter one sounds like something I had proposed earlier, in terms of writing down what reasonable expectations are for our decision-making, but it turned out to be unexpectedly controversial. How do we propose to go about this without it being similarly controversial? CE: I think the difference is in framing. Here, we'll propose internal expectations of what the team can expect from its members rather than what other teams can expect of our team. Jane: People may be less defensive in this context. In the other discussion, it was easy to confuse proposing clear expectations with disagreement about the nightly policy that was proposed. Having a separate context here may help. Consensus: We'll add action / backlog items for these. #### Talk about strategy for where to file and track style issues (style-team repo vs rust-lang/rust) #urgent CE: Did we decide to put it in the style-team repo? TC: The style guide is in the main Rust repo, so it's clear why people would file issues there. We had talked about there being better visibility in the main rust repo. CE: But we talked about moving the backlog and action items to the style-team repo. Jane/TC: Yes, we did agree to that. TC: Do we almost have consensus here? There will be issues in the style-team repo. And if the style guide issues go in the main repo, then issues will be split between repos. Jane/CE: Agreed that there's no need to collapse things into one repo. (There was discussion about whether or not some of those not present might have wanted to collapse all issues into the main rust repo and do away with issues in the style-team repo. But we were unclear here.) Consensus: There are two issues here. One is the handling of backlog and action items. We have consensus there to put those in *some* repo. The second issue is whether or not to collapse all issues into the main rust repo. That second issue needs more discussion to ensure we have consensus. #### (Decide) Review formatting changes for restrictions RFC https://github.com/rust-lang/rust/pull/106074 #important #urgent CE: The restrictions RFC has yet to land. So we probably shouldn't make a decision until this goes in. TC: We've talked about issuing style guidance preemptively. Are we really blocked here on that going in, or could we do that? CE: In this case, I'd like to see what we do with the AST. CE: And, actually, I'd like to see an initial suggestion from the person who wrote the PR for the restrictions RFC. That person had originally included changes to `rustfmt` in the PR that were then backed out. TC: It sounds like the action here is ask that person for a proposal. CE: We could comment in the PR. I'll do that. Consensus: CE will suggest to the author in the PR how to help us move forward. #### (Decide) Style rules for empty match arms - https://github.com/rust-lang/style-team/pull/147 #important (goal: 2024 style edition) TC: This has received extensive discussion on Zulip. There are many aspects to this. Caleb also filled in background on what people had previously been asking for. Someone would need to pull this all together. CE: Someone should come up with a concrete proposal. A design meeting (as in TC's proposal) would be appropriate. Jane: Agreed with that. Consensus: This needs more discussion; we recommend a design meeting. (The meeting ended here.) #### (Explore) review formatting changes for next edition proposed by @Josh Triplett in https://hackmd.io/SKGaTg6lSs6sBjANQKBmBA #important (goal: shipping 2024 style edition) (Mostly done) #### (Explore/Decide) Decide about handling formatting for inline assembly (all editions, or 2024+) - https://github.com/rust-lang/style-team/issues/152 #important #### (Explore/Decide) Formatting proposal for inline assembly - https://github.com/rust-lang/style-team/issues/152 #important #blocked(on writing a proposal) #### (Explore) Style Guide prescriptions for macros? #important #### (Explore) code string literal RFC https://github.com/rust-lang/rfcs/pull/3450 #urgent-ish (time sensitive, but not important. some implementation proposals create more freedom/less time dependency on t-style) #blocked (on updated proposal/RFC from RFC author) #### Review Prior Action Items ###### Completed ## 2023-08-16 ### Attendance Members: Jane, Caleb, Michael Goulet (CE), Josh Triplett Guests: TC Minutes: TC ### Agenda * Agenda consent + Check-in * Review prior action items * (Decide (whether this is 2024)) missing style for type alias + where clauses * https://github.com/rust-lang/rust/pull/114901 * (Explore) Style Guide prescriptions for macros? #important * Meeting Check-out ### Minutes #### Agenda consent Caleb: We should talk about the backlog item for about our prescriptions. Also the one about prescriptions for certain macros. But we should also talk about the ones Josh mentioned. Josh: I'd put at the top Caleb's suggestion about whether the style guide should guide on certain macros. It fits with talking about `asm!`. Josh: Beyond that, there are two PRs for the style guide we should review. Jane: You want to start with the macro conversation? Josh: Correct, then any of the other three. CE: Caleb and I might have had a disagreement on trailing WCs in a PR. We should sync on that in this meeting. Jane: No strong preference. Josh: Solving a disagreement sounds high priority. TC: +1 Caleb: Agreed, that was part of my suggestion. Josh: No strong preference here for prioritizing the macro suggestion. Jane: Propose to start with WCs, then follow up with macros. Then see after that. all: +1 #### Action items ##### Completed * MG to PR bugfix and missing style for type alias + where clauses, with FCP. * Josh to provide timely review on the bugfix. * https://github.com/rust-lang/rust/pull/114901 #### "Amend style guide section for formatting where clauses in type aliases" #114901 CE: Awhile back, we moved where the WC is placed for type aliases. But in rustfmt we just bail on trailing WCs. It's not clear whether we're going to continue to leave this unformatted in this style edition. Caleb: We have previously as a team discussed this. About a month ago, the team decided to not move forward with inline asm due to churn. And I asked whether that should also apply to trailing wCs on type aliases. But we didn't decide. CE: We need to decide whether to format this in style edition 2021. Jane: Let's do a round. CE: We should be formatting these WCs. There are two kinds of changes. One is going from no formatting to formatting. The second is going from bad formatting to better formatting. The latter needs to happen over an edition. But the former is case by case. CE: This trailing WC issue does show up with GATs. But this is still relatively new, so the churn seems less bad than not having formatting. Josh: On the one hand, I agree with the principle that we should try to not be too disruptive within an style edition, even on unformatted code. But there should be an exception for new constructs. The cost of style breakage is lower than stable API breakage. This has been around long enough that maybe we should format it in a new edition. Josh: Trailing WCs have been around a long time. But GATs are somewhat more recent. Maybe we could just do it for GATs? But overall I'm very hesitant. Caleb: I'm in favor of doing this in the current style edition. The door has been explicitly opened to do this. The churn is always going to be confined to just the type alias itself. By contrast, `let-else` can span a large amount of code. But formatting aliases is going to affect a contained amount of code. So this feels smaller. Jane: I take a less strict view of stability, so my inclination is caution. Insofar as we have to pick something... it's probably not satisfying to tell people to enable the style edition early. Maybe we could respond dynamically to feedback? I wouldn't object to either proposal. I'm a bit undecided. CE: Trailing WCs are not allowed in type alias items. They're only allowed in GATs, to clarify what Josh had said. Global type aliases don't do anything with WCs. CE: Second data point. I ran rustfmt on the compiler after implementing this. There was only one place that code changed. Caleb: At a minimum, nightly should apply the new formatting. I'd be disinclined to bifurcate this. My hope is that people have been hand-formatting this in the obvious way. The only thing that gives me pause is that rustfmt bails silently. But people may be confused about that and think that `rustfmt` has formatted all of their code. Jane: CE, you want formatting immediately. Caleb, you want formatting for both. For me, I'm not objecting, but I want to be able to adjust if people raise alarm. Josh? Josh: My view is shifting toward your position Jane. I'm not a fan of breakage. But I'm getting more sympathetic here. TC: As a matter of terminology, do we call it "breakage" to format something that was previously unformatted? Caleb: From the rustfmt side, no, this is explicitly not breakage. CE: Maybe "churn" is the right word. Jane: I propose we do the "churn". We should do a blog post saying that we're doing this and that we expect it to be the last one. Josh: Do we expect this to be the last one? Caleb: I don't know, and that worries me. I don't know what's been stabilized in the language that `rustfmt` is skipping. I would ask that we hold off on making guarantees that this won't happen again. TC: +1 Jane: Updated proposal. We'll blog about it, but not back ourselves into a corner. We'll say that we're investigating other places. We'll hope to not do this again but not put that in the blog post. TC: Do we intend for this hope about not adding formatting for previously unformatted constructs to apply going forward in general or just for the 2021 style edition? Caleb: This is the hope going forward in general; with the new team and processes we hope this kind of churn won't be necessary. all: +1 to the proposal. #### Formatting for macros Caleb: There's currently a little bit of formatting for macros. There are some minimal heuristics. This is the kind of thing that sometimes works "well enough". Caleb: So if the style guide had explicit direction for known formatting of certain macros, that would be a good thing. Caleb: I don't want to go after every macro in the standard library, certainly not every one in the ecosystem, but opening the door to doing formatting for certain macros would be good. Jane: Can we handle this async? If end up blocked, this can be the topic for the next meeting. (The meeting ended here.) ## 2023-08-09 ### Attendance Members: Caleb (lead), Michael, Jane (facilitator), Josh Triplett Guests: TC Minutes: TC ### Agenda * Agenda consent + Check-in * Review prior action items * (explore) Agenda generation and meeting formats proposal by TC * Meeting Check-out ### Minutes #### Agenda consent Jane: Agenda consent... We had a proposal from the last meeting. We had wanted to discuss the proposal from TC on the goals and format of our meetings. We wanted to discuss with the full team present. Sound right TC? TC: Absolutely correct. Josh: When should we check in on updates to past action items? Jane: Yes, we'll do that. Caleb: Is there any prep work needed to meaningfully participate in the design doc discussion. TC: There's no prep work needed and no expectation of having read the design document ahead of time. #### Action items (Action items...) Josh: Should we have a perennial action item for "write and submit PRs"? Jane: If it's not helpful to us, then let's drop it. Josh: My expectation would be that an agenda generator would help here. So I'd propose dropping this item. I did submit one PR about the formatting of as-casts. Jane: Let's go ahead and remove that item. Moving on to CE. CE: No updates on either item. Jane: For mine, I did send a comment this morning to Zulip regarding the question of should we set up highfive. Waiting on CE for thumbs up. CE: Thumbs up. Jane: That's it for action items. Josh, did you have a further item? Josh: Wanted to be sure that the PR to t-lang to include the checkbox for t-style had merged. #### Proposal for T-style process for triage and design meetings Jane: Let's move on to the actual proposal. TC: Here's the proposal: https://hackmd.io/rIoK41mxSjK1It01o4RLnA Jane: This is probably an "explore". A "decides" would get turned into a PR against the repo. Jane: Let's read it. (Meeting starts reading...) Jane: Think I understad, no clarifications. CE: Not sure I understand the distinction between them and how many of each there would be. But in general, I like the idea a lot. Josh: In terms of proportion, I'd expect that as long as we have open issues and PRs, we'd default to triage meetings. We'd have as many design meetings as we want per month. So we'd simply defer design meetings when more triage is needed. Josh: If we get it wired up correctly with triagebot where anyone can run the generator online, it would be easy to check how much is on the list for a triage meeting. Caleb: The section toward the end referring to the agenda and minutes being kept in a separate document for triage meetings. How would we keep track of all of those documents. TC: We would commit the minutes to the style-team repository. We'd also keep the documents in the workspace of t-style in HackMD with appropriate tags. Jane: Other thoughts on the clarifications TC? TC: I'd reinforce what Josh said about proportions and handling this dynamically. Jane: Reactions round. Jane: I like the idea of separate meetintgs. I can already see how we might want other kinds of meetings. Like the other ideas. CE: We should be tracking backlog items in the repo. It's easier to link things into issues. It'd be easier to point people to things. Josh: Very much in favor of the proposal. Thoughts on the types of meetings that we need. There is similarity between triage and design meetings in one specific way. We'll have issues for pending items that could use a design meeting. So in a way, it's kind of like dealing with that one item. So maybe we can have a smooth gradient between gradient and design. Jane: Looping back. The design meeting is like a primitive for how we do work together. The triage meeting is more meta. They're functionally similar. You can solve many issues with that low-level primitive. Josh: That's similar to what I was describing. I was thinking of it as triage as the root. But we got to the same place as different paths. Caleb: Thumbs up. A lot of the challenges and frictions we've had stem from trying to do too much at one time. Agile frameworks do a similar differentiation. Caleb: Clarifying question. Is the intent to have one more recurring meeting series that on a given week will either be triage or design? It's for another recurring meeting series. Jane: No, it replaces the current meeting slot. Caleb: Is it conceivable we'd have three meetings in a row of one or the other? Jane: Both the triage and the design meetings are the operational work of the team. Josh: There's enough lack of clarity on that specific point that we should document what is the default type of meeting. We could say that the default is a triage meeting. TC/Josh: That is how the document is written. Jane: We're changing the triage meeting to be more automated, and we're changing the design meeting to be more reliant on someone having something they want to actively focus on. If we finished the design meeting early, we'd probably use the remaining time for triage. Caleb: Maybe I'm taking the proposal too literally. The design meeting requires someone to put a document together. TC: The document doesn't need to have a design fully worked out. It's a document that describes what the goal of the meeting is and provides any necessary context. It's to guide the meeting. What we're doing here today is a good prototype for a design meeting. Jane: Should we not require a document? Caleb: That makes sense. TC: I actually do think the document is central to the proposal. Caleb: I worry about the level of overhead. Would like more time to think about the document. Jane: Concur with Caleb about the reservation. I see the value, but I'm not sure that's been a problem in our meetings. So as long as someone has that context, it could be OK as oral. TC: Everything there is still valid for triage meeting. None o that goes away. It's still OK to deep dive on issues during triage meetings. The document is what distinguishes the design meeting. Josh: We could start with a looser process. I do think there's value in having a document that answers the most basic questions. Jane: Seems like, still require a document, but it could be as minimal as a template. But it will be tagged appropriately and in our HackMD space. Jane: Does anyone feel this is not ready for a PR.... hearing none. TC, ready for a PR. Josh: Let's ship it and FCP it. (Checkout...) #### Review Prior Action Items ###### Completed ## 2023-08-02 ### Attendance Members: ~~Caleb (lead, secretary)~~, Michael, Jane (facilitator), Josh Triplett Guests: TC Minutes: TC ### Agenda * Agenda consent + Check-in * Review prior action items * (Explore) Talk about pending PRs and getting them merged, and what processes we should follow (action items, pings, etc) #important #urgent * Agenda generator? #important (subitem, but has implications beyond parent item, and independent value) * Meeting Check-out ### Minutes Josh/Jane: With only two t-style members here, should we proceed? We can discuss items but probably not decide. It's worth reviewing things. Jane: Thoughts on the agenda? Agenda consent?.... Hearing no objections. Josh: Appreciating the newfound urgency of getting the membership policy sorted out. Now putting this as a top priority once I can make room for it. Josh: Enthusiastic about writing PRs for various style-guide items. We have no rules for formatting `as` casts. I'll be adding a section to cover that like a binary operator. So little details like that are the first things I'm tackling. Jane: There was an item from Michael to PR a bugfix. Josh: Haven't seen that. Jane: Let's do the main agenda item. Let's start this with context gathering. What are the problems we want to address, then we can address the solutions. Jane: There are the PRs on the style team repo. We're not reviewing those consistently. We're a bit bandwidth limited, which is one good reason to push forward on expanding membership on the team. There's been progress on the main repo. The main thing that I'm aware of is the PRs on the style-team repo. Josh: Looking at the style-team repo now, there are a couple of PRs that seem worth salvaging. Cleaning this up is probably tractable. We should convert the PR for the match arms into an issue; we know it's an issue but we need to work out what to do about it. Josh: These should be possible to get through. But the list of issues is longer. Jane: There are around 18 open issues right now. Is there also a t-style tag on the main repo? Josh: We do. It looks like there are three open PRs that are marked for t-style. Josh: Confused about #114001.... Something may have been mistagged here. Jane: Back onto the topic. What's the current issue that we're trying to resolve. It seems to be the style-team repo and trying to make steady progress on the PRs. Josh: Making sure that we know where to track issues and that they're all in one place. Do we want issues tracked on the style-team repo or on the main repo, or both? Jane: Do you see the status-quo of currently tracking them on both as being a problem for tracking these issues? Josh: Not necessarily. Especially if we use triagebot; it's easy enough to see both. But I'm concerned about issues getting duplicated and tracked twice. Jane: This seems like it may be a separable issue. TC: In the case of the lang-team (break...) Jane: Anything else on the context before we get into solutions? Josh: Now that the style guide is in the main repo, people are going to file issues there unless we do something else there. Josh: Let's mark the item I just added as #urgent and #important. As people get involved, people will be looking for a process. It's better that we get ahead of this. Jane: To me, I'm not feeling the criticality. It feels useful. How do we define important? Josh: I'm on board with calling it #urgent. Jane: Agreed. Jane: Let's talk about what to do. Josh: My understanding was that we'd start with the proposal for triage and design meetings. Jane: Wanted to make sure we covered all problems first. Josh: It feels like our meetings go back and forth a bit between processa and grabbing issues as we see them. This is probably part of what led to the proposal to separate triage and design. Whatever we do, we should probably better separate these out. Jane: You're feeling like the current norm of how we work in t-style is reactive. And we're not very often taking a step back and looking at our long-term goals. Josh: Close to that. Not sure I'd describe it as reactive. It feels like we glance at the list and go with whatever someone thinks of then. But that may not include all of the important issues that we need to address. So our own process doesn't reliably surface issues that come in from others, since the process for others is to file issues. TC: I might summarize that as that it would be easy to become insular. Josh: Agreed. We need to be a team that others can rely on. Jane: We don't have the same good tooling for the style-team repo as we do for the main repo. So notifications don't get surfaced, and many of us rely on those notifications. That's the side of this problem I'm focused on. The agenda generator would help with that, but I don't want that to be the only solution. Josh: Agreed that's a great concrete proposal. Rustbot support for assigning new issues to one of us would be a good thing. Obviously we don't have full consensus of the team to do that. Josh: Action item 1: Bring it up on Zulip to ensure we have consensus there. Josh: Action item 2: Ask the infra team what it would take for rustbot / highfive to be configured for the style-team repo. Jane: Long-term maybe we could assume the council would set up a common repo for policy for all teams. Josh: To be clear, I'm not recommending that we move everything to the main repo. I suspect the style-team repo may be easier to deal with because it's smaller. TC: When/how do we want to discuss the document? Jane: What works for you? TC: This is the sort of thing that we should discuss with the full team in a meeting, hopefully with everyone here. It affects the feel and purpose of the meetings. It's about how we work. So everyone should be involved. Jane/Josh: Favorable toward the proposal. Jane: I'll take the action item to start a conversation on Zulip about checking for consensus on using rustbot / highfive. #### Review Prior Action Items ###### Completed ## 2023-07-26 ### Attendance Members: Caleb (lead), Jane (facilitator), Josh Triplett Guests: TC (secretary) Minuting: TC ### Agenda * Agenda consent + Check-in * Review prior action items * (Explore) Style team membership growth #urgent #important (10 minute timebox) * (Explore) Setting target/timeline to finalize 2024 Style Edition changes * Meeting Check-out ### Minutes After discussion, we decided to mark the work to finalize the 2024 style edition changes as both #urgent and #important. Josh: We should discuss recent feedback on [#113394](https://github.com/rust-lang/rust/pull/113394) about snapshotting the style guides for new editions. Jane: As it's without objection, we'll mark that as #urgent and #important. Josh: We have at the top of the backlog the policy on new style team mebers. It's marked as #urgent and #important. We should make it just #important. It's not urgent to do that. Caleb: Jane may need to step away from the group, and we had prevously agreed that if membership fell below 4 that it would be urgent to do something about it. Jane: Thanks Caleb for that, and I agree we should talk about it. Caleb: I propose we discuss with a 10-15 minute time-box. Caleb: I agree about discussing #113394. Josh: I'd propose to discuss first the 2024 edition changes with a 10-15 minute timebox. If we finalize that, it will help make our sense of urgency on the items feel more real. Caleb: Not opposed to talking about all three. Josh: Let's discuss the target timeline first. Jane: We have agenda consent. Let's talk first about the membership growth item first for 10 minutes. After that, we'll discuss the timeline for the 2024 edition. Then we'll discuss snapshotting if we have remaining time. Josh: Is the proposal to just discuss the policy around doing so or the prioritization of it, or also to discuss specific people? Jane: It could be both. Josh: I'd like to discuss next steps / policy / process, separately from identifying and choosing people. Jane: Without objections. Jane: Agenda consent take 2? No objections. ##### Style team membership and next steps (Discussion to first focus on next steps and any blockers to grow team, subsequent discussion at a future meeting to discuss any specific individuals) https://github.com/rust-lang/style-team/pull/176#discussion_r1222069273 Jane: We have the membership criterial document. It's still an open PR. We need to get that landed. Are there other barriers? I'd like to have an explicit... some documentation about reaching out. That's already in our charter. Beyond that we need to start soliciting people to join. Maybe we should reach out to existing participants or reach out to project leadership for directing people toward us. Josh: I'm all for us having project-wide unified mechanisms for team growth. But that shouldn't be a blocker for us to follow a team-specific process. Let's not interlock those two. Caleb: I'm curious whether we have a tactical goal that is top priority to get someone else so that we maintain the four person threshold. And whether we also have a longer-term tactical goal about how to bring in other people from different backgrounds or from elsewhere in the project. Jane: Absolutely agree on not blocking on project-wide resources. It's just one avenue for the future. As for Caleb's question. Speaking generally, it's good to have 6 people, in my opinion, for what's a healthy team. It's maybe not urgent to get there. But we should grow it anyway. And I may need to leave this team sooner rather than later. Though I may want to come back at some point. So the immediate goal is we should get that one extra person. We want a larger group to tap into more resources from the views of those other people. Josh: Agreed that we want a diverse set of perspectives. It's particularly important given the kind of work that style does. We need to avoid groupthink. At the same time, we need to find people who are aligned on the high-level goals, such as the value of having a unified style, and the value of moving forward together in the face of disagreement. That's actually more important than a diversity of perspectives. Caleb: Jane, are you maybe leaving quickly enough that we should consider temporarily lowering our standards? Jane: It's not that urgent. We can stick to our standards of what we expect from people. When I made the list of membership characteristics, I didn't order those in any way. But the first most important thing is of course to agree to the goals of the style team. Of course, all of these things are reason for objection. Josh: Agree that we shouldn't be lowering standards. Also critical that we have *positive* confirmation about people's ability to introspect on their values/axioms. Jane: Going to move the pending action items up in the list. ##### 2024 style edition Jane: Let's move on to the next item. Josh to give the context on it. Josh: We know we want to ship the style edition on a given date. We don't know what that date is. We should ask someone about that elsewhere in the project, and for now define our target as that date minus N. And we need to give enough time for `rustfmt` to implement and test. Ahead of that, we need to have the time to debate and bikeshed. Jane: To summarize that, we want to work backward from a given date. And we should work out how long the various items we'll be working back with will take. Josh: Yes, that's accurate. We need to think how long it's going to take to implement and test and factor that in. Caleb: The question you tossed back to `rustfmt`. My question with that hat on is, "well, what are the changes?" It's hard to say how long it's going to take before knowing *what* it is. So maybe we should gate what we pull into the 2024 edition from the style side based on what we can implement. Jane: How much can we decouple the work and get things rolling immediately? Can we make this so that it can happin in a more bottom-up vs top-down way? Can we get the continuous process rolling? It feels like that might take some pressure off of the style team. We get things into the train, and when we hit our date, that's it, and other things go into the next one. Josh: Agree with decoupling it. If we pick a date that seems reasonable (e.g. N minus 6 months) and we say the style edition must be finalized before then, then we can get feedback from `rustfmt` (on whether what we have is reasonable for rustfmt to implement/test/finalize after that date) and scale our ambitions accordingly. Caleb: I'm in violent agreement with both of you. I'll add that what Jane was describing as far as the mechanism already exists. `version = "Two"` is now a misnamed variant that's effectively style edition 2024. It should be called the 2024 edition. Jane: I'm hearing a proposal forming. I want to explicitly write it out and assign it to someone to be in charge of making this happen. Let's set a cutoff date N that's M months ahead of the date for the language as a whole. Let's write a policy describing the train, what we just discussed, and have someone in charge of writing that policy. Caleb: Agreed. I'm happy to take on that action item. There might be a second action item to check in with whoever would know in the project if we have a target date for 2024 (it's actually Josh). How hard of a date do we want this to be when we set it. How hard is the feature freeze, and do we need to codify that in this policy? Josh: We should pick a date for major feature freeze. That's when we're not going to add new major features to the style edition. But we may still make bug fixes, etc. Jane: Looping back, we should have two dates, one for major features, and another date for bug fixes. My own thoughts. I'm not feeling like the date should be super dogmatic. If we later think of a major feature that we really think should be included, we should have the room to do that. So we should think about that with respect to the policy. But of course, the policy can always be changed. People may often think the policies in the project are too set in stone. People should expect us to adjust dynamically. Josh: No objections to being softer on the feature freeze. The critical date is picking the "more or less" freeze date, maybe 6 months. What happens after that is maybe like other teams treat "beta backports". We'll need `rustfmt` on board for this. Caleb: Preemptively asking questions. I'd assume that this date will be something that t-style and the `rustfmt` teams will agree on, and we're not commiting to N - 6 months for future editions? Josh: We didn't start the concept of style editions until well into the 2024 edition; in the future (2027+) we should have more lead time (e.g. a year). TC: Agree with all of the above 100%. Jane: Caleb has agreed to take on writing a policy for that. We're tentatively using 6 months, but Caleb will come back with a firm proposal after talking with the `rustfmt` team. The "beta backport" language makes sense. We'll iterate on the policy over time. Jane: No objections? None. Jane: Moving on, with the remaining 5 minutes. Anything else to discuss? Josh: The discussion on #113394 probably fits? Consent.... yes. ##### #113394 Josh: We want to make sure to get the last things into the style guide that want, the current one, before we snapshot it. But on the other hand, I don't object to snapshotting the style edition before those are all merged in. Caleb: Agreed; I'll take ownership of making sure the commits that we want go in first. There is one commit that I do want to see pulled in before we snapshot. It'll happen this week. Josh: The future is now. The compiler does now reject the code discussed there. Not comfortable porting the language verbatim because we need to check. Caleb: The exception about adding or removing a semicolon does need to be reflected in the guide. Josh: As written, it was very much "may" kind of language. I've been doing work to normalize those. I'd love to see that shored up. Caleb: Will do. *End of meeting.* #### Review Prior Action Items ###### Completed ## 2023-07-19 ### Attendance Members: Jane, Josh Triplett, Michael Goulet, Caleb (kinda but really late) Guests: Jubilee, TC ### Agenda * Agenda consent + Check-in * Review prior action items * Backlog review and prioritization * (Explore/Decide) Decide about handling formatting for inline assembly (all editions, or 2024+) - https://github.com/rust-lang/style-team/issues/152 #important * Meeting Check-out ### Minutes (check in) Josh added items to the backlog for prioritization later: - "Fix the style meeting invite" (immediately resolved by MG) - "Talk about pending PRs" (action items) (backlog) #### Review Prior Action Items * Jane to follow up on feedback on [policy review process proposal](https://github.com/rust-lang/style-team/pull/176#discussion_r1222047066) and [Point of order policy proposal](https://github.com/rust-lang/style-team/pull/176#discussion_r1159031497) * (Decide) complete discussion on https://github.com/rust-lang/style-team/pull/176 (team policy and charter) #important * Fix the style meeting invite (has link to old minutes doc) [MG: DONE] #### Decide about handling formatting for inline assembly (all editions, or 2024+) Proposal (Josh): this has been stable longer than let-else, and there's more of it in the wild, so it'd be too disruptive to start formatting. Propose to do it in 2024. Decision: Do it in 2024 style edition. ## 2023-07-12 ### Attendance Members: Caleb (lead, secretary), Michael Goulet (compiler-errors, facilitator), Jane, Josh Triplett Guests: TC ### Agenda * Agenda consent + Check-in * Review prior action items * (Explore) Type aliases with where clause in "new" position (retroactive n.b. - this actually became a "decide") * (Explore) What process should we follow for prototyping changes to formatting (e.g changes to heuristics)? Should we implement prototypes of multiple heuristics in rustfmt in order to try them on various codebases? Or should we try them manually on a few dozen samples first, and consider that sufficient to be worth a preliminary selection and implementation for prototyping? How easy/hard is it to try things out in rustfmt? * Meeting Check-out ### Minutes #### Review Prior Action Items ###### Completed * [x] Michael will send a PR editing https://github.com/rust-lang/rust/blob/master/.github/ISSUE_TEMPLATE/tracking_issue.md and I-lang-nominate-ing it: DONE https://github.com/rust-lang/rust/pull/113586 #### Type aliases with where clause in "new" position https://rust-lang.zulipchat.com/#narrow/stream/346005-t-style/topic/where.20clause.20position.20in.20type.20aliases https://doc.rust-lang.org/nightly/style-guide/items.html#where-clauses Caleb: Style guide has prescriptions for "type aliases" (top level and assoc tys), based on old position of where-clauses. Syntax change was made, new position has no guidance. MG: As long as new position is not actually wording-incompatible, then we could do extension from wording of old position and fix it in 2024 if we're unhappy with it. Josh: Yeah, would like to adapt old formatting. May need style guide tweaks to make this work. Copy paste language having to do with `) where`. Josh: AI for someone to take on effort to patch with a few examples MG: Agree Caleb: Current example could just be flipped Josh: Indent would be needed Subsequent discussion around whether breakage should/does occur before/after the assignment operator Josh: If rustfmt matches current guidance around breaking after operator then we'd be bound by edition constraints MG: rustfmt actually already breaks before the operator. so this is similar to previous case of style guide bug MG: two things, fixing existing text and updating for "new" where clause position MG: Do we need an FCP for this? Josh: Which portion(s)? MG: both since this will probably be updated Caleb: Not for bug fix, maybe for new where position Josh: agreed on both counts, no FCP for the bugfix, FCP for the proposed frmatting for the new where position Proposed formatting: ``` type Foo<T> = Bar<T> where T: Bound; ``` Section outline (after bugfix and new style): - Here's how to format type aliases in general (one line if possible, break before `=` if necessary) - Here's how to add a where clause to that - Here's the special case for adding a where clause before the `=`, for which you outdent the `=` to make it easier to distinguish from the where clause bounds. But prefer putting the where clause at the end. AI: Michael to take both items (bugfix and missing style), with FCP. Josh to provide timely review on the bugfix TC: question about retroactively discovered bug in the style guide that exist in older/snapshotted versions Josh+others: let's take this one to zulip as it will be a longer discussion than we have remaining time for #### What process should we follow for prototyping changes to formatting? Style changes we're contemplating for future style edition, and want to identify good workflow between Style and Rustfmt teams to be able to prototype and test (both impact/desirability of formatting and implemetnation feasibility) Caleb: Complexity it depends on context, chains would be hard, empty match arms would be easy. One potential hesitation from rustfmt side would be doing too much experimentation that would strain rustfmt team bandwidth Josh: Where would "small" heuristics fall on that scale from complex to easy (assuming new heuristic is relatively simple)? Caleb: easier end of the scale. config options determining "small" are easily locatable within the code and will typically (possible exclusively) be located in a single place so will largely be a function of the complexity of the new heuristic TC: Notes the implication between rustfmt team bandwidth and the proposed lang stabilization process changes to include style guide text, group decision to continue discussion in zulip ## 2023-07-05 ### Attendance Members: Caleb (lead, secretary), Jane (facilitator), Josh Triplett Guests: TC ### Agenda * Agenda consent + Check-in * Review prior action items * (Decide) If we fix the style guide to match rustfmt, does that require an FCP? * related to: https://github.com/rust-lang/rust/pull/113145 * (Explore) Type aliases with where clause in "new" position * https://doc.rust-lang.org/nightly/style-guide/items.html#where-clauses * https://rust-lang.zulipchat.com/#narrow/stream/346005-t-style/topic/where.20clause.20position.20in.20type.20aliases * Meeting Check-out ### Minutes #### Review Prior Action Items Discussion around how we handle pending PR reviews, and general agreement that we don't need to capture individual action items nor backlog items for specific review and re-review. Consensus that we could have one high level item when necessary (e.g. desire to discuss proposed policy as opposed to individual review action items for each person) ###### Completed * [x] Josh to review [policy review process proposal](https://github.com/rust-lang/style-team/pull/176#discussion_r1222047066) * [x] Josh to review [Point of order policy proposal](https://github.com/rust-lang/style-team/pull/176#discussion_r1159031497) #### Is FCP needed to update Style Guide to match current rustfmt behavior Question originated around https://github.com/rust-lang/rust/pull/113145 What process should we follow for changes to the Style Guide that make it match the current behavior of rustfmt? Caleb: And are changes to the Style Guide considering "breaking" IFF it conflicts with rustfmt behavior (what if there are other formatter/tool consumers of the Style Guide) TC: How much consensus is needed to determine whether a conflict is a Style Guide bug or a Rustfmt bug? Are there any cases where you would not want to fix the style guide if it were a style guide bug? Josh: We adopted a policy around how we incorporate changes based on wanting to prevent rustfmt from introducing churn/CI breakage, that in turn translates to if/how/when Style Guide is updated. Josh: Current behavior around assignment operator is different than all other bin ops, elsewhere in the style guide, and general expectation. Modifying rustfmt behavior to match current text would be breaking and absolutely need FCP, but that's not the scenario at hand. Updating the Style Guide to describe rustfmt's current behavior doesn't count as a breaking change, it's not irreversible; since someone can always propose making the breaking change ("no, really, we want the text we originally had and rustfmt should make the corresponding breaking change") subsequently, the bugfix is reversible. Jane: Agrees with Josh's perspective around reversibility. Feels there's a false dichotomy, where there's an inherent breakage (alternatives such as adding notes to guide stating that rustfmt doesn't match what the style guide says). Tend to bias towards low overhead and trusting in the two people, doesn't necessarily feel an FCP is necessary, especially when there's a member from both T-style and T-rustfmt. Caleb: Want to raise a question: does the style guide consider rustfmt the primary/only consumer, or does the style guide take other tools into account. That may impact whether we consider a style guide change a breaking change. TC: Overlap between prior points, especially if Style Guide is authoritative since text could note rustfmt variation. Difference between looking forward vs. backward. For 2024 Edition & beyond could treat Style Guide as authoritative which could be consumed by broader community/other tools. If we treat current rustfmt behavior as default/desired formatting behavior (which should warrant an FCP), and so any variation in style guide could be treated as bugs, and then reviewed by style team for potential inclusion in future edition Josh: There are clearly other tools which may wish to consume the Style Guide. Design process of such tools that follows guide to the letter would include running against lots of Rust code and if differences occur then likely bug in tool or (). Has similarities to Rust Spec, and if/when encounter something in the spec that doesn't match the behavior, could be a bug in the spec or could be a bug in compiler. Precedence in Rust ecosystem for pragmatism with breaking semantic changes that have no impact being accepted (no crater failures). Josh: Propose (with FCP) text to the top of the Style Guide clarifying that if differences exist between Style Guide or Rustfmt then could be a bug in one or the other and investigation is needed. And that implementations of another formatting tool should check their behavior against the established corpus of Rust code (as commonly formatted by rustfmt) and if there are differences that might be a bug in their tool, rustfmt, or the style guide, but that we will *typically* err in the direction of not causing widespread breakage. Jane: If we give guarnatee that current rustfmt behavior is correct in this style edition. What happens after 2024 edition Jane: Disposition towards Caleb's question, enable ecosystem/community formatters. But maybe not since Style Guide establishes defaults that formatters would still be implementing Caleb: mouth words Jane: In summary, if conflict identified (style guide prescriptions and rustfmt behavior not matching), there's a bug and to Josh's earlier proposal, when there's a bug in the style guide we can have flexible, less formal process for fixing bug in style guide ## 2023-06-28 ### Attendance Members: Caleb (lead, secretary), Michael (facilitator), Josh Guests: TC ### Agenda * Agenda consent + Check-in * Review prior action items * (Decide) Style rules for empty match arms - https://github.com/rust-lang/style-team/pull/147 (10 mins) * (Inform) Discussion about the "code string" proposal and the unusual dynamic it might have with T-style * (Decide) Review formatting changes for restrictions RFC https://github.com/rust-lang/rust/pull/106074 * (Explore) Only if time remaining: Discuss actual style for the "code string" proposal * Meeting Check-out ### Minutes #### Review Prior Action Items ###### Completed * [x] Josh - review [nightly style policy](https://github.com/rust-lang/style-team/pull/180) then check your FCP box at: https://github.com/rust-lang/rust/pull/111119#issuecomment-1597627591 * [x] Michael will edit #111119 specifying that formatting for nightly style items can be parked in style-guide/nightly.md (or whatever) #### Style rules for empty match arms https://hackmd.io/nl-3kKGYTL-TGG8DWJ8fgA#Empty-Match-Arms https://hackmd.io/nl-3kKGYTL-TGG8DWJ8fgA#empty-match-arms ##### prior discussion: {} vs () Josh: Only reason unit works is for a match arm being used for control flow without returning a value. Braces work the same way, and the return result is also a unit. Unit explicitly comes across as I am returning a value. Braces indicates control flow block that does nothing, is important implementation detail of Rust, but not something typically thought about/intuition for developers. Josh: I believe braces are obviously right solution. Need to do this in a style edition, though, to avoid a breaking change to formatting. Michael: Maybe not fully in agreement with unit vs braces argument because match can also be used in expression position. Returning unit indicates explicitly not doing anything meaningful. I like braces aesthetically. Jane: finds Michael’s reasoning somewhat compelling. Wonders if we should have position-dependent formatting, questions whether it’s a logical. Initial reaction was strong preference for braces. Wants default style to be intuitive and not require additional thinking, especially during earning learning stages, wants to avoid “why is this turning into an empty tuple” questions. Caleb: Honestly don’t care much, would rather have an answer so rustfmt has direction. re Jane’s question about position, but we do have existing rules in style guide that are dependent on position. There is precedent. ##### Today's discussion: Caleb: This was an item that came from the old style team days. Josh and Michael: Prefer {} over () Caleb: No technical limitations, just a matter of opinion Michael: Maybe match can be used as an expression, and unit feels more like a value Josh: Comparison to end of function and questions why one would explicitly return () in that context Caleb: We need an action item for how to deal with style edition 2024-specific changes Josh: Part of the reason this was being asked about async in Zulip. Would be willing to take action item to update style guide with text/structure to differentiate between style editions AI: Josh to add PR to link 2021 style guide via a link Michael: Brings back the discussion about tags vs. commit hashes Josh: Regarding TC's question for normalizing `{ () }` to `{}`, should be a separate proposal. Josh: Have concrete proposal around tags vs. commit hash. Submit a PR now using comit hash, and then use next Rust release's tag as archival and link to it. TC: not proposing separate normalization, but similar reasoning could apply TC: If we had `{ () }`, is that considered an empty match arm? Josh: `{()}` could be a lint for example, not just handled by style Josh: Actually, we do normalize empty braces to the expression inside it. TC: Perhaps we shouldn't have that behavior Josh: Notes the differences between the persona where an experienced dev likely did so intentionally though a new Rust dev more likely didn't Discussion about style guide design principles; someone may want to add a design principle for how we handle experienced Rust developers vs people learning Rust. #### Code string literal RFC-3450 https://github.com/rust-lang/rfcs/pull/3450 Josh: new proposal to deal with challenges in getting proper indentation of code within string lits. difficult/frustrating to do with existing mechanisms. new proposal strips/modifies leading indentation Josh: Tradeoffs ```rust let value = bikeshed#" indented code # Indented by 4 under current proposal. or anything else "#; // Option: Keep the closing quote at prevailing indentation. // if you want a zero base indentation in the code block let value = bikeshed#" unindented code # Indented by 0 or anything else "#; // Option: Indent the closing quote. let value = bikeshed#" unindented code # Indented by 0 or anything else "#; // many bikesheddable variations, notably adding some indicator after the opener to select between semantic interpretations (e.g. strip longest common indent vs use indentation of closer) let value = bikeshed#"- unindented code or anything else "#; // caleb: what if we always wrapped in cases that have a preceding operator? let value = bikeshed#" "#; // josh: there's also the possibility of stacking bracketing constructs, notably with print/format, where the semantics here would determine how readable the result would be: print!(bikeshed#" here's some stuff - some more stuff - even more stuff "#); // normally we'd outdent this // caleb: we could force a wrap in the higher construct though // josh: we could force a wrap, but that would prevent some possible formatting options we might like/prefer // TC: In the Zulip thread, I've been suggesting that the closing quote is different than, e.g. a closing array bracket, since a string is a single literal, and the closing quote is semantically part of the string. // josh: Things like the ability to stack within another bracketing construct, notably as a function argument, are part of why I feel like it has a lot of similarity with bracketing constructs; consider formatting for both the zero-placeholder print case and the many-placeholder print case. // josh: should we maybe take this to Zulip? ;) (caleb: thumbsup. i guess i should read that long zulip thread on this) ``` Caleb: There are some places where rustfmt might need to add indentation? ## 2023-06-21 ### Attendance Members: Caleb (lead, secretary), Michael, Jane (facilitator), Josh Triplett Guests: ### Agenda * Agenda consent + Check-in * Review prior action items * (Decide) Nightly style policy: explore and decide how feature stabilization interacts with the style guide and rustfmt implementations (timebox 15 mins) * (Explore) continuing review of 2024 style edition suggestions doc https://hackmd.io/SKGaTg6lSs6sBjANQKBmBA * Meeting Check-out ### Minutes #### Review Prior Action Items ###### Completed #### Style Guide interaction with stabilization MG: tl;dr nightly style policy articulates new checklist item for feature stabilization to include style guide codification of rules. inter-team considerations to be discussed with t-lang. unsure how to best proceed/surface with lang Jane: clarification question MG: our policy states this, but not necessarily binding on t-lang Josh: One thing seeking clarification on style policy -- r-l/rust PR changes the style guide says style guide doesn't prescribe syntax, but nightly guide says that it may or may not. MG: Less about it not being in style guide, more about it not being binding. Caleb: seems like we're winding back an earlier decision aka "we're not going to land unstable formatting into the style guide, just make recommendations and draft PRs", I thought this discussion would focus on lang team interaction during stabilization Josh: not trying to reverse decision, just trying to remember. agreed with caleb's point about intermixed stable vs. nightly in-style guide. cargo team has a practice where docs are stable only, and only a single page with unstable content that gets moved over as part of stabilization. not explicitly proposing that for style guide, but would be open to doing something similar Caleb: digital nod MG: Josh's proposal sounds concrete. Shouldn't have open PRs running for the lifetime of a feature, having a separate nightly-area would be better. Could use this with lang Caleb: nods again Jane: +1 to MG's comment. For lang team interactions we don't have to solve everything, can iterate. What action items MG: proposal of two things, (1) will modify the r-l/rust pr to reflect this (articulate where wip nightly rules are captured, possibly `nightly.md`). (2) will reach out to t-lang for ascent on incorporating style guide aspect in feature/lang stabilization process Josh: suggests sending a pr for [the issue template](https://github.com/rust-lang/rust/blob/master/.github/ISSUE_TEMPLATE/tracking_issue.md) with the text for checkbox we're proposing and mark as lang nominated for discussion at next lang meeting Josh: Procedural note, do we want to uncheck FCP boxes? Jane: Trust Michael on this Josh: Me too Caleb: Agreed Josh: Will add concern just to note the text is being updated AI: Michael will send a PR editing https://github.com/rust-lang/rust/blob/master/.github/ISSUE_TEMPLATE/tracking_issue.md and `I-lang-nominate`-ing it AI: Michael will edit #111119 specifying that formatting for nightly style items can be parked in `style-guide/nightly.md` (or whatever) Two action items for Michael, (caleb will capture those up top later after meeting) #### Continued review of 2024 Style Edition changes Continued in https://hackmd.io/SKGaTg6lSs6sBjANQKBmBA ## 2023-06-14 ### Attendance Members: Caleb (lead, secretary), Michael , Jane (facilitator), Josh Triplett Guests: TC ### Agenda * Agenda consent + Check-in * Review prior action items * (Explore) Continue reviewing formatting changes for next edition proposed by @Josh Triplett in https://hackmd.io/SKGaTg6lSs6sBjANQKBmBA #important (goal: shipping 2024 style edition) * Meeting Check-out ### Minutes (check-ins) #### Review Prior Action Items ###### Completed * [x] Michael to edit PR (https://github.com/rust-lang/style-team/pull/180) tracking Jane's known concern in a separate section for revisiting. * [x] Jane to draft proposal for member characteristics #### Continue exploring 2024 style proposals Discussing 2024 style proposals in: https://hackmd.io/SKGaTg6lSs6sBjANQKBmBA ## 2023-06-07 ### Attendance Members: ~~Caleb (lead, secretary)~~, Michael (secretary), Jane (facilitator), Josh Triplett Guests: TC ### Agenda * Agenda consent + Check-in * Review prior action items * (Explore) review formatting changes for next edition proposed by @Josh Triplett in https://rust-lang.zulipchat.com/#narrow/stream/353175-t-style.2Fprivate/topic/Initial.20style.20proposal.20thoughts #important (goal: shipping 2024 style edition) * Meeting Check-out ### Minutes (check-ins) Discussing 2024 style proposals in: https://hackmd.io/SKGaTg6lSs6sBjANQKBmBA #### Review Prior Action Items ###### Completed ## 2023-05-24 ### Attendance Caleb (lead, secretary), Michael, Jane (facilitator), Guillaume (guest observer) ### Agenda * Agenda consent + Check-in * Review prior action items * (Explore) Style team membership growth * Meeting Check-out ### Minutes #### Review Prior Action Items ##### Completed * [x] Caleb will leave his blocking concerns inline so we can fix the user-facing/ordering of policy. (nb not really blocking concerns afterall, but feedback left inline) https://github.com/rust-lang/style-team/pull/180 ##### Style team membership group Collaborative working session on drafting some initial membership characteristics and next steps for growing the team, captured in separate hackmd linked below. https://hackmd.io/PHyeLQOGRpiu2ExN0nTjPQ ## 2023-05-17 ### Attendance Caleb (lead, secretary), Michael, Jane (facilitator) ### Agenda * Agenda consent + Check-in * Review prior action items * Capturing non-blocking concerns * Meeting Check-out ### Minutes #### Review Prior Action Items ###### Completed * [x] Michael to open PR in r-l/rust to add line (or two) to style guide clarifying nightly syntax position - https://github.com/rust-lang/rust/pull/111119 * [x] Michael to open PR in r-l/style-team to tactically add policy/posture on nightly syntax as separate doc - https://github.com/rust-lang/style-team/pull/180 Michael: Existing comments on nightly policy PR are kinda wishy-washy Jane: My concern was not blocking Michael: We should just track it later Caleb: Does have changes that he wants to propose Caleb: To be more precise, nightly style policy should be user-facing. Wording needs reordering #### Capturing non-blocking concerns Jane: in sociocracy framework secretary in charge of capturing and tracking concerns. want to be mindful of roles and associated work. perhaps minutes doc could be used Michael: feels like concerns should live within policy itself (e.g. inline fixme). somewhat disconnected if separated into minutes, and not necessarily readily available to those who are not attending meetings. Different than the role revisiting (e.g. quarterly secretary). Caleb: existing processes used elsewhere across the project, leans towards association/adjaceny in PR (rfcbot concerns) Jane: rfcbot concern is blocking objection. no mechanism for non-blocking, if non-blocking is only in PR then it can be lost upon PR merge. agreement with Michael's proposal Caleb: yup confirmed, brain miss on my end as my comment was a blocking concern Jane: Non-blocking concerns will be added inline in the policy (perhaps in a dedicated section at the bottom or whatever). Should have review date for policies scheduled. 4 months proposed Michael: Agree with reviewing, 4 months may be too short Caleb: Same initial reaction, is 4 months the right interval? From day job, 12 months is more normal. Same time, we don't have too many policies, so revisiting them more frequently is fine. Jane: Agree 4 might be pushing it. Can always review ad-hoc as needed, 12 months could be reasonable as a backstop Consent to incorporating policy review dates, 12 months for nightly policy Caleb: Also add policy review item to backlog with associated date Jane: Agreed Michael: Agreed, but should stay at bottom of backlog to not cause noise ACTION ITEM: Michael to edit PR tracking Jane's known concern in a separate section for revisiting. ACTION ITEM: Caleb will leave his blocking concerns inline so we can fix the user-facing/ordering of policy. ACTION ITEM: Add a 12 month review date for this nightly doc, record in team doc and policy. #### Style team membership growth Caleb: Previous consent that we should document desireable characteristics for style team membership as part of an initial step towards growing team. Not captured as an action item and not assigned Jane: Aligns with recollection of plan, don't recall if we discussed specifics of characteristics Caleb: Not really, only an example or two Jane: Agreed with capturing this, likely overlap in thinking around those characteristics but probably best proposed as draft by one person. Will take aciton item AI: Jane to draft proposal for member characteristics #### Nightly style policy changes re: Caleb Caleb: We should have an opener that states that style guide position again. Caleb: Then we can segue into process. Michael: Curious if copying in content from style guide text changes this would cover things Caleb: Realizes the all important distinction between the style guide (user facing) and the t-style posture/policy/procedure around (a) preferring some level (iterative) formatting support for new/nightly syntax vs perfect and stable formatting and (b) how the related tools/teams go about doing that. Notes that file name in r-l/style-team threw him off Michael: Would \*-procedure.md work better? Caleb: Probably yes ## 2023-05-10 Cancelled due to lack of quorum ## 2023-05-03 Cancelled due to lack of quorum ## 2023-04-26 ### Attendance Caleb (lead, secretary), Michael ### Agenda Didn't have a quorum, open/unstructured chat on a couple items ### Minutes #### Review Prior Action Items ##### Completed * [x] Caleb to open PR in r-l/rust adding let chain rules to Style Guide ## 2023-04-12 ** Meeting was cancelled due to most members being unavailable ** ## 2023-04-05 ### Attendance Caleb (lead, secretary), Michael, Jane (facilitator) ### Agenda * Agenda consent + Check-in * Review prior action items * (Explore) Backlog triage * (Decide) Policy for formatting of nightly language items #urgent #important * (Decide) let-else formatting question raised by t-rustfmt #urgent #important * (Explore) Style team membership growth #urgent #important * Meeting Check-out ### Minutes #### Review Prior Action Items * Jane: "point of order" not done, but will likely be done today * Caleb: "let chains" not done, but will likely be done prior to next meeting (finally) ##### Completed * [x] Michael to work with infra to get t-style issue edit permissions in r-l/rust * [x] Caleb to edit r-l/rust tracking issue with link to rustfmt issue once perms given #### Backlog Triage Minutes not explicitly taken, conversation and outcomes reflected in updated backlog #### Policy for formatting nightly language items https://rust-lang.zulipchat.com/#narrow/stream/353175-t-style.2Fprivate/topic/nightly.2Fexperimental.20syntax.20posture Caleb: Recapped linked thread that attempted to consolidate and summarize with final questions Jane: Haven't read but will do so Michael: Have read, thumbs up Jane: (read) Yes, agreed Caleb: With unanimous agreement we'd have two action items. (1) create artifact in r-l/style steam articulating procedure/posture on nightly syntax and (2) create PR in r-l/rust to update style guide text with summarized position Jane: Latter would be a subsection of team policy. Understand that could be blocker given current state, wouldn't be opposed to starting with a separate document and then later moving it into main policy doc due to benefits the single doc provides Michael: Sure, as soon as we have a policy doc we can copy or link it in. However, would object to blocking the codification of the nightly syntax posture unless we're going to heavily prioritize policy doc work and anticipate finishing it soon Jane: No objections to tactical approach of adding as a separate doc initially, with plan to consolidate Jane: Not exactly clear what the rl/rust pr will contain. Links to the style team repo? Caleb: Yes, one-liner of "no prescription for nightly syntax" just in case people look at the style guide. Being able to see the section in the style guide is useful. Jane: -Confused on ordering- Michael: r-l/rust PR will be blocked on FCP until the actual recommendation in style team repo is landed. #### let-else formatting question raised by t-rustfmt https://rust-lang.zulipchat.com/#narrow/stream/346005-t-style/topic/let-else.20formatting.20and.20control.20flow.20expressions Caleb: Summarized offline chat. TL;DR no decision to make existing style rules cover expected/desired formatting.Potential considerations for 2024, and possible let chains as well #### Expanding Team Membership Open discussion about current team size and general consensus that growing the team would be valuable. A larger team would make absences less impactful in meetings, and also make it easier for current team members to feel more comfortable stepping down if/when they are ready to pursue other interests. Noted that current team membership reflects fairly large representation across the project, theme to continue with any expansion. Also noted certain skills/characteristics desireable for members, set of which worth listing in policy docs ---- Template for each meeting: ## Next Meeting Date ### Attendance Members: Caleb (lead, secretary), Michael, Jane (facilitator), Josh Triplett Guests: ### Agenda * Agenda consent + Check-in * Review prior action items * (inform) bullet point list of proposed agenda items (labeled either inform, explore, or decide) * Meeting Check-out ### Minutes #### Review Prior Action Items ###### Completed

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.