[geomoose-psc] RFC-9: Adopt new linting and code formatting rules

[Dan Little]

Would folks be willing to vote simply on an update to the style guide? I’m
fine with retracting the RFC.

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.

On Fri, Jul 1, 2022 at 17:33 Eli Adam <eadam at co.lincoln.or.us> wrote:

> Just to return us partly to the topic, we're discussing "Adopt new linting
> and code formatting rules."
>
> On Fri, Jul 1, 2022 at 8:31 AM Jim Klassen <klassen.js at gmail.com> wrote:
>
>> On 6/30/22 13:00, Eli Adam wrote:
>>
>>
>>
>> On Thu, Jun 30, 2022 at 8:35 AM Dan Little <theduckylittle at gmail.com>
>> wrote:
>>
>>> 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.
>>>
>>
>> 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.
>>
>>
>>
>>> We could also revise RFC-9 to accept whatever we put
>>> into the style guide and the style guide is changed by simple vote.
>>>
>>
>> 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.
>>
>>
>> I'm also not seeing how RFC-4 precludes updating the style guide without
>> an RFC.
>>
>> 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.
>>
>
> 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).
>
> I hope that we can have the same discussion and interaction for any topics
> and decisions of the PSC (even without an RFC).
>
> 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).
>
> Best regards, Eli
>
> p.s. yes, my various quoting styles in this email were an attempt to get
> further discussion on the topic.
>
>
>> For example, look at the recent MapServer RFCs:
>>
>>
>>    - MS RFC 133: Mapfile Syntax Cleanup
>>    <https://mapserver.org/development/rfc/ms-rfc-133.html>
>>    - MS RFC 134: OGC API Support
>>    <https://mapserver.org/development/rfc/ms-rfc-134.html>
>>    - MS RFC 135: MapServer 8.0 Config file
>>    <https://mapserver.org/development/rfc/ms-rfc-135.html>
>>    - MS RFC 136: Rename shp2img to map2img
>>    <https://mapserver.org/development/rfc/ms-rfc-136.html>
>>    - MS RFC 137: Native FlatGeobuf support
>>    <https://mapserver.org/development/rfc/ms-rfc-137.html>
>>
>> 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.
>>
>> And just because I've recently had discussions about implementing Architectural
>> Decision Records for internal projects and realizing they basically serve
>> the same function as RFCs:
>>
>> https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
>> _______________________________________________
>> geomoose-psc mailing list
>> geomoose-psc at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/geomoose-psc
>>
> _______________________________________________
> geomoose-psc mailing list
> geomoose-psc at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geomoose-psc/attachments/20220703/d251c535/attachment.htm>