Thanks for more clarifications. What about 12 vs 13 and even number of 
votes issue?

On Monday, August 22, 2016 at 8:11:27 PM UTC+3, Larry Garfield wrote:
>
> 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/c7e30999-d8e8-4f0b-8ce3-47f35ca87063%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
  • [FIG 3.0] Nee... 'Alexander Makarov' via PHP Framework Interoperability Group
    • Re: [FIG... Chris Tankersley
      • Re: ... 'Alexander Makarov' via PHP Framework Interoperability Group
        • ... Alessandro Lai
        • ... Chris Tankersley
    • Re: [FIG... Larry Garfield
      • Re: ... 'Alexander Makarov' via PHP Framework Interoperability Group
      • Re: ... Alessandro Lai
        • ... Chris Tankersley
          • ... Larry Garfield
            • ... 'Alexander Makarov' via PHP Framework Interoperability Group
              • ... Alessandro Lai
                • ... 'Alexander Makarov' via PHP Framework Interoperability Group
                • ... Larry Garfield
                • ... 'Alexander Makarov' via PHP Framework Interoperability Group
                • ... Alessandro Lai
                • ... Michael Cullum

Reply via email to