Skip to content

minutes 2016 09 08

Jump to bottom
Nick Cameron edited this page Oct 3, 2016 · 2 revisions

Agenda

(Annotated with notes)

  • OK on team composition? Yes.
  • regular meeting

    • time

      • nrc to post Framadate or Doodle poll for regular meeting time, after RustConf.

    • What time zones are people in, so we can schedule meetings accordingly?

    • format (agenda, review issues/PRs, irc vs video)

    • minutes

      • For IRC meetings, save the IRC log and post it...somewhere.
      • For video meetings, scott and ubsan to experiment with jit.si's ability to record to YouTube.
  • Go over the RFC process and check we're ok with it
    • file issues (tag?)
    • reach consensus
    • implementation PR
      • option
    • fcp? - no
    • RFC PR
      • default?
    • ready for FCP
    • FCP

Generally seems fine. Requirement for rustfmt patch discourages bikeshedding Some interaction with issue of rustfmt options (https://github.com/rust-lang-nursery/fmt-rfcs/issues/3 ). Proposal: RFCs should specify if the option should remain after accepting the RFC; if not, remove it.

  • re-visiting issues

No re-opening bikesheds without new information. Issues already resolved by a previous RFC will be closed. If someone wants to propose a new unconsidered alternative, or significant new rationale that the previous discussion didn't take into account, consider that new information. scott to document that in the fmt-rfcs README

  • asynchronous versus meeting-driven

Asynchronous, as lang and libs have moved to. No specific process to move from issue to RFC PR yet. Anyone can decide to advance it forward (with an implementation). But we should keep an eye out for issues stuck in bikeshedding and provide explicit guidance.

  • style guide vs spec

Style guide Maintain the style guide in the same repo as rustfmt Provide "implementers notes" that users don't need to read for any corner case only interesting to rustfmt implementers

  • What should the first RFCs be?

  • How to prioritize issues

    • Josh: Let's focus on items that don't already have any established conventions, before we review items that do. Before we bikeshed, let's make some concrete forward progress.
    • Agreement on this principle: don't reopen items that most people agree on or that most people follow a common convention for.

  • How to keep tabs on the 'overall vision'

  • Discuss and agree on guiding principles: https://github.com/rust-lang-nursery/fmt-rfcs/issues/4

  • AOB?

2:38 PM <•nrc> so, let us begin
2:38 PM <•steveklabnik> AND SO IT BEGINS
2:38 PM <•JoshTriplett> {
2:39 PM <•ubsan> THE BEGINNINING
2:39 PM <•nrc> first off, is everyone OK with the team composition? Or do we feel we are missing somebody essential?
2:39 PM <•JoshTriplett> Anyone I would have considered suggesting is already here.
2:39 PM <•ubsan> I'm personally good with it
2:39 PM <•brson> seems like anybody who cares enough to commit the time would have spoken up by tnow
2:39 PM <•scott> seems good to me
2:40 PM <•nrc> second question, is everyone's email OK? (The one I used in the group emails) I intend to get an email alias setup any day now
2:40 PM <•ubsan> yep
2:40 PM <•scott> yes
2:40 PM <•JoshTriplett> Yes.
2:40 PM <•japaric> yes
2:40 PM <•steveklabnik> c
2:41 PM <•nrc> OK, regular meeting time, anyone have constraints?
2:41 PM <•nrc> preferences?
2:41 PM <•steveklabnik> almost all my meetings are on weds
2:41 PM <•nrc> I thought we should go once every two weeks to start with
2:41 PM <•steveklabnik> so keeping that would be kinda cool
2:41 PM <•scott> maybe in the future, but I have essentially no constraints for the next month or so
2:41 PM <•brson> weds bad
2:41 PM <•brson> lol
2:41 PM <•steveklabnik> but hard to schedule
2:41 PM <•brson> i can put more mtgs in weds
2:41 PM <•brson> but i've similarly got weds loaded up
2:42 PM <•JoshTriplett> In terms of preferences, I'd prefer a Monday or Tuesday, though other days are workable.  In terms of constraints, I have various regular meetings during the week.
2:42 PM <•JoshTriplett> If we're looking to determine an optimal time, might I suggest we use one of the tools for doing so that lets you mark possible and preferred times, and look for the union of those?
2:43 PM <•nrc> yeah, that might be a good idea
2:43 PM <•scott> I think we should do that too
2:43 PM <•nrc> OK, I'll set that up, maybe after rustconf
2:43 PM <•ubsan> gcalendar?
2:43 PM <•JoshTriplett> Framadate or Doodle, for instance.
2:44 PM <•nrc> ok, then meeting format - irc vs video - preferences?
2:44 PM <•ubsan> video very much preferred
2:44 PM <•nrc> Seemed like there was a preference for video before
2:44 PM <•ubsan> for this kinda thing
2:44 PM <•JoshTriplett> IRC helps as a backup or asynchronous channel, but I'd prefer video or at least audio.
2:44 PM <•nrc> yeah, we'll always have irc too
2:44 PM <•JoshTriplett> More human. :)
2:44 PM <•ubsan> being able to talk stuff out is really nice
2:44 PM <•scott> I'm fine with both. video/audio will probably be faster for this
2:44 PM <•nrc> nice thing about irc is you get minutes with no extra work
2:44 PM <•JoshTriplett> I've had great luck with meet.jit.si
2:44 PM <•JoshTriplett> nrc: True.
2:44 PM <•ubsan> although, being able to record is also important
2:45 PM <•scott> I tried meet.jit.si and it worked OOTB for me
2:45 PM <•ubsan> that's a complaint I've had in the past about the lang/compiler meetings
2:45 PM <•nrc> japaric, steveklabnik brson are you all ok with Video
2:45 PM <•JoshTriplett> Proposal: we should normally have an agenda for our meetings anyway, to keep them on track, so I'd suggest we transform the agenda iteratively into minutes by recording results for each item.
2:45 PM <•brson> nrc: yes
2:45 PM <•steveklabnik> video being "video" or "vidyo"
2:45 PM <•japaric> +1 video, but not vidyo please
2:45 PM — •JoshTriplett would find vidyo quite a pain.
2:45 PM <•ubsan> yeah no not vidyo
2:45 PM <•scott> -1 for vidyo
2:46 PM <•steveklabnik> i like video but don't like vidyo
2:46 PM <•JoshTriplett> Any objections to meet.jit.si as a strawman proposal?
2:46 PM <•steveklabnik> i have never tried it
2:46 PM <•steveklabnik> so i'm neutral
2:46 PM <•ubsan> I can't read the webpage
2:46 PM <•JoshTriplett> We could give it a quick test after the meeting.
2:46 PM <•nrc> same
2:46 PM <•ubsan> so... :-1: for that?
2:46 PM <•nrc> ok good start :-s
2:46 PM <•JoshTriplett> ubsan: How so?
2:46 PM <•ubsan> JoshTriplett: no scrolling
2:46 PM <•scott> ubsan: it's better when you're actually in a call, I think
2:46 PM <•nrc> oh I got that too
2:47 PM <•nrc> I assumed there was nothing interesting below the fold
2:47 PM <•JoshTriplett> ubsan: ...ew, I'd never noticed that.
2:47 PM <•ubsan> scott: probably, but I would like to like... read about it lol
2:47 PM <•JoshTriplett> nrc: Nothing important, but that's still disconcerting.
2:47 PM <•nrc> anyone have any other suggestions for tech?
2:47 PM <•JoshTriplett> Oh, I see.  You can actually scroll with the keyboard, but mouse scrolling doesn't work.
2:47 PM <•nrc> or shall we try meet.
2:47 PM <•nrc> ?
2:47 PM <•JoshTriplett> ubsan: Does that work?
2:48 PM <•ubsan> https://jitsi.org/Projects/YouTubeLive makes me happy
2:48 PM <•scott> I'm willing to test multiple sites at the end of the meeting with whoever wants to stick around
2:48 PM <•ubsan> JoshTriplett: yep
2:48 PM <•ubsan> JoshTriplett: weird
2:48 PM <•JoshTriplett> ubsan: Yeah.  Worth a bug report, if someone wants to file it. :)
2:48 PM <•JoshTriplett> I listed a few other choices in the agenda, but I found jit.si to have the most complete set of features (such as sharing).
2:49 PM <•JoshTriplett> And it's actually open.
2:49 PM <•ubsan> yeah, despite no scrolling with mouse, I think it's the best option
2:50 PM <•ubsan> maybe hangouts as a backup
2:50 PM — •JoshTriplett files the bug on jit.si via email.
2:50 PM <•JoshTriplett> Anyone want a CC?
2:50 PM <•nrc> ok, can someone hang out with scott after the meeting to test?
2:50 PM <•ubsan> I'll do it
2:50 PM <•nrc> And assuming that works, we'll use that next time and see how it works
2:50 PM <•nrc> with irc for backup
2:51 PM <•ubsan> alright, cool
2:51 PM <•nrc> next item, the RFC process
2:51 PM <•ubsan> currently, seems pretty okay
2:52 PM <•nrc> are you all familiar with the proposal in the RFC?
2:52 PM <•JoshTriplett> One moment.
2:52 PM <•nrc> and think it is ok?
2:52 PM <•JoshTriplett> Isn't the next item the recording of minutes?
2:52 PM <•nrc> oh yeah
2:52 PM <•JoshTriplett> (asking because we should probably start doing so.)
2:52 PM <•ubsan> JoshTriplett: jit.si allows broadcasting to youtube live
2:52 PM <•JoshTriplett> (for this meeting)
2:52 PM <•JoshTriplett> ubsan: Fun.
2:52 PM <•nrc> we have irc this week
2:52 PM <•JoshTriplett> True.
2:52 PM <•ubsan> oh, nrc, you want to host the meeting minutes?
2:52 PM <•nrc> host?
2:53 PM <•ubsan> like, in a github repo or something?
2:53 PM <•JoshTriplett> Might it make sense to put them in a repository owned by the style team?
2:53 PM <•nrc> well, depends how we all feel?
2:53 PM <•nrc> we could
2:53 PM <•nrc> we don't *have* to
2:53 PM <•nrc> I think it would be better if we did
2:53 PM <•JoshTriplett> If we were using IRC exclusively, I'd suggest just pointing to botbot logs or similar.
2:53 PM <•ubsan> JoshTriplett: do we have a style team repo?
2:53 PM <•scott> I sent a request to botbot for this channel but who knows how long it'll be
2:53 PM <•nrc> an alternative is making notes
2:54 PM <•JoshTriplett> ubsan: Nothing other than fmt-rfcs right now.
2:54 PM <•JoshTriplett> Actually...
2:54 PM <•nrc> we can make a new one
2:54 PM <•nrc> easily enough
2:54 PM <•ubsan> nrc: I'm against that
2:54 PM <•nrc> notes or a new repo?
2:54 PM <•ubsan> nrc: they often don't get made, and then they're given up
2:54 PM <•ubsan> notes
2:54 PM <•JoshTriplett> Should we have a mailing list or Discourse, to go with the mail alias?  If so, perhaps we should just mail out the minutes after each meeting?
2:54 PM <•nrc> we should have a tag on internals
2:54 PM <•ubsan> direct recording is way better
2:55 PM <•ubsan> and far easier
2:55 PM <•nrc> I don't think we should have a mailing list - Rust project has been avoiding them in general
2:55 PM <•JoshTriplett> ubsan: You're suggesting recording the meetings via YouTube as the primary record?
2:55 PM <•ubsan> JoshTriplett: correct
2:55 PM <•nrc> will that work?
2:55 PM <•nrc> If that works, I'd be happy with it
2:55 PM <•nrc> if everyone else is happy being recorded
2:55 PM <•JoshTriplett> ubsan: That's definitely low-friction.  Two questions: 1) is anyone uncomfortable with that, and 2) is that sufficiently accessible to anyone who might want to review it?
2:55 PM <•scott> I'm fine with it
2:56 PM <•JoshTriplett> It's less work for us, and more work for anyone who wants the *summary* of our decisions.
2:56 PM <•JoshTriplett> (Of course, our most important decisions will be recorded in fmt-rfcs as resolutions.)
2:56 PM <•scott> I'm +1 for recording IRC minutes into a github repo. the same repo could house links to video recordings
2:56 PM <•ubsan> JoshTriplett: yeah, the important stuff gets to the fmt-rfcs repo
2:56 PM <•JoshTriplett> Fair enough.
2:56 PM <•ubsan> our reasoning goes into a youtube archive
2:57 PM <•ubsan> that like, 3 people watch
2:57 PM <•JoshTriplett> :)
2:57 PM <•ubsan> but those 3 people care!
2:57 PM <•scott> how do brson, steveklabnik, and japaric feel about video recording?
2:57 PM <•JoshTriplett> I find it mildly odd/discomforting to record video meetings, but I won't object to it if everyone else is fine with it.
2:57 PM <•steveklabnik> i like..... it's fine. i don't know how useful it is
2:57 PM <•japaric> I'm not opposed but we should keep minutes because they are easier to read/grep
2:58 PM <•brson> i don't mind, but think it's unlikely anybody will watch them
2:58 PM <•scott> I'm also unsure how useful it is. if it's easy, I'd go for it, if it's hard to implement, I wouldn't bother
2:58 PM <•JoshTriplett> (Not because any of the information in the meeting is private, just because it can be a bit...stifiling?  Might make us disinclined towards small-talk niceties and personal asides.)
2:58 PM <•brson> maybe useful if they can be auto-transcribed
2:58 PM <•japaric> I don't know how many people will watch an entire hour of bikeshedding :-)
2:58 PM <•ubsan> brson: you would be shocked what bored college students watch at 2 in the morning
2:58 PM <simulacrum> brson: I think youtube auto-transcribes
2:58 PM <•japaric> but seems low effort on our side
2:58 PM <•JoshTriplett> simulacrum: *badly*, but yes. :)
2:59 PM <•JoshTriplett> It's definitely the lowest-effort option.  If we think we're unlikely to manage to do anything better, it's OK.  If we can manage to record minimal text minutes, I'd prefer that.
2:59 PM <•nrc> if the whole thing is low effort, then this seems fine
2:59 PM <•nrc> I find it very high overhead to record any kind of minutes
2:59 PM <•ubsan> JoshTriplett: the issue with minutes is (and I'd be fine doing those in addition) is ^
2:59 PM <•JoshTriplett> *nod*
2:59 PM <•JoshTriplett> I take minutes for a regular meeting at work.  Happy to do so, but it's a lot of work. :)
2:59 PM <•ubsan> and, for example, the lang team did minutes for a while, but then just stopped
3:00 PM <•nrc> ok, I propose we start with recordings and see how it goes, we can add notes/minutes if it doesn't work out so well
3:00 PM <•JoshTriplett> Question:
3:00 PM <•JoshTriplett> ubsan: Does it look like meet.jit.si supports turning the streaming/recording on and off dynamically during a meeting?
3:00 PM <•scott> I do like the idea of minimal minutes in the form of writing decisions into the agenda like JoshTriplett has done for the video call point
3:00 PM <•ubsan> JoshTriplett: I'm not sure
3:01 PM <•nrc> ok
3:01 PM <•nrc> RFC process
3:01 PM <•JoshTriplett> ubsan: If so, then I'd withdraw any small objection I had, on the basis that we can call in, delimit the formal meeting with the recording, and be comfortable small-talking before and after. :)
3:01 PM <•nrc> actually
3:02 PM <•JoshTriplett> In any case, agreed that we should go ahead and try it for next time.
3:02 PM <•nrc> scott - can you experiment with recording and let us know please?
3:02 PM <•ubsan> JoshTriplett: oh, yeah
3:02 PM <•ubsan> JoshTriplett: you can
3:02 PM <•scott> nrc: yes
3:02 PM <•JoshTriplett> Perfect.
3:02 PM <•nrc> cool
3:02 PM <•nrc> ok
3:02 PM <•nrc> RFC process
3:03 PM <•nrc> everyone familiar with it and OK with how it should work?
3:03 PM <•nrc> in particular, how it is a bit different from the current RFC one?
3:03 PM <•scott> see https://github.com/rust-lang/rfcs/blob/master/text/1607-style-rfcs.md#process
3:03 PM <•nrc> (I put an overview in the agenda too)
3:03 PM <•brson> tldr?
3:03 PM <•JoshTriplett> I've read it.  Seems like the biggest difference is "don't propose something without a patch to rustfmt"?
3:04 PM <•scott> yeah it sounds like rustfmt has to support the style first
3:04 PM <•JoshTriplett> Advantage: much less inclination to bikeshedding.
3:04 PM <•nrc> also, try and get rough consensus in issues before making a PR
3:04 PM <•nrc> yes
3:04 PM <•ubsan> nrc: it seems... fine? I don't have any objections, anyways
3:04 PM <•JoshTriplett> One disadvantage: it ties into the discussion about rustfmt having options for styles.
3:04 PM <•nrc> require a Rustfmt option between the issue and PR stages
3:05 PM <•JoshTriplett> If you have to add the support with an option, now rustfmt has an option.
3:05 PM <•nrc> I think we need options at least until this process is kind of settled
3:05 PM <•JoshTriplett> We might not want that option after the default changes.
3:05 PM <•nrc> so
3:05 PM <•nrc> putting aside the details of the option debate
3:05 PM <•JoshTriplett> nrc: OK.  We should probably address that item early on, but sure.
3:05 PM <•nrc> I think the RFC PR should specify which options remain on acceptance
3:06 PM <•nrc> and then we take out options from Rustfmt when the RFC is accepted
3:06 PM <•scott> I like that idea
3:06 PM <•JoshTriplett> nrc: Sounds good.  We might want an "unstable option" mechanism in the future, but that'll work for now.
3:08 PM <•scott> how long is FCP? the length of time between meetings?
3:08 PM <•nrc> ok, one question: should we FCP going from issue to PR? Or how do we signal that we are ready for that?
3:09 PM <•nrc> so, with the async RFC stuff, not necessarily
3:09 PM <•JoshTriplett> nrc: Well, at a minimum, going from issue to PR requires a rustfmt PR, right?
3:09 PM <•steveklabnik> i imagine _some_ of this kind of thing will shake out over time
3:09 PM <•nrc> we can start with a week and see if we need more
3:09 PM <•steveklabnik> we will develop a rhythm
3:09 PM <•scott> ok
3:09 PM <•nrc> JoshTriplett: yes
3:09 PM <•JoshTriplett> I don't think we need an FCP for moving from issue to PR; I hope we can do that by consensus.
3:09 PM <•nrc> but I kind of want an indicator for when we are ready for that
3:10 PM <•nrc> otherwise we could get a tonne of options really early
3:10 PM <•JoshTriplett> Good point.
3:10 PM <•nrc> JoshTriplett: one problem we found from other teams is its kind of hard to identify consensus
3:10 PM <•scott> nrc: you want to know when to go from fmt-rfcs issue to rustfmt PR?
3:10 PM <•nrc> without being super-explicit
3:10 PM <•nrc> i.e., checkboxes
3:11 PM <•nrc> scott: I guess so, yes
3:11 PM <•JoshTriplett> If we're going full-asynchronous, then yeah, we'd need an asyncronous way to confirm that all of us are in agreement.
3:11 PM <•nrc> or at least
3:11 PM <•nrc> if a person wants to do rustfmt implementation
3:11 PM <•nrc> but doesn't want to waste their time
3:11 PM <•scott> I guess we do need some way to decide which options to accept into rustfmt
3:11 PM <•nrc> when should they start working to be relatively safe?
3:12 PM <•scott> (if there are too many)
3:12 PM <•JoshTriplett> Are we looking to beta-test the asynchronous process *before* the rust RFC process does?
3:12 PM <•JoshTriplett> As opposed to waiting for that process to shake out?
3:12 PM <•nrc> JoshTriplett: nah, we'll figure it out as we go along
3:12 PM <•nrc> let it shake out
3:12 PM <•nrc> doesn't need to be perfect to start
3:13 PM <•JoshTriplett> nrc: Then I'd suggest that, for now, we decide whether to move from issue to RFC PR in a meeting, decide when to call FCP in a meeting, and conclude an RFC in the next meeting after FCP.
3:13 PM <•JoshTriplett> If the asynchronous process gets hammered out, we'll adopt it.
3:13 PM <•nrc> JoshTriplett: it kind of has - lang and libs are using async now
3:13 PM <•JoshTriplett> Ah, didn't realize that.
3:13 PM <•nrc> and it is much better - nice to have summaries in the PRs, etc.
3:14 PM <•JoshTriplett> Then, apart from the issue->PR readiness issue, any reason we shouldn't just adopt that unmodified?
3:14 PM <•JoshTriplett> nrc: (I'd assume you know that process well via those teams?)
3:14 PM <•scott> does the team even need to decide when issues move forward? I feel like a community member who sees an issue has a decent amount of support could just step forward and implement or write an RFC
3:14 PM <•steveklabnik> the teams are adopting the async process.... asynchronously
3:14 PM <•nrc> yeah, I think we should do that
3:14 PM <•nrc> JoshTriplett: ^
3:14 PM <•JoshTriplett> OK.
3:15 PM <•JoshTriplett> scott: I don't think it's a hard requirement, but I can imagine someone wondering if it's time to stop bikeshedding and start implementing/deciding.
3:15 PM <•nrc> scott: yeah, that seems reasonable
3:15 PM <•JoshTriplett> scott: Entirely too easy to just keep bikeshedding forever.
3:15 PM <•nrc> sometimes it is nice to be explicit
3:15 PM <•scott> I guess the team should step in if it's dragging on
3:15 PM <•scott> a community member can just beat us to the punch if they want
3:15 PM <•nrc> yeah, we should
3:15 PM <•JoshTriplett> So, process-light for now, and pay special attention to when we might need to explicitly say "let's move forward with this"?
3:15 PM <•nrc> yeah, let's try that
3:15 PM <•scott> we must be bikeshed watchdogs
3:16 PM — •ubsan watches careful
3:16 PM <•nrc> if we find its hard to see consensus we can add something more explicit
3:16 PM <•JoshTriplett> scott: That does seem like our most important job. :)
3:16 PM <•JoshTriplett> I do like separating issue and RFC more strongly, in the spirit of "hold off on proposing solutions".
3:17 PM <•nrc> I had "revisiting issues" on the agenda, but actually I think we can deal with that if and when necessary
3:17 PM <•JoshTriplett> nrc: What did you mean by that item?
3:18 PM <•JoshTriplett> What happens if someone wants to change something already decided by an old RFC?
3:18 PM <•scott> I assume it's when someone makes an issue about something that was already decided another way by a previous RFC
3:18 PM <•nrc> if we make some decision, but then later make some other decision which makes the first one weird or wrong, do we want some process for re-opening the first issue?
3:18 PM <•nrc> Because generally we don't want to re-open bikesheds
3:18 PM <•nrc> e.g., ? currently being debated again
3:19 PM <•JoshTriplett> As a general principle, we don't want to reopen something without new information.
3:19 PM <•steveklabnik> yeah this is a good point
3:19 PM <•ubsan> JoshTriplett: but I imagine that new bikeshed would be new information
3:19 PM <•JoshTriplett> If someone wants to propose a new unconsidered alternative, or significant new rationale that the previous discussion didn't take into account, that might be reasonable.  If they just disagree with the decision, that's not sufficient to reopen anything.
3:19 PM <•scott> JoshTriplett: agreed. I think we can recognize this when we come to it
3:19 PM <•ubsan> like, just an example, set 4 space indent, then we choose to do 80 chars, that might reopen 4 space indents
3:20 PM <•nrc> it makes it easier to close issues/PRs if we write something down as a policy
3:20 PM <•JoshTriplett> ubsan: That's definitely new information, yes.
3:20 PM <•JoshTriplett> ubsan: But in that case, I'd think the 80-char proposal would need to make a decision on indent if those are believed to be tied together.
3:20 PM <•scott> I think the policy is "no re-opening bikesheds without new information"
3:20 PM <•ubsan> JoshTriplett: agreed
3:20 PM <•ubsan> but just an example
3:21 PM <•JoshTriplett> scott: Agreed.
3:22 PM <•japaric> I agree to that policy and I think that policy should be written down in the rfc repo README and re-stated when an issue is closed
3:22 PM <•JoshTriplett> japaric: Good call.  Who will write that up as a PR for fmt-rfcs README?
3:22 PM <•nrc> ok, can someone volunteer to do that?
3:22 PM <•nrc> heh
3:22 PM <•scott> I can make that PR
3:23 PM <•nrc> thanks!
3:23 PM <•nrc> ok, next up
3:23 PM <•nrc> style guide vs spec
3:23 PM <•ubsan> nrc: something like ubsan.github.io/style seems like a good way to go
3:23 PM <•ubsan> imho
3:23 PM <•nrc> the original RFC is very much written in terms of making a 'spec' for Rustfmf with a style guide as a side product
3:23 PM <•JoshTriplett> Is this a difference beteween "SHOULD" and "MUST", or a question of level of detail?
3:23 PM <•ubsan> (note: biased)
3:24 PM <•scott> nrc: I'm not sure I understand the difference
3:24 PM <•scott> I have some opinions for the style guide format, but is that the question?
3:24 PM <•JoshTriplett> I'd like to understand the distinction being made as well.
3:26 PM <•JoshTriplett> nrc: I didn't realize you were recording action items at the bottom of the minutes; I was recording them inline in the minutes. :)
3:27 PM <•scott> I like the inline decision notes, though :)
3:27 PM <•scott> not everything is an action item
3:27 PM <•JoshTriplett> (Aside: this is another good reason for video calls.  It's more difficult to stare silently at each other for several minutes. ;) )
3:27 PM <•ubsan> lol
3:28 PM <•nrc> so, the difference in my mind is a document targeted at implementers vs a document aimed at Rust users
3:29 PM <•scott> ah
3:29 PM <•nrc> the level of detail seems very different to me
3:29 PM <•nrc> and probably the tone too
3:29 PM <•scott> do you have an example? my gut reaction is that the rules should be simple enough that the detailed offered to the users is enough to implement rustfmt correctly
3:29 PM <•scott> I could see the tone difference
3:29 PM <•nrc> actually more the precision, rather than the level of detail
3:30 PM <•ubsan> nrc: I feel like something like the rustic style guide is a good example
3:30 PM <•scott> so, like more edge case examples that would inappropriate for a style guide?
3:30 PM <•nrc> scott: not a concrete example, but to be a bit more specific, how you describe interactions, a style guide can give two rules and let humans figure out how to combine them
3:30 PM <•ubsan> it's readable for a user, and implementable for an implementer
3:30 PM <•nrc> for rustfmt, you probably need to specify the interaction
3:31 PM <•JoshTriplett> I would prefer to see the guide written for Rust users, not for rustfmt implementers.  If we need additional information for rustfmt implementers for a corner case that *isn't* obvious from the user information, I'd suggest that we either let rustfmt serve as the disambiguating spec, or write that information down as an "implementer note" in the style guide.
3:31 PM <•scott> what if we wrote a style guide with an "implementer's notes" appendix or side-document?
3:31 PM <•nrc> there are a lot of edge cases that rustfmt wants too, more than I'd put in a style guide
3:32 PM <•scott> I'd prefer if the most effort is put into the style guide
3:32 PM <•JoshTriplett> ubsan: Leaving the question of content aside, I like the presentation approach of your style guide.
3:32 PM <•nrc> to be clear
3:32 PM <•scott> i.e. I currently consider the user-oriented style guide the main document
3:32 PM <•ubsan> agreed with scoot
3:32 PM <•nrc> I'm interested as much in the 'how' as the 'if'
3:33 PM <•nrc> I don't think a collection of RFCs will make a good style guide
3:33 PM <•JoshTriplett> If the corner case is important enough that users might wonder, add it to the body of the guide.  If the corner case is something users can safely gloss over and only rustfmt implementers will care about, we can have an "implementers note" aside for it.
3:33 PM <•ubsan> probably not
3:33 PM <•ubsan> @nrc
3:33 PM <•nrc> (but could be a good spec)
3:33 PM <•ubsan> ehhh
3:33 PM <•ubsan> I've tried writing a spec from the existing RFCs
3:33 PM <•scott> RFCs aren't always a good spec either, since they get superseded without being updated sometimes
3:33 PM <•JoshTriplett> scott: Right.
3:33 PM <•JoshTriplett> They're a good start.
3:33 PM <•ubsan> and they have varying levels of detail as well
3:33 PM <•nrc> ok, well, maybe spec is the wrong word
3:33 PM <•scott> or the implementation changes due to information learned during implementation without updating the RFC
3:34 PM <•nrc> but as a guide to what rustfmt should look like
3:34 PM <•JoshTriplett> One related concrete proposal:
3:34 PM <•JoshTriplett> How would people feel about the official style guide living in the same repository as rustfmt?
3:34 PM <•JoshTriplett> Specifically, so that rustfmt and the style guide can get patched in the same PR/commit?
3:34 PM <•scott> that seems okay
3:34 PM <•nrc> yeah, that is one of the alternatives in my mind
3:34 PM <•steveklabnik> ah that seems cool
3:35 PM <•nrc> the other is we do the two separately
3:35 PM <•JoshTriplett> (Also, an item for future meetings: should rustfmt move somewhere more official/integrated, like the rust repo, so everyone has it?)
3:35 PM <•steveklabnik> also, we are almost at an hour
3:35 PM <•nrc> the former is good because it keeps the guide up to date
3:35 PM <•nrc> but it raises the bar for PRs by a lot
3:35 PM <•scott> I'm thinking: style guide in rustfmt repo, with appendices for implementation details/edge cases/interactions and another for rustfmt's non-default options, which shouldn't be in the main style guide
3:35 PM <•JoshTriplett> nrc: That doesn't seem like a bad thing.  *Someone* has to write that documentation.
3:36 PM <•JoshTriplett> nrc: And the implementer of the rule/RFC/etc seems like the right person.
3:36 PM <•JoshTriplett> Same premise as tests; yes, requiring tests raises the bar for submissions, but that's a mentorship/guidance problem, not an argument for being more lax.
3:36 PM <•ubsan> yeah ^
3:37 PM <•JoshTriplett> I do actually have a 4-5 phone meeting right now.
3:37 PM <•ubsan> and we can give guidance/mentorship
3:37 PM <•JoshTriplett> I can stay on IRC and continue participating asynchronously. :)
3:37 PM <•scott> we have a later item "* How to keep tabs on the 'overall vision'". I think updating the style guide alongside RFCs will help with that
3:37 PM <•brson> one thing i would like is to have a running example that accumulates every decision and is cross-referenced to the rfcs
3:37 PM <•JoshTriplett> brson: +1
3:37 PM <•nrc> yes to both of these things ^
3:37 PM <•scott> good idea, agreed
3:37 PM <•brson> i think that wolud help maintain a sense of what all the little decisions add up to
3:38 PM <•nrc> ok, so I think we somewhat agreed about the style guide thing
3:38 PM <•JoshTriplett> scott: Somewhat, though I think that connects more to https://github.com/rust-lang-nursery/fmt-rfcs/issues/4
3:38 PM <•nrc> at least we can see how it plays out
3:38 PM <•nrc> I'll update the process with this
3:38 PM <•nrc> ok
3:39 PM <•nrc> we're out of time, but I did want to ask one more thing
3:39 PM <•nrc> how to decide what to work on first/encourage issues for?
3:39 PM <•nrc> should we seed empty issues as recommendations?
3:39 PM <•JoshTriplett> I'd added a suggestion to Etherpad saying that we should focus on things that *don't* have any established convention in practice.
3:40 PM <•nrc> or use tags for 'we think this is worth working on now' vs 'we should do this later'
3:40 PM <•scott> I agree with JoshTriplett's note in the etherpad. we should get uncontroversial stuff through first, to get the style guide and brson's suggested example code started easily
3:40 PM <•JoshTriplett> Not things that people mostly have a convention on, even if others disagree with that convention.
3:40 PM <•JoshTriplett> (e.g. let's defer the 4/100 2/80 discussion, please.)
3:40 PM <•ubsan> for example, lets just get tabs vs spaces done
3:40 PM <•JoshTriplett> (or 4/infinite </bikeshed>)
3:40 PM <•JoshTriplett> ubsan: Good call.  I don't think we'll have a problem with that one.
3:40 PM <•ubsan> and space before a function call
3:40 PM <•ubsan> i.e., foo () vs foo()
3:41 PM <•ubsan> and fn foo () vs fn foo()
3:41 PM <•JoshTriplett> With the convention being not-GNU-style, foo() and fn foo()?
3:41 PM <•ubsan> yes
3:41 PM <•nrc> these seem to be things that have well-stablished conventions
3:41 PM <•scott> nrc: yeah, that's the point
3:41 PM <•scott> at least to get them into the style guide
3:41 PM <•JoshTriplett> True.  I hesitate to even open items that seem closed now.
3:41 PM <•scott> I don't think they need RFCs
3:41 PM <•nrc> but I'd be happy to start with un-controversial things
3:41 PM <•JoshTriplett> I don't think they need RFCs either, and I don't think we should open any.  I think we need a baseline style guide.
3:41 PM <•nrc> scott: this seems to be the opposite of JoshTriplett's suggestion
3:42 PM <•scott> oh, it kind of it
3:42 PM <•scott> is*
3:42 PM — •JoshTriplett refines.
3:42 PM <•nrc> ok, that might be a good start
3:42 PM <•scott> well, I agree with JoshTriplett's suggestion for the first RFCs
3:42 PM <•JoshTriplett> I think we need a baseline record of mostly-uncontroversial existing convention.  *Not* via RFCs.
3:42 PM <•ubsan> hmm
3:42 PM <•scott> I think we should get a baseline styleguide before RFCs
3:42 PM <•nrc> we have a big PR with the start of the style guide with *very* uncontroversial things where we don't expect much discussion
3:42 PM <•JoshTriplett> scott: +1
3:42 PM <•ubsan> maybe just an RFC for a baseline?
3:42 PM <•scott> sure, a single baseline conventions RFC
3:42 PM <•JoshTriplett> nrc: Right.  And anything that has non-bikeshedding disagreement we can pull out and handle via RFC.
3:43 PM <•nrc> yeah it would need a PR, but perhaps not quite the same template format
3:43 PM <•scott> anything that is controversial in the baseline RFC is removed and becomes an issue
3:43 PM <•nrc> JoshTriplett: yes
3:43 PM <•ubsan> scott: seems good
3:43 PM <•JoshTriplett> nrc: Right.  And perhaps a PR to rustfmt rather than to fmt-rfcs. :)
3:43 PM <•JoshTriplett> (to integrate the doc)
3:43 PM <•ubsan> okay, another question
3:43 PM <•ubsan> static muts?
3:43 PM <•nrc> Hopefully, Rustfmt should do everything that is in the first PR
3:43 PM <•nrc> if it is not, then I would say it needs discussion
3:43 PM <•ubsan> they should be all caps, right?
3:44 PM <•JoshTriplett> ubsan: Personal opinion: caps == constant.
3:44 PM <•ubsan> JoshTriplett: but static UnsafeCell...
3:44 PM <•JoshTriplett> ubsan: globals are flagged by the compiler saying "you need an unsafe block for that..."
3:44 PM <•scott> I think static mut is all caps conventionally but I think it could become an issue
3:44 PM <•nrc> ubsan: meta-question specifying this, Rustfmt currently doesn't make this kind of change
3:44 PM <•nrc> it would be tricky
3:44 PM <•JoshTriplett> nrc: True.  And it's not possible in the general case.
3:45 PM <•JoshTriplett> nrc: (e.g. you have both FOO and foo.)
3:45 PM <•ubsan> nrc: true
3:45 PM <•ubsan> but it should still be in the style guide
3:45 PM <•ubsan> even if not automatable
3:45 PM <•JoshTriplett> I think it's reasonable to document them in the style guide, and perhaps rustfmt (or rustc) can flag them but not fix them.  As with non_snake_case.
3:45 PM <•ubsan> ^^
3:45 PM <•scott> agreed
3:45 PM <•JoshTriplett> Perhaps tag items that we don't expect rustfmt to fix, only flag.
3:45 PM <•nrc> there has been opinion expressed by the core team that we should focus on Rustfmt-able stuff rather than a general style guide
3:45 PM <•ubsan> I disagree with that
3:46 PM <•nrc> obvs, doesn't need to be a hard line
3:46 PM <•scott> there will always be style guide stuff that rustfmt can't do well, like variable naming
3:46 PM <•JoshTriplett> nrc: I think we should prioritize items that rustfmt can do automatically, but I don't think it should be a hard line.
3:46 PM <•scott> but I don't think we'll necessarily need to discuss that stuff a lot
3:46 PM <•nrc> yeah, that makes sense
3:46 PM <•JoshTriplett> We should hesitate to specify something rustfmt can't automate, but I can think of a few cases.
3:46 PM <•nrc> both the above
3:46 PM <•nrc> ok, I want to draw this to a close
3:46 PM <•ubsan> yeah
3:46 PM <•JoshTriplett> (Honestly, I'm *really* tempted to say, for instance, that breaking long lines automatically should require an explicit option to rustfmt, because it does so much damage sometimes.)
3:46 PM <•nrc> how should we start with the first PR?
3:47 PM <•scott> we could adapt ubsan's rustic style guide, just the most conventional parts
3:47 PM <•JoshTriplett> ubsan: With a couple of exceptions, I'd be fine with seeing your style guide become the initial proposal.
3:47 PM <•nrc> does someone want to take point on that or should we have some collaborative setup?
3:47 PM <•JoshTriplett> ubsan: (notable exception: if { long condition } and similar use of braces.)
3:47 PM <•ubsan> scott: it's getting redone right now
3:47 PM <•nrc> scott: I think we want to start with something much smaller than that
3:47 PM <•ubsan> by c74d
3:48 PM <•ubsan> JoshTriplett: yeah, sure
3:48 PM <•nrc> I don't want to be in a situation where we are modifying the base style guide
3:48 PM <•nrc> that adds a certain amount of momentum
3:48 PM <•JoshTriplett> nrc: Is there a base style guide we can start from?
3:48 PM <•nrc> no
3:48 PM <•ubsan> JoshTriplett: no
3:48 PM <•nrc> thus the question:
3:48 PM <•JoshTriplett> nrc: What do you mean by "modifying the base style guide" then?
3:48 PM <•nrc> does someone want to take point on that or should we have some collaborative setup?
3:49 PM <•nrc> the result of our first PR will become the base style guide
3:49 PM <•JoshTriplett> A collaborative setup seems helpful, but someone needs to take point so it doesn't languish forever.
3:49 PM <•scott> maybe just a few of us could meet more often to throw together the base document
3:49 PM <•JoshTriplett> I'm willing to help put that together.
3:49 PM <•scott> I am, too
3:49 PM <•nrc> yeah, I want to be quick with the base
3:49 PM <•ubsan> I will too
3:49 PM <•nrc> because we are kind of blocked on starting the main process until we have it landed
3:49 PM <•ubsan> I think rustic style guide is a fine base if you just tear out the controversial stuff
3:50 PM <•nrc> that seems a fine way to start
3:50 PM <•scott> we can pull text from it at any rate, if it fits
3:50 PM <•JoshTriplett> So, I have a proposal for the first item that, while not in rustfmt, seems sufficiently contentious to be not a convention.
3:50 PM <•JoshTriplett> "lining things up"
3:50 PM <•JoshTriplett> (Versus "indent but don't align")
3:51 PM <•nrc> I would like to be specific about this
3:51 PM <•ubsan> JoshTriplett: open an issue, so we can wrap this up? :P
3:51 PM <•JoshTriplett> ubsan: Will do.
3:51 PM <•ubsan> I need to do CSAW things :3
3:51 PM <•scott> should we (whoever is available) just meet as often as possible until we can submit the baseline RFC?
3:51 PM <•nrc> ok, ubsan scott or JoshTriplett can someone start a repo for the style guide and email the team
3:52 PM <•JoshTriplett> Standalone repo for now, until we get a draft?
3:52 PM <•ubsan> sure, I'll start it
3:52 PM <•nrc> yes
3:52 PM <•nrc> thanks ubsan 
3:52 PM <•JoshTriplett> Thanks.
3:52 PM <•nrc> ok, so lets call this meeting
3:52 PM <•nrc> thanks everyone!
Clone this wiki locally