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

[Eli Adam]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geomoose-psc/attachments/20220701/42756881/attachment.htm>