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

Eli Adam eadam at co.lincoln.or.us
Sun Jul 3 09:18:17 PDT 2022


+1 to changing the style guide

+0 to RFC method for minor change like this

Would like to hear from others too.

Best regards, Eli

On Sun, Jul 3, 2022 at 9:01 AM Dan Little <theduckylittle at gmail.com> wrote:

> 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/75198fea/attachment-0001.htm>


More information about the geomoose-psc mailing list