This is a really nice proposal. I also think that this does not solve anyway the issues of the FIG itself; maybe the best option could be to push for both approaches? Nothing in the FIG 3.0 proposal forbids that!
In fact, I think that the FIG 3.0 modification are good anyway, and that the *-interop groups can still be formed and promoted, even outside of the FIG reach; then, each *-interop can choose to "be embraced" by the FIG, where the work (which is already done) can be formalized as a PSR, with little work and two simple votings. What do you think? Il giorno lunedì 8 agosto 2016 15:57:39 UTC+2, pmjones ha scritto: > > Dear Voting Members, > > There is another way to solve the problems listed in the [FIG 3.0 > summary][1]: formally encourage the creation of a *-interop project as a > prerequisite to a FIG entrance vote. (Look to container-interop and > async-interop as examples.) > > * * * > > Point by point from the FIG 3.0 tl;dr: > > > Everyone has equal say on FIG PSRs, no matter their expertise or their > project’s relevance in the PSR’s problem space > > A *-interop project concentrates on its particular problem, and can invite > (or draw the attention of) those who have relevant expertise. Both > container-interop and async-interop were able to this successfully. > > > There are lots of clever awesome people involved in the FIG who are not > project representatives > > A *-interop project need not be limited to only project representatives. > It can accept (or refuse) anyone it wants. > > > Member projects find it difficult to engage in everything going on in > the FIG > > Interested parties can enagage in as many, or as few, *-interop projects > as they like. > > > There is an ongoing question if the FIG produces PSRs for member > projects or for the wider community; especially when the wider community > pays it so much attention due to its de-facto status as ‘the php standards > body’. > > Each *-interop project can define for itself the audience it addresses. > > * * * > > This has several advantages over the FIG 3.0 approach. > > - fewer rules changes (perhaps only one!) > > - less bureaucracy > > - less centralization > > - reduced hierarchy > > - fewer committees > > - more flexibility > > - greater openness > > Each *-interop gets to operate in the way it likes, according to its own > project members. > > Each *-interop can work through its ideas among a smaller set of > interested participants, perhaps with implementation trials, without having > the pressure of "being a standard" from the outset. > > Once a *-interop project feels it has solved its particular problem, it > can petition for FIG entrance under current FIG bylaws. > > If there is more than one *-interop groups tackling the same problem in > different ways, FIG can pick from the different groups, or ask that they > merge their efforts before entrance. > > FIG can also see how broadly the work of *-interop group has been > accepted, providing real-world information as to the value of the work > before the entrance vote. > > * * * > > Please consider this the opening of the 2-week discussion that occurs > prior to a vote; of course, it may go on longer than that. > > > [1]: https://medium.com/@michaelcullumuk/fig-3-0-91dbfd21c93b#.4fhp3srq0 > > -- > > Paul M. Jones > http://paul-m-jones.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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/b14f9c91-265b-4606-80c0-fdbfcbf37169%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
