<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 07/02/2014 11:19 AM, Gábor Lehel
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAPoegsy5epOVZcaJ4VxLgspYWh-s4bmEB0ey_Lhwk=EvWLfF6w@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>
                <div>
                  <div>
                    <div>
                      <div>
                        <div>
                          <div>Thanks, this is a good step, as is
                            delaying taking actions by a day as proposed
                            in the meeting itself.<br>
                            <br>
                            <br>
                            <blockquote style="margin:0px 0px 0px
                              0.8ex;border-left:1px solid
                              rgb(204,204,204);padding-left:1ex"
                              class="gmail_quote">
                              If you have any suggestions for how this
                              regular email or the process in general
                              could be improved, please let us know.</blockquote>
                            <div><br>
                            </div>
                            <div>Most fundamentally, what I'm wondering
                              is, why do most of the things discussed at
                              the meetings need to be discussed
                              separately in the first place? <br>
                              <br>
                              Why not have those discussions directly in
                              the comments for the respective RFC PRs?
                              Up to and including leaving comments like
                              "we suggest closing this, because
                              {justification}, unless someone convinces
                              us otherwise", "we suggest merging this
                              because {justification}", and so on. In an
                              ideal world, the meetings could merely
                              ratify the decisions which were already
                              evident from the PR discussions
                              themselves. This could also help avoid
                              situations where the two discussions end
                              up disjoint in some way, e.g. according to
                              this week's meeting notes @pcwalton and
                              @aturon essentially recapitulated the
                              exact same debate about the lifetime
                              elision "self rule" at the meeting which
                              @aturon and I had previously gone through
                              in the PR comments.<br>
                            </div>
                          </div>
                        </div>
                      </div>
                    </div>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    I would like to move in this direction, but like many cultural
    changes it will be gradual. The primary reason we do so much in
    meetings is because face-to-face discussions move much faster and
    involve much less argumentation than asynchronous online
    discussions. In the immediate future I'd like to put more pressure
    on meeting participants to express their opinions on the issue ahead
    of meetings, which this initiative Nick is working on helps by
    making it clear what issues are coming up.<br>
    <br>
    <blockquote
cite="mid:CAPoegsy5epOVZcaJ4VxLgspYWh-s4bmEB0ey_Lhwk=EvWLfF6w@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>
                <div>
                  <div>
                    <div>
                      <div>
                        <div>
                          <div>
                            <div>
                              <br>
                              <br>
                            </div>
                            <div>From the proposed-for-discussion list:<br>
                              <br>
                              <blockquote style="margin:0px 0px 0px
                                0.8ex;border-left:1px solid
                                rgb(204,204,204);padding-left:1ex"
                                class="gmail_quote"><a
                                  moz-do-not-send="true"
                                  href="https://github.com/rust-lang/rfcs/pull/122"
                                  target="_blank">https://github.com/rust-lang/rfcs/pull/122</a>
                                - Syntax sugar for prefix-style type
                                parameter lists - ben0x539<br>
                                    Sugary syntax for putting a group of
                                type parameters and their bounds before
                                a group of functions. Motivation is our
                                often unwieldly lists of type
                                parameters.<br>
                                    Not much feedback, but mostly
                                positive. Generally for the motivation,
                                rather than the solution.<br>
                                    Recommend close in deference to RFC
                                135 (where clauses) which solve the
                                motivating problem here, along with
                                other issues.<br>
                              </blockquote>
                            </div>
                            <br>
                          </div>
                          The two are complementary, not substitutive.
                          122 allows factoring out type parameter lists
                          for multiple declarations. 135 allows writing
                          them differently.<br>
                          <br>
                        </div>
                        <br>
                      </div>
                      From the meeting itself, because it concerns
                      process:<br>
                      <blockquote style="margin:0px 0px 0px
                        0.8ex;border-left:1px solid
                        rgb(204,204,204);padding-left:1ex"
                        class="gmail_quote">
                        <ul class="">
                          <li>nrc: Do we want to keep this open? It's
                            the <code><></code> to <code>[]</code>
                            changes.</li>
                          <li>acrichto: It's so new, I don't think we
                            should close it.</li>
                          <li>nrc: Even so, if we're not going to do it,
                            I don't think we should keep it open.</li>
                        </ul>
                      </blockquote>
                      I don't see what could have been gained by closing
                      it. Potential scenarios if it's left open:<br>
                      <br>
                    </div>
                     (1) Participants end up convincing each other than
                    the change is not worth doing. (This is what ended
                    up happening in this case.)<br>
                  </div>
                   (2) Contrary to expectations, a consensus emerges in
                  favor of the change. Maybe there is some factor that
                  hadn't been taken into account previously, or the
                  arguments of one side end up convincing the other. I
                  think this might be useful information to have
                  learned. Then you can evaluate the decision on the
                  merits.<br>
                  <br>
                </div>
                Whereas if it's closed early:<br>
                <br>
              </div>
               (3) People are left with the opinions they already had,
              and now might also have the impression that Mozilla has
              heavy-handedly shut down the debate.<br>
              <br>
            </div>
            I mean, possibly leave a comment like "Just so you know, we
            are extremely unlikely to do this, but feel free to keep
            discussing", but I think that was clear to everyone at the
            outset. I just don't see what could have been gained by
            preventing the discussion from playing itself out.<br>
            <br>
          </div>
          Cheers,<br>
        </div>
        Gábor<br>
        <div>
          <div>
            <div>
              <div>
                <div>
                  <div>
                    <div>
                      <div><br>
                      </div>
                    </div>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On Tue, Jul 1, 2014 at 1:23 AM, Nick
          Cameron <span dir="ltr"><<a moz-do-not-send="true"
              href="mailto:lists@ncameron.org" target="_blank">lists@ncameron.org</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div dir="ltr">Hi all, there have recently been some calls
              to be more open about the Rust meetings, in particular to
              publish the agenda beforehand. The agenda setting has been
              quite informal, often not coming together until the
              meeting starts. Not to say that we won't publish an agenda
              in the future, but that it is not as easy as it might
              seem. However, as a step towards that, I will be mailing
              out the part of the agenda that is set in advance which is
              the set of (usually older) RFCs where discussion has
              mostly ceased and where we feel we can make a decision on
              progress. This email is a relatively new convention in any
              case. It has been sent to most meeting attendees at the
              start of the week. From now on, I'll send it to the
              mailing list instead. If you have comments on the RFCs,
              please comment on the RFC PR itself, please do not reply
              to the mailing list. <br>
              <br>
              Some explanation of the process here - each week there are
              two Rust meetings where we discuss RFCs, the general Rust
              meeting and the triage meeting. We only accept RFCs at the
              general meeting. RFCs may be closed at either meeting. In
              order to make sure no older RFCs slip through the cracks,
              RFCs where discussion has come to a stop (or nearly so)
              are recommended each week for discussion. Based on the
              outcome of the discussion on the PR and the current goals
              of the Rust project (in particular in not accepting any
              major backwards compatible changes before 1.0) an RFC will
              be proposed for discussion at the general meeting if it
              needs discussion or we are likely to accept, or to the
              triage meeting if it is likely to closed. To clarify, what
              actually happens to an RFC is decided at the meeting, not
              by which meeting it is discussed at. Often, other RFCs are
              also discussed at the meetings where attendees think there
              is a more urgent need to discuss something. You can see
              the minutes of the meeting discussions at <a
                moz-do-not-send="true"
                href="https://github.com/rust-lang/meeting-minutes"
                target="_blank">https://github.com/rust-lang/meeting-minutes</a>.
              Not all the RFCs proposed in this email get discussed at
              the meetings - either because we run out of time or
              because a key person is not at the meeting.<br>
              <br>
              The 'actions agreed' section keeps track of actions on
              older RFCs agreed at previous meetings, but which have not
              yet been carried out.<br>
              <br>
              If you have any suggestions for how this regular email or
              the process in general could be improved, please let us
              know.<br>
              <br>
              Cheers, Nick<br>
              <br>
              <br>
              Proposed for discussion at Rust meeting<br>
              ---------------------------------------<br>
              <br>
              <a moz-do-not-send="true"
                href="https://github.com/rust-lang/rfcs/pull/16"
                target="_blank">https://github.com/rust-lang/rfcs/pull/16</a>
              - attributes on statements and blocks<br>
                  huon has updated<br>
                  should we accept now?<br>
              <br>
              <a moz-do-not-send="true"
                href="https://github.com/rust-lang/rfcs/pull/17"
                target="_blank">https://github.com/rust-lang/rfcs/pull/17</a>
              - Iterable trait family - erikt<br>
                  No recommendation, just needs a kick to get moving
              again.<br>
              <br>
              <a moz-do-not-send="true"
                href="https://github.com/rust-lang/rfcs/pull/108"
                target="_blank">https://github.com/rust-lang/rfcs/pull/108</a>
              - Convenience syntax for module imports - tommit<br>
                  Allow e.g., `use module::{self, Type};` for `use
              module::Type; use module;`.<br>
                  Generally positive response. Some bike shedding around
              the use of `self` since we call the file <a
                moz-do-not-send="true" href="http://mod.rs"
                target="_blank">mod.rs</a>, and some proposal to allow <a
                moz-do-not-send="true" href="http://self.rs"
                target="_blank">self.rs</a> instead.<br>
                  Recommend we accept (possibly we should bikeshed the
              synax `self`). We could postpone this (it would be
              backwards compatible), but it seems very desirable and
              would be little effort to implement.<br>
              <br>
              <a moz-do-not-send="true"
                href="https://github.com/rust-lang/rfcs/pull/114"
                target="_blank">https://github.com/rust-lang/rfcs/pull/114</a>
              - Unboxed closures - nmatsakis<br>
                  A lot of discussion, pretty much all about the
              details. General sentiment that we want this.<br>
                  Recommend we accept - is this the right RFC to accept,
              I've not really been keeping track - pnkfelix, pcwalton -
              is there something which supersedes this? I think this
              needs a small update to reflect some of the later
              comments.<br>
              <br>
              <a moz-do-not-send="true"
                href="https://github.com/rust-lang/rfcs/pull/117"
                target="_blank">https://github.com/rust-lang/rfcs/pull/117</a>
              - Rename unsafe to trusted - stevelabnik<br>
                  Loads of opinion in the thread (162 comments!). Note
              that Niko has an upcoming RFC with the concept of
              unsafe/trusted traits where the keyword `trusted` makes a
              lot more sense than `unsafe`, so we could save a keyword
              here.<br>
                  Recommend we discuss this.<br>
              <br>
              <a moz-do-not-send="true"
                href="https://github.com/rust-lang/rfcs/pull/118"
                target="_blank">https://github.com/rust-lang/rfcs/pull/118</a>
              - arithmetics and logic operators to take their arguments
              by value not by ref - pcwalton.<br>
                  Pretty negative feedback (though not all). I remember
              being convinced this was the proper way to implement
              arithmetic operators a while back, but I can't remember
              why (something about using tuples in the signature maybe?
              I can't remember). There seems to be some poor interaction
              with BigInt, etc. where implementing for `&BigInt`
              isn't what you want (but I don't see why from the comment,
              pcwalton seems to in his reply though).<br>
                  Lets discuss this.<br>
              <br>
              <br>
              Proposed for discussion at triage<br>
              ---------------------------------<br>
              <br>
              <a moz-do-not-send="true"
                href="https://github.com/rust-lang/rfcs/pull/98"
                target="_blank">https://github.com/rust-lang/rfcs/pull/98</a>
              - Add 'maybe initialised' pointers (pretty much out
              params, aiui) - gereeter<br>
                  A new form of reference, `&uninit`, is added that
              is write-only and points to possibly uninitialized data.<br>
                  Mixed reactions - overall positive, but agreement on
              low priority.<br>
                  Recommend close as postponed - was this agreed last
              week?<br>
              <br>
              <a moz-do-not-send="true"
                href="https://github.com/rust-lang/rfcs/pull/45"
                target="_blank">https://github.com/rust-lang/rfcs/pull/45</a>
              - Avoiding integer overflow - bmyers<br>
                  Proposes range types and other complicated stuff, but
              discusses other options.<br>
                  Lots of discussion on integer overflow in general, no
              agreement. Also discussed to death on the mailing list
              several times, including currently.<br>
                  Recommend close - we might conceivably do something,
              but we won't do this and we won't lose anything by closing
              this RFC (there's also a new RFC with a different proposal
              derived from the most recent mailing list thread).<br>
              <br>
              <a moz-do-not-send="true"
                href="https://github.com/rust-lang/rfcs/pull/119"
                target="_blank">https://github.com/rust-lang/rfcs/pull/119</a>
              - add support to serialize::json for incrementally reading
              multiple JSON objects - XMPPwocky<br>
                  Apparently this is included in RFC 22, which has an
              implementation.<br>
                  Recommend close in deference to RFC 22.<br>
              <br>
              <a moz-do-not-send="true"
                href="https://github.com/rust-lang/rfcs/pull/120"
                target="_blank">https://github.com/rust-lang/rfcs/pull/120</a>
              - Reintroduce 'do' keyword as sugar for nested match
              statements - bvssvni<br>
                  Syntax for flattening match statements by 'chaining'
              arms of a match statement.<br>
                  Feedback is mostly negative. Some positive feelings
              for including the macro rather than first class syntax.
              Others want to wait for HKT and have a function.<br>
                  Recommend close as postponed. We probably want
              something like this, but not pre-1.0.<br>
              <br>
              <a moz-do-not-send="true"
                href="https://github.com/rust-lang/rfcs/pull/122"
                target="_blank">https://github.com/rust-lang/rfcs/pull/122</a>
              - Syntax sugar for prefix-style type parameter lists -
              ben0x539<br>
                  Sugary syntax for putting a group of type parameters
              and their bounds before a group of functions. Motivation
              is our often unwieldly lists of type parameters.<br>
                  Not much feedback, but mostly positive. Generally for
              the motivation, rather than the solution.<br>
                  Recommend close in deference to RFC 135 (where
              clauses) which solve the motivating problem here, along
              with other issues.<br>
              <br>
              <br>
              Actions agreed<br>
              --------------<br>
              <br>
              <a moz-do-not-send="true"
                href="https://github.com/rust-lang/rfcs/pull/22"
                target="_blank">https://github.com/rust-lang/rfcs/pull/22</a>
              - Deserializing to a stream of tagged values - erikt<br>
                  Changes to the deserialisation framework. Allows for
              decoding into an enum. No commentary for or against.<br>
                  erikt to update?<br>
              <br>
              <a moz-do-not-send="true"
                href="https://github.com/rust-lang/rfcs/pull/88"
                target="_blank">https://github.com/rust-lang/rfcs/pull/88</a>
              - Macro syntax to count sequence repetitions - Eridius<br>
                  More discussion - esp, can it be done with a macro<br>
              <br>
              <a moz-do-not-send="true"
                href="https://github.com/rust-lang/rfcs/pull/101"
                target="_blank">https://github.com/rust-lang/rfcs/pull/101</a>
              - More flexible pattern matching for slices - krdln<br>
                  No comments. The RFC is a little bit vague, but seems
              like kind of a win. Backwards incompatible.<br>
                  Close.<br>
              <br>
            </div>
            <br>
            _______________________________________________<br>
            Rust-dev mailing list<br>
            <a moz-do-not-send="true" href="mailto:Rust-dev@mozilla.org">Rust-dev@mozilla.org</a><br>
            <a moz-do-not-send="true"
              href="https://mail.mozilla.org/listinfo/rust-dev"
              target="_blank">https://mail.mozilla.org/listinfo/rust-dev</a><br>
            <br>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Rust-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Rust-dev@mozilla.org">Rust-dev@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/rust-dev">https://mail.mozilla.org/listinfo/rust-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>