Hi all, It's worth noting here an issue we just came across with container-interop, essentially the problem exists in the licensing in that we essentially need specs to be licensed to the FIG from the beginning otherwise we hit issues with copyright reassignment (we [secretaries] are currently working with the PSR-11 team behind the scenes to get this resolved).
https://github.com/php-fig/container/pull/4 -- Michael C On 10 August 2016 at 04:31, Nate Abele <[email protected]> wrote: > On Monday, August 8, 2016 at 9:57:39 AM UTC-4, pmjones wrote: >> >> 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 > > > > In broad brushstrokes, I see how this could be understood to be > superficially similar to the other FIG re-org proposal, but it's actually a > major (and important, I think) philosophical departure: the final > deliverable is an actual piece of software, rather than a spec for an > actual piece of software. This moves FIG's organizational process to what I > believe is the Platonic ideal for an organization of its type: one where a > +1 vote is more like an 'intent to implement'. > > This has a number of knock-on effects, including: > - Interop group participants are more sensitive toward and naturally > incentivized to develop around what existing projects are doing, and > - ...are more likely to solicit meaningful, practical feedback and buy-in > from the intended audience > > Using code as the fundamental unit of organization also encourages > something which often seems to be an afterthought: the opportunity to > iterate on real, working examples. > > In sum, I think this approach will help keep people focused on what > matters, and the openness of the process allows FIG to capitalize on the > efficiencies that make OS itself work so well. > > Thank you all for indulging my musing. I yield the balance of my time. :-) > > -- > 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/eae2fc8b-30ed-44ae-b8a4-9226d15d501c%40googlegroups.com > <https://groups.google.com/d/msgid/php-fig/eae2fc8b-30ed-44ae-b8a4-9226d15d501c%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CAAqcDMiw1fHs2fzCEgKtk6U6UiwrYOVCbunzEdO_jj0WtWOWPA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
