As mentioned in the pull request, I feel a need to make a distinction
between artefacts/deliverables and the process (working groups). Allow me
to brainstorm a bit:
- PHP-FIG recognizes three types of artefacts:
- PSR: requires a controlled change process, where acceptance and
errata are subject to CC approval.
- PER: only requires initial acceptance by CC, can evolve over time
without explicit CC approval.
- auxilary material, including util libraries
- All artefacts are owned by the CC.
- Each artefact should have an Editor or Maintainer appointed by the CC.
- The CC can form (or approve formation of) a WG.
- CC can delegate maintenance of each artefact to a Working Group.
- CC can request a WG to prepare a new artefact. If no suitable WG is
available, a new WG must be formed.
- A WG has at least three members members.
- A WG has one WG Lead (currently the editor for a PSR).
- A WG has a CC Sponsor.
- Editors and Maintainers are automatic WG members of the WG that is
responsible for the artefact.
- The CC can terminate a WG when it the the WG not longer needed.
- When a WG is terminated, artefacts keep their Editor or Maintainer.
Obviously, this is not a complete proposal, but I hope that the direction
is clear.
--
Vincent
On Friday, August 13, 2021 at 7:16:07 PM UTC+2 Michael Cullum wrote:
> With the util libraries, I'd concur with Matthew.
>
> Right now it is kind of undefined I agree but I also am not sure that is
> necessarily an issue to be honest. What is the problem solved by creating
> formal processes around the util libraries?
>
> You call out simplecache-util, I don't think the problem there is a lack
> of formal process for util libraries. It appears to either be that it's
> just not necessary/no demand for anything there or nobody is willing to put
> the time into doing it. I don't think a formal process is the answer there?
>
> Also, most of the util libraries need very little to no maintenance as
> they are designed to be kept simple and uncontroversial. Maintaining a
> group around each of those seems quite heavy and probably would result in
> more time spent on the admin than the actual project itself.
>
> I think conceptually something like what is proposed [PERs] make sense for
> things like coding standards but I would note that it is also very helpful
> to be able to clearly delineate versions and call out that one is meeting a
> standard (PSR-12 or PSR-2). Nobody wants standards to be... too fast moving
> or agile, perhaps a version a year at maximum velocity for example.
>
> So perhaps when establishing a PER there is a defined maximum release
> schedule velocity and a strict scope of what 'evolution' looks like (e.g.
> stuff is only added due to new or mutated PHP functionality, to clarify, or
> to reflect changes in the ecosystem for coding standards, not just add
> whatever you wish whenever you want).
>
> I also think backwards compatibility [in the sense of not changing things
> but only being additive as any standard change is a BC break in the usual
> sense of the word] and simplistic versioning (e.g. PER-CodingStandards V1,
> V2, V3 where they are additive or clarificatory, not mutating) I think
> would be critical to the success of the idea of PERs, over something like
> semantic versioning which automatically implies three levels of versioning
> and the idea of "BC" breaks. I can't see people wanting to be maintaining
> automation tools or projects that are dealing with a standard that is being
> updated too frequently or has complex versions determining which versions
> of the standard are supported (tooling) or which version is implemented
> (projects).
>
> Many thanks,
> Michael
>
> On Fri, 13 Aug 2021, 17:27 Larry Garfield, <la...@garfieldtech.com> wrote:
>
>> On Thu, Aug 12, 2021, at 10:42 AM, Matthew Weier O'Phinney wrote:
>> > My main question is why the Util libraries would move to the PER
>> process.
>> >
>> > Currently, these have been developed to provide features complementary
>> > to a given standard:
>> >
>> > - cache-util and simplecache-util provides boilerplate that will be
>> > used in most implementations, as well as default "in memory"
>> > implementations.
>> > - http-util provides constants used for request methods and response
>> > status codes
>> >
>> > In each case, I'd argue they're less "evolving standards" as they are
>> > libraries tracking common usage or tracking non-FIG standards to
>> > provide commonly used artifacts. In other words, they are _libraries_,
>> > not _recommendations_.
>> >
>> > Otherwise, the rest of this looks fantastic! Thanks for putting this
>> together!
>>
>> Mainly because right now we have no process for util libraries; their
>> ownership and management is entirely undefined (as witnessed by the
>> simpelcache-util library being entirely empty and abandoned for no
>> particular reason). I figure if we establish a process for them it would
>> probably look an awful lot like the PER process, so I tossed them in
>> together.
>>
>> If we wanted to keep them separate, what would that look like?
>>
>> --Larry Garfield
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "PHP Framework Interoperability Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to php-fig+u...@googlegroups.com.
>>
> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/php-fig/0a7fec5a-864d-4b44-b24b-717d9e7e3343%40www.fastmail.com
>> .
>>
>
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to php-fig+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/259e9ba3-f2e7-42d4-a0a3-1a35cc104626n%40googlegroups.com.
