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

Sun Jul 3 16:02:16 PDT 2022

+0.   I don’t feel really understand the impact of the style guide change
(how the new style is different than the current style enforced by ESLint),
but I am generally in favor of staying up to date with best practices to
keep the code base current and approachable.

And at least prettier has an emacs plugin.  Although, I wonder how that
interacts with EditorConfig.

On Sun, Jul 3, 2022 at 11:18 Eli Adam <eadam at co.lincoln.or.us> wrote:

> +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/7c783f2c/attachment.htm>