Hey Gary! As Larry suggests, the two approaches are very similar and not mutually exclusive. Taking container interop as an example again, it could easily be a random project by interested parties that is then turned into a working group, as a working group is what would be needed to really beat it into shape over the last mile.
If the purpose of FIG 3.0 is to turn into a proper standards body - and not just a ratification of stuff more than half of the member projects are currently doing (or like the sound of) - then a working group is important. Extra eyes, extra time, extra steps, etc are all required to make it hit that level. If we want to carry on exactly as the FIG has done, then letting people make standard implementations and build a bunch of code off it, then get frustrated if anyone wants change and just let it languish for years or slap a rubber stamp on it because close enough... then continue with the interop approach. I don't think the FIG 3.0 suggestions as they stand make them a problem solving body, I think they're just saying "Come and have the conversation with us" instead of "Ah do what you like, come back when you're done and hopefully it'll be something we want to ratify without totally recoding it." I'd hate to see that happen. Glenn: You seem a bit disgruntled here, maybe I could add some context as an observer of the FIG 3.0 conversations. The "political wall" you refer to is "Should this person be in here." You'll often see a large group of inexperienced junior devs wanted to standardize something (we've seen about ten standards groups pop up and burn away to nothing in the space of months), mostly due to those folks being inexperienced. If you just let literally anyone get involved then you have a noisy mess that creates either nothing, or creates junk. "I find it quite offensive that FIG thinks it has the power to modify community lead interop projects." Where does it say this? What do you think the FIG is suggesting? If people want to make a GitHub repo with -interop in the title then they're perfectly welcome to do so, the FIG is not trying to stop that from happening and how the heck would it even do that? :D Don't forget, a foo-interop project could be a working group later, nothing would suggest otherwise. *"A PSR should be a formalization of something the community already has."* Yeah mostly. Take a look at the HTTP Middleware examples, the community had implemented multiple approaches. Seeing as the community had multiple existing solutions, which would it standardize? The most popular? By which metric? Regardless of which of the many approaches should be standardized, many of the most popular implementations were using approaches that were full of holes. Should we rubber stamp this busted approach, or should we use the standardization process to improve the situation, and bring the PHP community up to scratch in the process? I entirely agree that PSRs should have implementations built to test the theory, and they *could *be interop projects, or they could be Working Groups. They're not mutually exclusive, but I'd rather have a formal Working Group than just telling people to go away and come back with something to be ratified. The goal is to make the FIG a formal standards body, instead of just a pile of cowboys knocking out standards based on whatever implementation happens to be around like PSR-3 == monolog. :) On Tuesday, August 9, 2016 at 5:44:08 AM UTC-4, GeeH wrote: > > 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 php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/bcfdf27b-4924-462c-96b1-bd37d3a262d9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
