On 08/06/2016 12:43 PM, Matthieu Napoli wrote:
I like that project (FIG 3.0) a lot, however I'm also concerned that
only 12 people will vote on PSRs. What if there's a PSR being written
that has nothing to do with those 12 people?
For example what if there's an "async" PSR but none of those 12 people
work with async libraries: why would they vote YES? And also
important: why would they be "qualified" enough to vote correctly on
topics they may not work with? -> both technically and in terms of
seeing/understanding the need behind the PSR (hope I'm not offending
anyone in saying that, that's not the goal at all)
Hi Matthieu. No offense taken.
The CC isn't expected to be domain experts in all subjects. That would
be unreasonable, and in practice impossible.
The issue you identify is exactly the issue we have today: Of the 39
member projects we have now, how many of them have any experience with
async? Of the representatives of those projects, how many have written
async code? Very very few, so an async spec in FIG today would be voted
on by 39 people/projects that for the most part don't have any
experience or expertise to offer, most of whom do not have the time or
inclination to become domain experts just to vote on it. That's bad. :-)
When we started talking about async PSRs last year, we said
(collectively) "we should get some more async projects in FIG, so we
know what we're doing." That is, of course, a totally backwards way to
go about it because it doesn't at all help the other projects and their
reps know what they're doing, but it does then give those few async
projects equal vote on, say, middlewares, or caching, areas where they
may not have any expertise to offer either.
The solution to that is the CC/WG split: The Working Group is designed
to be composed of those people -- whether project-affiliated or not,
whether CC members or not -- who do have relevant domain knowledge
and/or "skin in the game" because they are from a project (whether a FIG
member or not) that does have directly relevant experience. It then
gives them more say, because as a WG member they get a vote on the spec
before it's passed up to the Core Committee. In that sense, this model
gives even more authority to those who would be most affected by a given
spec.
To Adam's "taxation without representation" point, it means that those
who may be affected by a given spec would have more representation then
they do today; they do not need to first be a member project, and their
vote is not diluted by all of those projects that, frankly, have nothing
to add.
For example, let's be honest, Drupal has little if anything to add to an
async spec. We might make use of it in the future sometime, but at this
point Drupal the project is of no real value, at least no more than any
other random PHP user in the world. The input of people like Aaron
Piotrowski of Icicle, however, is absolutely crucial, and far more
important than anything I have to add. But that shouldn't require
giving Icicle (which is still a small and experimental project) an equal
say in Middleware design as Michael O'Phinney. Similarly, it may be
valuable to actively include Sara Golemon (from HHVM, which has async
support) even though she's not affiliated with any project at all.
The Core Committee, then, is not intended to deal with the nitpicky
minutua of the spec. It's intended to look at the broader picture,
ensure that specs are consistent with each other to the extent relevant
(eg, PSR-13 favors immutability in order to be compatible with PSR-7)
and don't do anything grossly stupid (let's do everything with
subclasses and public properties!), ensure that Igor Wiedler (of React
PHP) wasn't actively excluded, and so on. That does likely mean that CC
members will be required to become at least passingly familiar with any
topic that warrants a spec. They'll need to know what promises are and
why they are, for instance, even if they've never written a promises
library themselves. Asking 12 people (who volunteered for the job) to
become at least passingly familiar with various topics is much more
reasonable, and achievable, than asking 40-odd people to do so just
because they want to have input in one specific spec that relates to
their project.
So yes, CC members will need to become minimally competent in various
topics, but not experts. That's a much easier task than we have today,
and is complemented by explicitly putting the domain experts in a given
area directly in charge of the technical nitty gritty that they're
trying to solve.
--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].
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/a1f55827-165f-9c5b-5bf3-b8bf9d6d77a0%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
