Thank you for that LOOOOOOONG explanation Larry, it did carry value once I had time to read it. While the -interop approach you wrote about was not something I was concerned with, the other portions were useful. Thanks for the time spent.
In regards to: > That does of course presume that a project rep is bothering to read the > list and keep abreast of what's going on. If someone doesn't even have the > capacity to do that much, then the project needs to pick a new rep. > Waiting until a spec is done and polished and just waiting on a final vote > to make sure projects know what is going on is completely and utterly > backward. I would caution that we are all busy, and switching a rep because FIG is not our life with every breath may be extreme. In your description, and others' posts, I'm hearing, "Members who can't keep up should go away." To those who are able to keep up 100% I commend you, but I feel that would be nobody. We all strive to fit FIG into our day-to-day the best we can, because we want to contribute. Therefore I still have my initial concern where things could progress without everybody knowing. However, I'm not sure how we tackle that. I proposed a member project vote because it was the easiest to implement and carry out. While I'm still not sold that FIG 3.0 is ready without including a member vote as stated, I'm convinced there will never be a "one size fits all" solution...and maybe that's OK. I do feel that overall it is a step in the right direction. Regards, Adam Culp On Wednesday, August 10, 2016 at 5:29:45 PM UTC-4, Larry Garfield wrote: > > Hi Adam. There seems to be two different threads in your comment, so I am > going to try and separate them. > > One is ensuring influence of projects on a spec. The other is ensuring > awareness by projects of a spec. > > The second one is much easier: That's why specs are discussed on list (or > equivalent if we ever were to move to a forum or similar), and why an > Entrance Vote (to form a WG) should happen earlier, rather than later. A > project rep's job is to at least monitor the list so that they're aware of > what's going on. If they see there's a discussion about a spec that would > be relevant to their project, they can decide what if anything their > project wants to do about it (which could well include ignoring it, which > is totally fine). > > That's actually one reason why having WGs form early, rather than some > informal -interop group elsewhere that only comes to FIG at the end, is a > good thing. It provides *visibility* into the conversation if it is here, > where we have an explicit gathering of projects that may have a stake in > the outcomes. In other words, the awareness point you raise is precisely > why formal working groups is better than "please do something elsewhere > before talking to us". > > That does of course presume that a project rep is bothering to read the > list and keep abreast of what's going on. If someone doesn't even have the > capacity to do that much, then the project needs to pick a new rep. > Waiting until a spec is done and polished and just waiting on a final vote > to make sure projects know what is going on is completely and utterly > backward. > > The other point is ensuring (appropriate) influence on a spec (for some > definition of appropriate). In this case, the formation of a Working Group > is the initial trigger of "hey, this is happening, if you want to get > involved this is the time". Projects can then, if they choose, get > involved either as members of the Working Group or as just people > commenting. > > Just as now, there is absolutely no requirement that someone be part of a > Working Group to contribute. Everyone is welcome to participate in the > discussion of a spec today, even if they're not the Editor, Sponsor, or > Coordinator. That wouldn't change. The WG members are those actively > building the spec, probably making trial implementations, etc. But that > doesn't mean others are excluded, and their time spent reviewing and > commenting is absolutely valid. > > And, importantly, projects can say "we want to be actively involved here, > not just passively involved", and they are by-default accepted as part of > the WG; and not just the project rep. If, say, Drupal wanted an "active > seat" on a rebooted PSR-5 (documentation), I would not take that myself. I > would invite our documentation lead, Jen Hodgdon, to do so, and she would > then have a vote as part of the WG provided she remained actively involved. > > Certainly it's possible for the WG to blow off someone who is not on the > group explicitly. Humans are humans. That's one of the reasons the CC is > there. The CC is in a position to call it out if a WG conspicuously > ignored input from some circle, and reject a spec if that's the case. > > Let me use PSR-15 (HTTP Middlewares) as an example. There are a minority > of current member projects that use PSR-7; there are a minority of current > projects that use a middleware design of some variety or another; there are > many current projects that do HTTP handling of some variety; There's a lot > of overlap in those groups, and the union of them is probably a majority of > projects but far short of "everyone". (Off hand I count ~11, or about one > quarter, that I'm fairly certain don't touch HTTP anywhere.) > > Today, the official WG is just 3 people (Woody Gilk, Paul Jones, Jason > Coward), and, strictly speaking, they could bring a draft all the way to a > final vote without ever talking to anyone else but the 3 of them. (Not > that I expect them to do so, but it is on paper possible.) > > In the current (FIG 2) model: > * Every project knows that middlewares are being worked on. > * Only two of those people (Editor and Coordinator) technically need to > agree on anything, until it's brought to a vote. > * Any individual that wants to can give input, if they know where to do > so, but the Editor/Coordinator are under no obligation to listen. > * When the final vote happens, if, for instance, Matthew feels that Zend > Framework's needs were totally ignored then he has no recourse other than > to yell a lot and try to convince people to vote -1 because of that. He's > unlikely to be successful, as that's one vote among ~40 and weighted > equally with those 11 projects that have nothing to do with HTTP, so don't > really care. It's also a 50% vote, which is not a high bar. > > With the FIG 3 model: > * Every project would know that middlewares are being worked on. > * Any individual that wants to can give input. > * Any project that wants to be actively involved in its development can > get a seat on the WG if they're willing to be actively engaged. > * If Matthew feels ZF has a major role to play in the spec, he or a > designate can be part of the WG. That gives that rep, worst case scenario, > one vote among 5-12, I'd estimate. It's also a 2/3 vote, so it's easier > for a WG member who feels the spec is totally off the rails to force the > issue. > * The CC can also push back if a spec passes a Readiness Vote but clearly > ignored Zend Framework's input. They're also a 2/3 vote, so again, higher > bar needed to verify that the spec took all relevant input into > consideration. > > That is, under FIG 3 projects have more direct influence, and more checks > to avoid being ignored or railroaded, than under FIG 2... *if* they wish to > exercise it. Projects that aren't relevant, or don't want to bother, don't > dilute the influence of those that are and do. > > > I should note that this model also resolves the "people vs projects" > question. Under FIG 2 currently, we are all projects, unquestionably, not > people. At least on paper. As some keep pointing out, however, that's not > entirely true in practice; many to most of us act as people, not projects, > much to all of the time. FIG 3 accepts and acknowledges this, and shifts > the emphasis from projects to relevant-domain-experts, which often comes > from project involvement. In that sense it's much more honest. > > For instance, Jackalope as a project likely has quite little to add to > HTTP Middlewares. Lukas Smith may. As may someone else not affiliated > with any project, but who nonetheless has more value to add to the spec > than say, Phing does as a project. > > It's not perfect or bulletproof, certainly. But it is closer to it, and > harder to railroad a spec through, than the current setup. Note that I am > making an implicit assumption here: > > Most adult professionals will act like responsible adult professionals > most of the time, given a structure that encourages doing so. The > challenge is ensuring the right structure and organization in which to do > so. > > If we cannot make that assumption, then FIG is totally doomed as is our > industry and we should just all go become farmers. :-) > > Adam, I hope that addresses your concerns. > > (Note: The examples above are for demonstration purposes only and should > not be interpreted as casting aspersions on any of those mentioned or > implied as examples. ) > > --Larry Garfield > > On 08/07/2016 08:06 PM, Adam Culp wrote: > > Thanks Larry, but as stated I will be taking the the Secretary topic to a > new thread. It should not be here. > > As for your post answering my concerns, it did not. Your post assumes that > a given PSR would only affect a limited number of member projects, and > therefore they would all likely be a part of the process. While this > scenario may apply to some of the current PSR's on the deck now, it will > likely not always be the case. > > Again, I was not saying that a member vote would carry HUGE amounts of > weight on a given PSR vote. I would envision that a member vote would help > alert member projects about the completion of PSRs that may affect them, > and allow them to have some limited input prior to it going final. Isn't > that a portion of why we are all members of the group to begin with? > > Otherwise we could easily enter a situation where member projects would > not be aware of something they should be concerned about until it is too > late. However, as a member of the interoperability group it would be > somewhat expected for them to comply by the outside community. > > Regards, > Adam Culp, IBMiToolkit > > > On Sunday, August 7, 2016 at 6:58:16 PM UTC-4, Larry Garfield wrote: >> >> On Aug 7, 2016 5:28 PM, Christopher Pitt <[email protected]> wrote: >> >> >> >> secretaries taking an active role in a discussion threads, versus >> aiding members in understanding content >> > >> > >> > I don't understand the difference. Unless by "aiding members in >> understanding" you mean not speaking. Then I understand the difference. :) >> >> Michael has stated a few times that on FIG 3, he's speaking as the >> co-author, not Secretary, just as I'm speaking as co-author, not Drupal >> rep. Taking an advocacy position is therefore entirely appropriate and to >> be expected. >> >> Adam, did my earlier message address your concerns? >> >> --Larry Garfield >> > -- > 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] <javascript:>. > To post to this group, send email to [email protected] <javascript:> > . > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/58a05207-101f-4da0-9055-2b7cccc392a0%40googlegroups.com > > <https://groups.google.com/d/msgid/php-fig/58a05207-101f-4da0-9055-2b7cccc392a0%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/dc36e9b6-b1e8-4a4e-9ec9-ecd1bd6e64e4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
