I completely agree with Paul here, this is, for me, at least worth investigating. It takes the onus off the FIG organising the minutiae of HOW standards get created but puts the focus on the group to ratify things that are ready to be added as a standard. Container Interop is a great example here, it was self-formed and has got wide adoption and is ready to be ratified as a PSR in my opinion. I'm not convinced that this group needs to worry about who is involved in creating a standard, or how the proposals get to the point where they can be considered a PSR - it's been proven that self-formed small groups can get that job done.
I appreciate that the role of this group could not be completely "hands off" - for example, if no standard exists for $x, and the group feels that a standard is needed in this area, then it will need to address the problem and encourage a team to tackle this problem. I know people will say "that's exactly what working groups are going to be!" and I can see that, but in all reality, it's not. Working Groups (from my understanding) will be regulated and will need at least $y number of people of which $z are from the group. I would prefer to see the FIG simply maintain a list of things they think need addressing, and encourage teams to look at the problems. I believe that moving the focus of the FIG from a problem-solving body to a ratification body will make life easier for everyone, and will solve some of the problems being addressed in the FIG 3.0 proposal. Gary On Monday, 8 August 2016 15:57:39 UTC+2, 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 > > > > -- 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/4f96130f-7f16-4981-978e-d7d30fbb7bd4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
