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]
<javascript:>> 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]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
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/619f41aa-6348-8365-b6d5-5471f380de64%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
