[FIG 3.0] Need clarifications about core committee
389 views
Skip to first unread message
Alexander Makarov
Aug 21, 2016, 5:30:50 PM8/21/16
to PHP Framework Interoperability Group
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!
1. What's the reason to limiting core committee to 12 members? To me it looks wrong that
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?
3. Have I missed information about how core committee members are rotated / re-elected?
Chris Tankersley
Aug 21, 2016, 6:12:42 PM8/21/16
to php...@googlegroups.com
On Sunday, August 21, 2016, 'Alexander Makarov' via PHP Framework Interoperability Group <php...@googlegroups.com> 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!1. What's the reason to limiting core committee to 12 members? To me it looks wrong that
If I remember correctly, the idea was to have a smaller, dedicated core group to encourage the members to be more active. All of the work regarding each PSR will be handled by the individual working groups though, which may contain core members but ideally are made up of many different member projects.
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?
That's what the working groups are for. The Working Group should be made up of people interested and knowledgeable about the topic. When the PSR is all finished (wording and two implementations) and ready to be finalized, it's passed onto the core committee for a final vote.
3. Have I missed information about how core committee members are rotated / re-elected?
That info was in the PR for the change. I'm on mobile otherwise I would link to it.
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/8629479a-0c05-468d-9705-a1003d1bc368%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Alexander Makarov
Aug 21, 2016, 7:03:01 PM8/21/16
to PHP Framework Interoperability Group
Chris Tankersley, thanks for info. I've somehow missed renewal terms. Members are elected for 2 years. That's probably a bit lengthy period.
Do you know why the number of core committee members is exactly 12?
I understood that after work is done, proposal is passed to core committee for final vote. I still wonder what happens if current core committee members do not have expertise about the topic to vote... they can ensure quality of the text itself and its clarity but can't ensure that the proposal itself is a good one. Probably not a big issue since proposal already passed multiple stages.
// Just realized I haven't finished 2nd sentence :) Please ignore "To me it looks wrong that".
Alessandro Lai
Aug 22, 2016, 3:53:26 AM8/22/16
to PHP Framework Interoperability Group
Yeah, the point is exactely that. The core committee doesn't need to be experts on the field, they can relay that to the WG. They can (and must) however reject a PSR if they think that the WG ignored or didn't listen to experts or big players in the context of the PSR.
Chris Tankersley
Aug 22, 2016, 11:39:49 AM8/22/16
to php...@googlegroups.com
Alessandro echoed most of what I'm going to say, but here's my answers:
On Sun, Aug 21, 2016 at 7:03 PM, 'Alexander Makarov' via PHP Framework Interoperability Group <php...@googlegroups.com> wrote:
Chris Tankersley, thanks for info. I've somehow missed renewal terms. Members are elected for 2 years. That's probably a bit lengthy period.Do you know why the number of core committee members is exactly 12?
Not sure. There should probably be an odd number of members through, to avoid equal voting counts. I thought it was because that was the number on the ISOC board, but that seems to be 13. Someone correct me if I'm wrong.
I understood that after work is done, proposal is passed to core committee for final vote. I still wonder what happens if current core committee members do not have expertise about the topic to vote... they can ensure quality of the text itself and its clarity but can't ensure that the proposal itself is a good one. Probably not a big issue since proposal already passed multiple stages.// Just realized I haven't finished 2nd sentence :) Please ignore "To me it looks wrong that".
The Core Committee is not meant to be knowledge experts on everything. They are there to make sure that the implementations look correct and match the PSR, with the idea that the Working Group itself did due diligence. The Working Group itself should have come up with the draft wording, finalized it, and actually implemented it before it ever gets to the final PSR vote.
It sounds like throwing someone under the bus, but if a bad PSR is created, it's kind of the working group's fault if a bad PSR is created.
--
On Monday, August 22, 2016 at 1:12:42 AM UTC+3, Chris Tankersley wrote:
On Sunday, August 21, 2016, 'Alexander Makarov' via PHP Framework Interoperability Group <php...@googlegroups.com> 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!1. What's the reason to limiting core committee to 12 members? To me it looks wrong thatIf I remember correctly, the idea was to have a smaller, dedicated core group to encourage the members to be more active. All of the work regarding each PSR will be handled by the individual working groups though, which may contain core members but ideally are made up of many different member projects.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?That's what the working groups are for. The Working Group should be made up of people interested and knowledgeable about the topic. When the PSR is all finished (wording and two implementations) and ready to be finalized, it's passed onto the core committee for a final vote.3. Have I missed information about how core committee members are rotated / re-elected?That info was in the PR for the change. I'm on mobile otherwise I would link to it.--
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+unsubscribe@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/8629479a-0c05-468d-9705-a1003d1bc368%40googlegroups.com.
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 php-fig+unsubscribe@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/945b4095-6142-4b38-b4ae-35d7b03bbf25%40googlegroups.com.
Larry Garfield
Aug 22, 2016, 1:11:27 PM8/22/16
to php...@googlegroups.com
On 08/21/2016 04:30 PM, 'Alexander Makarov' via PHP Framework
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
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
> 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!
in my response as well.
> 1. What's the reason to limiting core committee to 12 members? To me
> it looks wrong that
"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?
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?
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
Alexander Makarov
Aug 22, 2016, 2:29:39 PM8/22/16
to PHP Framework Interoperability Group
Thanks for more clarifications. What about 12 vs 13 and even number of votes issue?
Alessandro Lai
Aug 22, 2016, 2:30:48 PM8/22/16
to PHP Framework Interoperability Group
So Larry, this also addresses the issue of the (12) even number of the core committee? Since votes requires always 2/3, no tie is possible?
Chris Tankersley
Aug 22, 2016, 2:38:02 PM8/22/16
to php...@googlegroups.com
On Mon, Aug 22, 2016 at 2:30 PM, Alessandro Lai <alessand...@gmail.com> wrote:
So Larry, this also addresses the issue of the (12) even number of the core committee? Since votes requires always 2/3, no tie is possible?
That was my bad, yes. 2/3 would mean an even number of members would be fine. I'd forgotten that bit, and just remember the 50% number from what we needed for Quorum. It's laid out in the PR:
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/f386c41a-5b86-4da8-a575-9099c57346de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Larry Garfield
Aug 22, 2016, 3:56:50 PM8/22/16
to php...@googlegroups.com
On 08/22/2016 01:37 PM, Chris
Tankersley wrote:
On Mon, Aug 22, 2016 at 2:30 PM, Alessandro Lai <alessand...@gmail.com> wrote:
So Larry, this also addresses the issue of the (12) even number of the core committee? Since votes requires always 2/3, no tie is possible?
That was my bad, yes. 2/3 would mean an even number of members would be fine. I'd forgotten that bit, and just remember the 50% number from what we needed for Quorum. It's laid out in the PR:
Just replying to confirm the above, yes. With most CC votes being
2/3 (that is, 8/12 assuming everyone votes, which should be likely),
the "tie breaker" value of an odd number of people isn't relevant.
A multiple of 3 keeps each election an equal size (modulo unexpected
vacancies).
--Larry Garfield
--Larry Garfield
Alexander Makarov
Aug 23, 2016, 7:58:07 AM8/23/16
to PHP Framework Interoperability Group
Great. Then it makes sense to me. The diff is quite big and info is a bit scattered there. I guess that's why there are negative votes on topic.
Alessandro Lai
Aug 23, 2016, 6:07:40 PM8/23/16
to PHP Framework Interoperability Group
Well, the vote has now been canceled. I've just now finished reading again the full diff, and I've found clarifications about possible tie votes: majority must be +1 with 50%: https://github.com/php-fig/fig-standards/pull/752/files#diff-a7e6254aa839471064951898e0ebb021R17
So basically no tie is possible.
Are there any other doubts to be settled?
Alexander Makarov
Aug 24, 2016, 6:27:05 AM8/24/16
to PHP Framework Interoperability Group
Well, clarity of the document. It takes time to find what you need so maybe wording or structure could be improved for better comprehension, cross-linking introduced etc.
Larry Garfield
Aug 24, 2016, 9:51:27 AM8/24/16
to php...@googlegroups.com
Can you note anything in particular
that is clumsy to read? We were aiming for explicitness and lack
of vagueness, which in prose does tend to lead to verbosity. To
me it still reads fairly well, but as the author I am of course
biased on that front. :-)
--Larry Garfield
--Larry Garfield
Alexander Makarov
Aug 24, 2016, 10:08:01 AM8/24/16
to PHP Framework Interoperability Group
I'll try to re-read it and make a pull request with changes or at least a list of suggestions.
Alessandro Lai
Aug 24, 2016, 10:26:45 AM8/24/16
to PHP Framework Interoperability Group
Larry, it think that the part about vote rounding is not clear enough; it's understandable through the examples, but the rule is somewhat "implicit" in there.
Michael Cullum
Aug 24, 2016, 8:13:38 PM8/24/16
to FIG, PHP
Hi Alessandro,
Larry asked me to just jump in and clarify this (the legalese part of the spec was mostly from me and this also relates to existing bylaws).
It's based on the current wording (and rounding rules) in the current Voting Protocol where no tie is possible, the burden of proof, so to speak, lies with the person calling for a motion to pass and rounding is clarified through examples. This appears to be the easiest way to do it to be honest without lots of verbosity which has the ability to hinder understanding than improve it. If you have any alternative suggestions for wording they would be most welcome although I suspect a similar discussion occurred when the original Voting Protocol was written (PMJ: Perhaps you could confirm this?).
I would draw note to the current voting protocol, in particular points 5 and 6: https://github.com/php-fig/fig-standards/blob/master/bylaws/001-voting-protocol.md
--
Michael Cullum
FIG Secretary
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/1878ff62-fb7a-458d-b83a-5cfdb9a7733b%40googlegroups.com.
Alessandro Lai
Aug 25, 2016, 7:03:56 AM8/25/16
to PHP Framework Interoperability Group
Understood, thanks for the clarification. Seeing the "old" bylaw, I suspect the same.
Il giorno giovedì 25 agosto 2016 02:13:38 UTC+2, Michael Cullum ha scritto:
Hi Alessandro,
Larry asked me to just jump in and clarify this (the legalese part of the spec was mostly from me and this also relates to existing bylaws).It's based on the current wording (and rounding rules) in the current Voting Protocol where no tie is possible, the burden of proof, so to speak, lies with the person calling for a motion to pass and rounding is clarified through examples. This appears to be the easiest way to do it to be honest without lots of verbosity which has the ability to hinder understanding than improve it. If you have any alternative suggestions for wording they would be most welcome although I suspect a similar discussion occurred when the original Voting Protocol was written (PMJ: Perhaps you could confirm this?).I would draw note to the current voting protocol, in particular points 5 and 6: https://github.com/php-fig/fig-standards/blob/master/bylaws/001-voting-protocol.md
--Michael CullumFIG Secretary
On 24 August 2016 at 22:26, Alessandro Lai <alessand...@gmail.com> wrote:
Larry, it think that the part about vote rounding is not clear enough; it's understandable through the examples, but the rule is somewhat "implicit" in there.
Il giorno mercoledì 24 agosto 2016 15:51:27 UTC+2, Larry Garfield ha scritto:Can you note anything in particular that is clumsy to read? We were aiming for explicitness and lack of vagueness, which in prose does tend to lead to verbosity. To me it still reads fairly well, but as the author I am of course biased on that front. :-)
--Larry Garfield
On 08/24/2016 05:27 AM, 'Alexander Makarov' via PHP Framework Interoperability Group wrote:
Well, clarity of the document. It takes time to find what you need so maybe wording or structure could be improved for better comprehension, cross-linking introduced etc.
On Wednesday, August 24, 2016 at 1:07:40 AM UTC+3, Alessandro Lai wrote:Well, the vote has now been canceled. I've just now finished reading again the full diff, and I've found clarifications about possible tie votes: majority must be +1 with 50%: https://github.com/php-fig/fig-standards/pull/752/files#diff-a7e6254aa839471064951898e0ebb021R17So basically no tie is possible.
Are there any other doubts to be settled?
--
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+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages