<div dir="auto">Would folks be willing to vote simply on an update to the style guide? I’m fine with retracting the RFC. </div><div dir="auto"><br></div><div dir="auto">I was modeling the MapServer PSC behavior (and had a different read of RFC 4) but am not in any conviction over whether that is necessary. </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 1, 2022 at 17:33 Eli Adam <<a href="mailto:eadam@co.lincoln.or.us">eadam@co.lincoln.or.us</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Just to return us partly to the topic, we're discussing "Adopt new linting and code formatting rules."<input name="virtru-metadata" type="hidden" value="{"email-policy":{"disableCopyPaste":false,"disablePrint":false,"disableForwarding":false,"enableNoauth":false,"expandedWatermarking":false,"expires":false,"sms":false,"expirationNum":1,"expirationUnit":"days","isManaged":false,"persistentProtection":false},"attachments":{},"compose-id":"106","compose-window":{"secure":false}}"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 1, 2022 at 8:31 AM Jim Klassen <<a href="mailto:klassen.js@gmail.com" target="_blank">klassen.js@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    On 6/30/22 13:00, Eli Adam wrote:<br>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div><br>
          </div>
        <br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Thu, Jun 30, 2022 at 8:35
            AM Dan Little <<a href="mailto:theduckylittle@gmail.com" target="_blank">theduckylittle@gmail.com</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <div dir="auto">RFC-4 is why I thought we may need an RFC
              for this. Since it would supersede what is in the previous
              RFC. Maybe RFC-4’s codification if the standard was
              misguided but we’re stuck with it now. </div>
          </blockquote>
          <div><br>
          </div>
          <div>After rereading RFC-4, I don't think that we codified any
            standards in the RFC and were wise enough to make reference
            to standards (which have already changed once before see
            /developer/standards vs /docs/style_guide).  Updating the
            style guide and a simple PSC vote by email or IRC at the
            next meeting make sense to me but I'd like to hear from
            others too.  </div>
          <div><br>
          </div>
          <div> </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">We could also revise
            RFC-9 to accept whatever we put
            <div dir="auto">into the style guide and the style guide is
              changed by simple vote. </div>
          </blockquote>
          <div><br>
          </div>
          <div>If we did paint ourselves into the corner with RFC-4, I
            think this is a better path out.  I see it as already
            falling into the realm of routine project functions.  </div>
          <div><br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    I'm also not seeing how RFC-4 precludes updating the style guide
    without an RFC.<br>
    <br>
    Although, I also don't see that this discussion is inappropriate for
    an RFC.  This is a request for comments on a proposal that impacts
    the project.  Members can comment, propose amendments, and vote to
    express agreement or disagreement and a RFC seems like the
    appropriate way to document that process.  I know we've been
    treating RFCs somewhat equivalent to making a constitutional
    amendment, but I really don't think a RFC needs to carry that much
    weight to be useful/valid.<br></div></blockquote><div><br></div><div><div>Good point.  My inclination against an RFC is to avoid cluttering them up and to also encourage the routine functioning of the project via other accepted routine processes (non-RFC PSC votes for 'small' and 'medium' decisions).</div><div><br></div><div>I hope that we can have the same discussion and interaction for any topics and decisions of the PSC (even without an RFC).  </div></div><div><br></div><div>I  hope to hear some additional input too (pertaining to either the original content of the RFC or whether it should be an RFC or not).  </div><div><br></div><div>Best regards, Eli</div><div> </div><div>p.s. yes, my various quoting styles in this email were an attempt to get further discussion on the topic.  </div></div></div><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    <br>
    For example, look at the recent MapServer RFCs:<br>
    <blockquote>
    </blockquote>
    <div>
      <ul><li><a href="https://mapserver.org/development/rfc/ms-rfc-133.html" target="_blank">MS
          RFC 133: Mapfile Syntax Cleanup</a></li>
      <li><a href="https://mapserver.org/development/rfc/ms-rfc-134.html" target="_blank">MS
          RFC 134: OGC API Support</a></li>
      <li><a href="https://mapserver.org/development/rfc/ms-rfc-135.html" target="_blank">MS
          RFC 135: MapServer 8.0 Config file</a></li>
      <li><a href="https://mapserver.org/development/rfc/ms-rfc-136.html" target="_blank">MS
          RFC 136: Rename shp2img to map2img</a></li>
      <li><a href="https://mapserver.org/development/rfc/ms-rfc-137.html" target="_blank">MS
          RFC 137: Native FlatGeobuf support</a></li></ul>
    </div>
    <p>A couple have fairly broad impact, but most of them are fairly
      trivial in nature, down to renaming a single file.  I think RFCs
      are better used for documenting the decision making process rather
      than setting something in stone.  Which is to say, I don't think
      we need to be afraid of RFCs (as long as we have a functional PSC
      anyway).  RFCs are cheap, it's just a file and a vote.<br>
    </p>
    <p>And just because I've recently had discussions about implementing
      <span>Architectural Decision Records for internal projects and
        realizing they basically serve the same function as RFCs:<br>
      </span></p>
    <p><a href="https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions" target="_blank">https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions</a><br>
    </p>
  </div>

_______________________________________________<br>
geomoose-psc mailing list<br>
<a href="mailto:geomoose-psc@lists.osgeo.org" target="_blank">geomoose-psc@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/geomoose-psc" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/geomoose-psc</a><br>
</blockquote></div></div>
_______________________________________________<br>
geomoose-psc mailing list<br>
<a href="mailto:geomoose-psc@lists.osgeo.org" target="_blank">geomoose-psc@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/geomoose-psc" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/geomoose-psc</a><br>
</blockquote></div></div>