On 08/21/2016 04:30 PM, 'Alexander Makarov' via PHP Framework
Interoperability Group wrote:
Voting on FIG 3.0 started. I've read diff of the changes (huge one),
TLDR at medium and searched ML but haven't found answers to some
questions. Please help me find the answers. Thanks!
Chris and others have already answered a fair bit here, but I'll throw
in my response as well.
1. What's the reason to limiting core committee to 12 members? To me
it looks wrong that
We've seen in practice that a review-body made up of, essentially,
"anyone who wants to be, is involved in some project, and we don't all
hate" is not working. The majority of project reps are not following
every discussion, are not versed in the details of every spec, and have
neither the time nor inclination to do either. It's both unreasonable
and impractical to expect that of 40-something people, especially when
that's not in the job description right now.
It is, however, reasonable to expect a smaller number of people to do
so, especially when that is explicitly their job description. We wanted
it to be an elected group, not just people who happen to own a popular
GitHub repo (for some definition of popular), which means it has to be a
fixed number of "seats" one way or another. I originally wanted 9, but
Michael convinced me to expand it to 12 to get more input and make it a
little harder for any one person to filibuster the entire process
despite most votes now being 2/3 instead of 50%+1 (to encourage broader
consensus.)
2. Why 12 exactly? What if there's a PSR on a topic any of these 12
members don't care about or don't have expertise about?
CC members aren't expected to be experts in a given area. That's what
the Working Group is for. They're expected to be well-informed
generalists. Eg, an async WG is and should be responsible for writing a
Promises spec, made up mostly of people who have, well, written Promises
before so know what they're doing. :-)
The CC is only expected to know *enough* about Promises to validate that
the spec is reasonable (but not get into bikesheds about a specific
parameter name, for instance); that it's reasonably consistent with
other PSRs (eg, we're tending to favor immutability, it's following our
coding conventions regarding *Interface suffixes or not, etc.); that the
trial implementations exist, are legit, and have flushed out any
expected bugs; etc.
That may require some CC members to bone up on Promises at least a bit,
but not to the point of Chris Pitt-levels of expert. That's much more
reasonable to expect of 12 people who signed up for that job
specifically than 40 who didn't.
The Working Group are the specialists. The Core Committee are the
generalists. They should complement each other rather than be combative
with each other.
3. Have I missed information about how core committee members are
rotated / re-elected?
They're elected for 2 year terms in parallel with the Secretaries.
Basically, the process was already there, I've used that model in other
organizations in the past with success, and it was easier than trying to
come up with some other process that resulted in even more time spent on
governance. A 2 year staggered term means an election every 8 months,
which is about as frequent as I think we can deal with if we want to
spend time primarily on specs rather than governance matters. (I think
we all agree with that goal.)
See:
https://github.com/php-fig/fig-standards/pull/752/files#diff-7aeee0a55f5e81ea8a0b5f9dc76c6822R1
--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 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/d2b5a9c4-7c2b-c83e-8a9a-138a1d84655d%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
