On Sun, Jun 15, 2025 at 10:29 PM 'Andreas Heigl' via PHP Framework Interoperability Group <php-fig@googlegroups.com> wrote:
> Hey all > > Am 13.06.25 um 13:33 schrieb 'Andreas Heigl' via PHP Framework > Interoperability Group: > [snip] > > > > So all in all: > > > > I did not hear anyone saying that it is a bad idea which implies that > > the idea has some merits. > > > > We have 4 people that are willing to form an initial Working Group > > (Juliette, Jaap, Vincent and myself), one of which (Vincent) offered to > > be the CC sponsor. Per the bylaws that right now would not be sufficient > > for a full working group but definitely for a limited Working Group > > > > As the scope will definitely evolve over time and is not expected to be > > actually finished at one point this sounds more like it fits the PER > > process. > > > > The proposal seems to be to define and maintain a set of attributes that > > are relevant for more than one single tool so that different tools can > > use and rely upon a defined set of attributes and users do not need to > > use several similar attributes with the same meaning for different > > tools. The expected outcome is a meta-document listing the attributes, > > possible parameters to them and a usage for each of them. In addition a > > package will be distributed that contains implementations for these > > attributes to support usage in code or auto-complete. > > > > Any additions to this? Any Objections? > > > > Cheers > > > > Andreas > > > So what would be the next steps? > > Is the above information already enough for the editor to call for an > entrance vote? > > ... After reading the bylaws it looks like there is a chicken and egg > situation though... > > > Editors are appointed by the Core Committee > > > Working Groups are created by an Entrance Vote of the Core Committee. > The Entrance Vote includes the appointment of an Editor > > > The Editor (for a Limited Working Group) or Sponsor (for a Full > Working Group) may then call for an Entrance Vote of the Core Committee > to enquire whether the Core Committee is generally interested in > maintaining a PER for the proposed subject, even if they disagree with > the details of the proposal. > > Anyone able to shed some light here would be appreciated... > > Do we (Jaap, Juliette, Vincent, Larry, myself and whoever else is > interested) now just form an informal group to discuss things off-list > or is that something that needs to happen *after* creating a WorkingGroup? > > I mean we can for sure discuss things separately but I'd rather use > "official" means for that so that the process is as transparent to > anyone interested as possible. > > Looking forward to some purely process-related feedback here. > > Cheers > > Andreas > > > -- > ,,, > (o o) > +---------------------------------------------------------ooO-(_)-Ooo-+ > | Andreas Heigl | > | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | > | https://andreas.heigl.org | > +---------------------------------------------------------------------+ > | https://hei.gl/appointmentwithandreas | > +---------------------------------------------------------------------+ > | GPG-Key: https://hei.gl/keyandreasheiglorg | > +---------------------------------------------------------------------+ > > -- > 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 visit > https://groups.google.com/d/msgid/php-fig/0cb8632e-364d-4de0-84a3-10765a24b742%40heigl.org > . > This is an intriguing idea and I definitely see the value in there being a registry, but I struggle to imagine how it'd work in practice if it's successful. How would we: - package this via composer? Would anyone wanting to use a single attribute need to download the entire corpus? What if we are successful and end up with megabytes of attributes? - decide which attributes are valuable and which are not? Wouldn't we need to accept all attributes to avoid bias and prevent blocking people in the wild trying to build new things? - deal with backwards compatibility? Wouldn't it be likely that these attributes need to change over time? - deal with naming collisions? Are we going to namespace things further than `\Per\Attribute`? What if a project changes its name or namespace? - handle deprecations? Are we appointing someone from the originating project to manage the lifecycle or are we expecting the editor to be the arbiter? Given that PHP already has a widely available and trusted registry in Composer, wouldn't it be better for packages to declare their attributes in their composer.json and allow the existing package registry to track them? That way project maintainers could provide a package of just their attributes and Composer can manage creating a searchable list of them a-la https://packagist.org/extensions. I'd like to see some answers to these questions laid out in a draft meta document before we vote on entrance. Best, Korvin -- 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 visit https://groups.google.com/d/msgid/php-fig/CANeXGWXxJcLD7izbmYJdCzm3VKZwzHx8SX-JEGihpHE4bdwOkA%40mail.gmail.com.
