[Proposal] FIG 3.0
2031 views
Skip to first unread message
Larry Garfield
Apr 22, 2016, 10:41:06 AM4/22/16
to php...@googlegroups.com
Introduction
Hi folks. This took quite a bit longer than intended, but it is what it is.
Back in January/February, there was a lengthy discussion about FIG, its
structure, its purpose, its audience, and so forth. It was a good
discussion, and surfaced a number of issues. There was also some talk
of possible changes to help find solutions.
Since then, Michael Cullum and I have been working on a proposal to
partially restructure FIG based on those discussions. Rather than a
piecemeal approach, we decided that enough issues warranted a holistic
approach that the resulting document is intended to supplant most of our
current structural bylaws. (Those relating to licensing and such are
not relevant so we didn't touch those.) We've informally dubbed this
proposal FIG 3.0. (FIG 2.0 being the formal Editor/Sponsor/Coordinator
bylaw, FIG 1.0 being the wild-west that preceded that.) The full
proposal is here, as a PR:
https://github.com/php-fig/fig-standards/pull/752
*
*If you prefer it as one big Google Doc, that is available here:
*https://docs.google.com/document/d/1ZlJiOB-Ab_c-8-6BHpQhu0ZqE2Rr1kP7sWoWBbM7v_Q/edit?usp=sharing
**(But please use this email thread for feedback, so it's all in one place.)
Before you dig in too deep, however, I wanted to offer an overview and
explanation of the key changes being proposed. The text itself is a bit
long, but that's mainly because we took the time to flesh out a lot more
"error conditions" than before. This is at least the 3rd organization
I've been involved in defining bylaws for and Michael studied Law, so we
knew from experience that it's better to make sure edge cases are
handled up front before you have a runtime exception. :-) The key
reforms, however, are as follows:
1) An actual formal mission statement.
**
*
Specifically, one that clarifies FIG as looking to advance the PHP
ecosystem as a whole, not exclusively member projects. It also
solidifies that both practical experience and our own R&D are intended
inputs.
A lot has changed since the PHP Standards Group was originally formed.
The "market need" and approach that made sense a few years ago is not
what PHP would most benefit from today and into the future; that's OK.
That's healthy. Based on the previous discussion, the informal Reddit
survey/thread, and other general zeitgeist information, we believe that
FIG should willingly fill the vacuum of "PHP user-space standards body".
Whether or not that was appropriate in the past, it is the right thing
to do today.
2) A more robust Working Group structure
Our working groups today are still fairly informal, and are missing a
lot of detail needed to keep them working smoothly. The formal Editor
position helped a great deal to clarify who does what, but as we've seen
there are still a number of problems with the current model. Most
notably, there is the ever-present question of "standardize existing or
design new" as well as what role people other than the Editor play.
Another issue we're seeing with some newer proposals is people working
"under the radar". That offers no visibility into their process, nor a
way for people to join the effort when appropriate.
To address that, rather than 2 Sponsors and an Editor a Working Group
now requires 5 people, one of whom is the Editor and one of whom is the
Sponsor, of whom there is now only one. The Working Group (aside from
the Sponsor) can be anyone, but the formal members have an actual vote;
A PSR cannot move from Draft to Review without a 2/3 vote of the Working
Group, which means that while no one person (other than the Editor) can
stonewall a PSR, there must still be a reasonably broad consensus of the
involved parties to move forward.
Additionally, while in Review trial implementations of the PSR must be
worked on. (If they haven't been already.) That balances the "existing
or new design" question. By the time of the final vote, it *is* an
existing design. Whether it was designed entirely by the Working Group,
adopted from some existing package, or (most likely) some combination
thereof, there is proof-of-viability for a PSR before it can be
finalized. That helps flush out "wait, that can't actually be
implemented" problems before a PSR is frozen, and helps to verify the
usefulness of the spec.
Since member projects are like to be a good source of useful experience
for a working group, project reps essentially get a "fast track" onto a
relevant Working Group. Working Groups can then be granted their own
sub-lists/sub-forums, git repos, etc. to improve transparency into their
process by both FIG and the community at large.
This model is inspired by IETF's working groups, although adapted for
FIG's smaller size and scope.
3) A more focused, people-centric core team
A regular issue we discuss is the role of projects in FIG. Do we admit
projects or people? (Answer: Kinda sorta both, depending on the vote.)
How can we get project reps actually engaged? (Answer: We rarely do.)
How can people who aren't identified with some "major" project (for
some definition of major) get involved in a meaningful way? What is the
purpose, if there is one, of the "Community" representative position
that Cal formerly held? Do we "need" to get projects to join FIG for
them to have a say, or is that putting the cart before the horse? (Yes.)
Our solution here is to acknowledge two facts.
A) A majority of projects will not have an interest in a majority of the
work FIG does at any given time, at least not enough to meaningfully
contribute. That's OK.
B) Being a formal project lead is a poor filter for "having skin in the
game", but we do still need experienced, informed, skilled hands at the
wheel.
Therefore, we setup a new group within FIG that we're calling the Core
Committee (whose members are called Core Committee members). We're
calling it that because we've not come up with a better name yet. Core
Committee [member] is a mouthful and I'd really like to have a better
name before this thing goes to a vote. We already have "Representatives"
so "Senator" is the obvious tongue-in-cheek option, but that sounds too
pompous and also leads to jokes about the ImPHPerial Senate, which we
probably don't want. :-) Suggestions for a better name here are very
welcome.
In any event, the CC is a 12 person team, who, like the Secretaries, are
elected for 2 year terms, staggered 8 months apart so that there's a
natural continuity over time. Most of the "we need you to actually pay
attention" tasks we currently lean on project reps for we shift to the
CC. That includes the Entrance vote and Approval vote for PSRs. CC
members are those actively engaged at most/all times.
Realistically, if we look at FIG's activity now, 12 is about as large a
group as we can muster that is going to pay regular attention. Most
people don't, and won't, and we accept that. This way, we know we have
people actively looking at FIG, FIG's work, and the ecosystem holistically.
Crucially, however, the CC members *do not have to be project reps*.
They can be, but they're elected from the PHP community at large.
There are certainly people who would be good for the job that are not
closely affiliated with any particular project, and that's OK. Just as
crucially, CC members are elected by not just project reps, but also the
FIG-engaged PHP community. We've defined that as anyone who's
contributed something on the mailing list 5 times in the last year.
That means most members of working groups are going to end up
qualifying by default. They still have to be nominated by a project
rep, however, which keeps the project reps at least somewhat engaged and
acts as a stop against any random person deciding to self-nominate and
go crazy.
The net result is that CC members are, unequivocally, elected as
"people", not projects. Which means when admitting a project, we can
and should vote on them, unequivocally, as "projects", not people. The
answer to "projects or people" is "one of each." :-)
In a sense, we go from one "community rep" to 12, and put them in
charge. If 10 of those 12 also happen to be project reps, that's OK.
If 2 of them happen to be project reps, that's OK. We divorce those
questions from each other while still providing a natural filter so that
we should end up with responsible, informed, skilled individuals
populating the CC.
4) Greater clarity around project membership itself
While this is a less important issue given the changes above, we also
include more definition around what sort of organizations we want as
members. This is a bit of a change from the current (lack of)
convention, but is based on our experience in the last few years. In
particular:
A) Redefine member projects as not being exclusively PHP-code projects.
That would allow in organizations like OWASP, and, potentially,
companies like JetBrains. (However, to some extent their input would
still be more valuable on the appropriate Working Group.)
B) Clarify that projects need to be for-reals projects, not
aspirational. This is already a de facto stance we've taken but this
formalizes it.
C) Clarify that "mere extensions" are already covered by their parent
project. IE, a particular Symfony bundle or Drupal module is not
eligible, but a project build on Symfony (like Drupal, phpBB, or
Laravel) is.
D) Clarify that projects:representatives is a 1:1 relationship.
With the exception of the first point this is already de facto the case.
That covers, I believe, the bulk of the document. Much of the rest of
it is simply fleshing out process around the above reforms, but please
do take the time to review it in detail. Like all good developers, we
know full well that there's probably a dozen bugs in the alpha version.
Large swaths of it are copy-paste-tweak from the current bylaws, but
reorganized into a cohesive whole and spell-checked.
Overall, we believe this model solves a host of the challenges FIG now
faces:
1) People or Projects?
2) "Just for us" or for the community?
3) How inventive can we be?
4) How can we get project reps to be engaged?
5) How do we ensure those with relevant input have a voice?
6) How do we ensure only "battle tested" work gets as far as PSR stage?
7) How can we broaden our community involvement while maintaining, or
even improving, a good signal/noise ratio?
These solutions all build off of each other; realistically, I don't
believe a piecemeal approach would be effective. It is the holistic
approach that makes it work, because different parts complement each other.
I'd like to close by thanking my co-conspirator, Michael Cullum, for all
of his work on this proposal over the last few months, as well as the
input from others whose brains we've picked. And with that, I open the
floor for questions.****
--
--Larry Garfield
Hi folks. This took quite a bit longer than intended, but it is what it is.
Back in January/February, there was a lengthy discussion about FIG, its
structure, its purpose, its audience, and so forth. It was a good
discussion, and surfaced a number of issues. There was also some talk
of possible changes to help find solutions.
Since then, Michael Cullum and I have been working on a proposal to
partially restructure FIG based on those discussions. Rather than a
piecemeal approach, we decided that enough issues warranted a holistic
approach that the resulting document is intended to supplant most of our
current structural bylaws. (Those relating to licensing and such are
not relevant so we didn't touch those.) We've informally dubbed this
proposal FIG 3.0. (FIG 2.0 being the formal Editor/Sponsor/Coordinator
bylaw, FIG 1.0 being the wild-west that preceded that.) The full
proposal is here, as a PR:
https://github.com/php-fig/fig-standards/pull/752
*
*If you prefer it as one big Google Doc, that is available here:
*https://docs.google.com/document/d/1ZlJiOB-Ab_c-8-6BHpQhu0ZqE2Rr1kP7sWoWBbM7v_Q/edit?usp=sharing
**(But please use this email thread for feedback, so it's all in one place.)
Before you dig in too deep, however, I wanted to offer an overview and
explanation of the key changes being proposed. The text itself is a bit
long, but that's mainly because we took the time to flesh out a lot more
"error conditions" than before. This is at least the 3rd organization
I've been involved in defining bylaws for and Michael studied Law, so we
knew from experience that it's better to make sure edge cases are
handled up front before you have a runtime exception. :-) The key
reforms, however, are as follows:
1) An actual formal mission statement.
**
*
Specifically, one that clarifies FIG as looking to advance the PHP
ecosystem as a whole, not exclusively member projects. It also
solidifies that both practical experience and our own R&D are intended
inputs.
A lot has changed since the PHP Standards Group was originally formed.
The "market need" and approach that made sense a few years ago is not
what PHP would most benefit from today and into the future; that's OK.
That's healthy. Based on the previous discussion, the informal Reddit
survey/thread, and other general zeitgeist information, we believe that
FIG should willingly fill the vacuum of "PHP user-space standards body".
Whether or not that was appropriate in the past, it is the right thing
to do today.
2) A more robust Working Group structure
Our working groups today are still fairly informal, and are missing a
lot of detail needed to keep them working smoothly. The formal Editor
position helped a great deal to clarify who does what, but as we've seen
there are still a number of problems with the current model. Most
notably, there is the ever-present question of "standardize existing or
design new" as well as what role people other than the Editor play.
Another issue we're seeing with some newer proposals is people working
"under the radar". That offers no visibility into their process, nor a
way for people to join the effort when appropriate.
To address that, rather than 2 Sponsors and an Editor a Working Group
now requires 5 people, one of whom is the Editor and one of whom is the
Sponsor, of whom there is now only one. The Working Group (aside from
the Sponsor) can be anyone, but the formal members have an actual vote;
A PSR cannot move from Draft to Review without a 2/3 vote of the Working
Group, which means that while no one person (other than the Editor) can
stonewall a PSR, there must still be a reasonably broad consensus of the
involved parties to move forward.
Additionally, while in Review trial implementations of the PSR must be
worked on. (If they haven't been already.) That balances the "existing
or new design" question. By the time of the final vote, it *is* an
existing design. Whether it was designed entirely by the Working Group,
adopted from some existing package, or (most likely) some combination
thereof, there is proof-of-viability for a PSR before it can be
finalized. That helps flush out "wait, that can't actually be
implemented" problems before a PSR is frozen, and helps to verify the
usefulness of the spec.
Since member projects are like to be a good source of useful experience
for a working group, project reps essentially get a "fast track" onto a
relevant Working Group. Working Groups can then be granted their own
sub-lists/sub-forums, git repos, etc. to improve transparency into their
process by both FIG and the community at large.
This model is inspired by IETF's working groups, although adapted for
FIG's smaller size and scope.
3) A more focused, people-centric core team
A regular issue we discuss is the role of projects in FIG. Do we admit
projects or people? (Answer: Kinda sorta both, depending on the vote.)
How can we get project reps actually engaged? (Answer: We rarely do.)
How can people who aren't identified with some "major" project (for
some definition of major) get involved in a meaningful way? What is the
purpose, if there is one, of the "Community" representative position
that Cal formerly held? Do we "need" to get projects to join FIG for
them to have a say, or is that putting the cart before the horse? (Yes.)
Our solution here is to acknowledge two facts.
A) A majority of projects will not have an interest in a majority of the
work FIG does at any given time, at least not enough to meaningfully
contribute. That's OK.
B) Being a formal project lead is a poor filter for "having skin in the
game", but we do still need experienced, informed, skilled hands at the
wheel.
Therefore, we setup a new group within FIG that we're calling the Core
Committee (whose members are called Core Committee members). We're
calling it that because we've not come up with a better name yet. Core
Committee [member] is a mouthful and I'd really like to have a better
name before this thing goes to a vote. We already have "Representatives"
so "Senator" is the obvious tongue-in-cheek option, but that sounds too
pompous and also leads to jokes about the ImPHPerial Senate, which we
probably don't want. :-) Suggestions for a better name here are very
welcome.
In any event, the CC is a 12 person team, who, like the Secretaries, are
elected for 2 year terms, staggered 8 months apart so that there's a
natural continuity over time. Most of the "we need you to actually pay
attention" tasks we currently lean on project reps for we shift to the
CC. That includes the Entrance vote and Approval vote for PSRs. CC
members are those actively engaged at most/all times.
Realistically, if we look at FIG's activity now, 12 is about as large a
group as we can muster that is going to pay regular attention. Most
people don't, and won't, and we accept that. This way, we know we have
people actively looking at FIG, FIG's work, and the ecosystem holistically.
Crucially, however, the CC members *do not have to be project reps*.
They can be, but they're elected from the PHP community at large.
There are certainly people who would be good for the job that are not
closely affiliated with any particular project, and that's OK. Just as
crucially, CC members are elected by not just project reps, but also the
FIG-engaged PHP community. We've defined that as anyone who's
contributed something on the mailing list 5 times in the last year.
That means most members of working groups are going to end up
qualifying by default. They still have to be nominated by a project
rep, however, which keeps the project reps at least somewhat engaged and
acts as a stop against any random person deciding to self-nominate and
go crazy.
The net result is that CC members are, unequivocally, elected as
"people", not projects. Which means when admitting a project, we can
and should vote on them, unequivocally, as "projects", not people. The
answer to "projects or people" is "one of each." :-)
In a sense, we go from one "community rep" to 12, and put them in
charge. If 10 of those 12 also happen to be project reps, that's OK.
If 2 of them happen to be project reps, that's OK. We divorce those
questions from each other while still providing a natural filter so that
we should end up with responsible, informed, skilled individuals
populating the CC.
4) Greater clarity around project membership itself
While this is a less important issue given the changes above, we also
include more definition around what sort of organizations we want as
members. This is a bit of a change from the current (lack of)
convention, but is based on our experience in the last few years. In
particular:
A) Redefine member projects as not being exclusively PHP-code projects.
That would allow in organizations like OWASP, and, potentially,
companies like JetBrains. (However, to some extent their input would
still be more valuable on the appropriate Working Group.)
B) Clarify that projects need to be for-reals projects, not
aspirational. This is already a de facto stance we've taken but this
formalizes it.
C) Clarify that "mere extensions" are already covered by their parent
project. IE, a particular Symfony bundle or Drupal module is not
eligible, but a project build on Symfony (like Drupal, phpBB, or
Laravel) is.
D) Clarify that projects:representatives is a 1:1 relationship.
With the exception of the first point this is already de facto the case.
That covers, I believe, the bulk of the document. Much of the rest of
it is simply fleshing out process around the above reforms, but please
do take the time to review it in detail. Like all good developers, we
know full well that there's probably a dozen bugs in the alpha version.
Large swaths of it are copy-paste-tweak from the current bylaws, but
reorganized into a cohesive whole and spell-checked.
Overall, we believe this model solves a host of the challenges FIG now
faces:
1) People or Projects?
2) "Just for us" or for the community?
3) How inventive can we be?
4) How can we get project reps to be engaged?
5) How do we ensure those with relevant input have a voice?
6) How do we ensure only "battle tested" work gets as far as PSR stage?
7) How can we broaden our community involvement while maintaining, or
even improving, a good signal/noise ratio?
These solutions all build off of each other; realistically, I don't
believe a piecemeal approach would be effective. It is the holistic
approach that makes it work, because different parts complement each other.
I'd like to close by thanking my co-conspirator, Michael Cullum, for all
of his work on this proposal over the last few months, as well as the
input from others whose brains we've picked. And with that, I open the
floor for questions.****
--
--Larry Garfield
Joe Ferguson
Apr 22, 2016, 10:55:22 AM4/22/16
to php...@googlegroups.com
I'm really happy to see this shared with the group in the form of what appears to be a great proposal. Thanks Larry and Michael for putting this together.
--
- Joe Ferguson
JoeFerguson.me
MemphisPHP.org
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/571A37FB.2030709%40garfieldtech.com.
> For more options, visit https://groups.google.com/d/optout.
--
- Joe Ferguson
JoeFerguson.me
MemphisPHP.org
> 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.
> To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/571A37FB.2030709%40garfieldtech.com.
> For more options, visit https://groups.google.com/d/optout.
Samantha Quiñones
Apr 22, 2016, 11:17:15 AM4/22/16
to PHP Framework Interoperability Group
Thank you, Larry & Michael for all the work you've put into this proposal! I'm excited to see this develop. :)
--
Samantha Quiñones
Chris Tankersley
Apr 22, 2016, 11:19:28 AM4/22/16
to php...@googlegroups.com
Thank you Larry and Michael. If nothing else, I'm glad to see the abandonment issue finally making its way to the light of day!
I'll be interested to see how the wider community reacts to the possibility of FIG becoming what we were originally "shamed" out of being, which was a group of people that came up with standards that we thrust upon the world of PHP. I know full well that wasn't the original case and isn't the case today, but we'll see how the community reacts in whole.
Overall I'm happy with the proposed changes and clarifications. As it relates to the core committee, we're effectively doing that now, as there are only a handful of projects that work heavily on the PSRs and much of the discussion. I'm guilty of not being involved as much as I probably should be, but it is what it is. I think having a Community vote is important, and the committee helps fulfill that need and, if we are being more community focused, give the community more of a specific say in what we do.
For me, overall this is a +1.
-Chris, Sculpin
--
--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+u...@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/571A37FB.2030709%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
Benni Mack
Apr 22, 2016, 12:34:36 PM4/22/16
to php...@googlegroups.com
Larry and Michael,
this is really a great analysis and a next generation for FIG, love the ideas and the results!
Thanks for this massive work.
All the best,
Benni.
- TYPO3 Core Team Leader
TYPO3... inspire people to share
this is really a great analysis and a next generation for FIG, love the ideas and the results!
Thanks for this massive work.
All the best,
Benni.
- TYPO3 Core Team Leader
TYPO3... inspire people to share
Alessandro Lai
Apr 22, 2016, 1:56:41 PM4/22/16
to PHP Framework Interoperability Group
This is really a nice and very detailed work! Thanks to both for you work!
Paul Jones
Apr 22, 2016, 2:02:41 PM4/22/16
to php...@googlegroups.com
Hi all,
> On Apr 22, 2016, at 09:40, Larry Garfield <la...@garfieldtech.com> wrote:
>
> *
> *If you prefer it as one big Google Doc, that is available here:
>
> *https://docs.google.com/document/d/1ZlJiOB-Ab_c-8-6BHpQhu0ZqE2Rr1kP7sWoWBbM7v_Q/edit?usp=sharing
Regarding this line ...
"FIG Secretaries will also represent the FIG as a whole to the general community and public on matters relating to the FIG's activities."
... is that an appropriate duty of a secretary? Their operations seem entirely internal to me. If there is to be a "face", I would say it should be (or be from) the Core Committee.
I'll bring up other points as they occur to me.
--
Paul M. Jones
http://paul-m-jones.com
> On Apr 22, 2016, at 09:40, Larry Garfield <la...@garfieldtech.com> wrote:
>
> *
> *If you prefer it as one big Google Doc, that is available here:
>
> *https://docs.google.com/document/d/1ZlJiOB-Ab_c-8-6BHpQhu0ZqE2Rr1kP7sWoWBbM7v_Q/edit?usp=sharing
"FIG Secretaries will also represent the FIG as a whole to the general community and public on matters relating to the FIG's activities."
... is that an appropriate duty of a secretary? Their operations seem entirely internal to me. If there is to be a "face", I would say it should be (or be from) the Core Committee.
I'll bring up other points as they occur to me.
--
Paul M. Jones
http://paul-m-jones.com
Michael Cullum
Apr 22, 2016, 2:24:18 PM4/22/16
to FIG, PHP
Hi Paul,
That's not a change from the existing and voted upon (unanimously) current secretary bylaw (Actually there is very little change the secretary position at all except adjustments for the new system with votes and the like).
The number of secretaries is currently 3 people which is a much more practical number for doing things like coordinating PR/DA type activities and makes sense in line with the other agreed duties such as managing the marketing materials such as Twitter. Furthermore, it makes much more sense for the secretaries to be responsible for this as they represent the interests of the FIG and are neutral, whereas core committee members are expected to have opinions, which might often differ. Public relations and developer advocacy are also much more administrative responsibilities, whereas the point of the core committee is to serve as a technical panel for assessment of PSRs. There is nothing of course though preventing anyone else (core committee members, project representatives or community members) from giving conference talks and the like about the PHP FIG and this is something to be actively encouraged.
Also I'd add that this almost happened accidentally anyway as at the past few conferences myself, Samantha and Joe have been in attendance at, we've had so many people coming up to us to talk about the FIG and it's operations/PSRs. Just in the short space of a few months, the role has proven itself to be successful at getting people engaged with the FIG and spreading information about PSRs we produce.
Thanks,
Michael
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/76C481EC-6387-4EC8-8C50-4227D97ACC10%40gmail.com.
Korvin Szanto
Apr 22, 2016, 2:50:19 PM4/22/16
to FIG, PHP
Hi All,
I am hard-pressed to express how I feel about this proposal, inspired and reenergized might be as close as I can get. Spending the time to put this together and to champion it is way above and beyond and much appreciated, if this proposal passes I owe you both lunch and maybe a hug.
I combed through this proposal and absolutely loved every part, I even exclaimed a big "YES" when I read the part about dropping member projects who do not express their intent to remain in the group within 30 days of the vote being accepted. This feels to me like exactly what this group needed, I cannot wait until we can start implementing.
Thanks!
Korvin
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAAqcDMghwntAq4t2wOvTB5W3o-6eh%3DE%3DStWNzKKELmLLfFjKpw%40mail.gmail.com.
Jeremy Lindblom
Apr 22, 2016, 2:50:45 PM4/22/16
to php...@googlegroups.com
In the section about "Core Committee Vacancy" there was something the "fifth-highest voted candidate" that I did not understand at all. Everything else I've made it through so far seems fine.
--
Jeremy Lindblom (@jeremeamia)
Software/Platform Engineer at Engrade (part of McGraw-Hill Education)
Jeremy Lindblom (@jeremeamia)
Software/Platform Engineer at Engrade (part of McGraw-Hill Education)
Co-organizer of the Arizona PHP User Group (@azphp)
Co-founder of the Pacific Northwest PHP Conference (@PNWPHP)
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAAqcDMghwntAq4t2wOvTB5W3o-6eh%3DE%3DStWNzKKELmLLfFjKpw%40mail.gmail.com.
Larry Garfield
Apr 22, 2016, 3:41:04 PM4/22/16
to php...@googlegroups.com
The wording there was a bit hard to phrase, so there's room for
improvement. Let me try and flesh it out a bit.
Under normal circumstances, come election month, there are 4 CC seats
open. Let's say there 7 candidates. We use STP to winnow those 7 down
to 4, who are the new CC members. The other 3 get a hardy handshake and
thanks for playing.
However, suppose that there's a vacancy for one of the other CC seats,
because someone resigned part way through their term. Now, whoever the
last person to be eliminated for the 4 "normal" seats (for 24 months) is
would get that extra seat, but only for the remaining time left on that
term. (Which is either 8 or 16 months.) If there's 2 extra open seats
for the same duration, the last 2 people to be eliminated before we pick
the final 4 get that them. If they're for a different duration, the 5th
place person gets the 16 month term and the 6th place person gets the 8
month term.
For the initial CC election, we go through that process all the way down
to pick the full slate of 12, just as we did for the Secretaries albeit
with sets of 4 rather than sets of 1.
Is that clearer? Any suggestions on how to make the wording clearer,
other than a long list of examples?
On 4/22/16 1:50 PM, Jeremy Lindblom wrote:
> In the section about "Core Committee Vacancy" there was something the
> "fifth-highest voted candidate" that I did not understand at all.
> Everything else I've made it through so far seems fine.
>
> --
> *Jeremy Lindblom (@jeremeamia <https://twitter.com/jeremeamia>)*
> Software/Platform Engineer at Engrade <https://engrade.com/> (part of
> McGraw-Hill Education <http://www.mheducation.com/>)
> <https://groups.google.com/d/msgid/php-fig/CAAqcDMghwntAq4t2wOvTB5W3o-6eh%3DE%3DStWNzKKELmLLfFjKpw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> <https://groups.google.com/d/msgid/php-fig/CALDVupK-2U6zwqMrE4skCFz-MMANdR2YEREvSf21NYL37Trbwg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--Larry Garfield
improvement. Let me try and flesh it out a bit.
Under normal circumstances, come election month, there are 4 CC seats
open. Let's say there 7 candidates. We use STP to winnow those 7 down
to 4, who are the new CC members. The other 3 get a hardy handshake and
thanks for playing.
However, suppose that there's a vacancy for one of the other CC seats,
because someone resigned part way through their term. Now, whoever the
last person to be eliminated for the 4 "normal" seats (for 24 months) is
would get that extra seat, but only for the remaining time left on that
term. (Which is either 8 or 16 months.) If there's 2 extra open seats
for the same duration, the last 2 people to be eliminated before we pick
the final 4 get that them. If they're for a different duration, the 5th
place person gets the 16 month term and the 6th place person gets the 8
month term.
For the initial CC election, we go through that process all the way down
to pick the full slate of 12, just as we did for the Secretaries albeit
with sets of 4 rather than sets of 1.
Is that clearer? Any suggestions on how to make the wording clearer,
other than a long list of examples?
On 4/22/16 1:50 PM, Jeremy Lindblom wrote:
> In the section about "Core Committee Vacancy" there was something the
> "fifth-highest voted candidate" that I did not understand at all.
> Everything else I've made it through so far seems fine.
>
> --
> Software/Platform Engineer at Engrade <https://engrade.com/> (part of
> McGraw-Hill Education <http://www.mheducation.com/>)
> Co-organizer of the Arizona PHP User Group
> <http://www.meetup.com/azPHPUG/> (@azphp <https://twitter.com/azphp/>)
> Co-founder of the Pacific Northwest PHP Conference
> <http://pnwphp.com/> (@PNWPHP <https://twitter.com/pnwphp>)
> <la...@garfieldtech.com <mailto:la...@garfieldtech.com>> wrote:
> >
> > *
> > *If you prefer it as one big Google Doc, that is available here:
> >
> >
> *https://docs.google.com/document/d/1ZlJiOB-Ab_c-8-6BHpQhu0ZqE2Rr1kP7sWoWBbM7v_Q/edit?usp=sharing
>
> Regarding this line ...
>
> "FIG Secretaries will also represent the FIG as a whole to the
> general community and public on matters relating to the FIG's
> activities."
>
> ... is that an appropriate duty of a secretary? Their
> operations seem entirely internal to me. If there is to be a
> "face", I would say it should be (or be from) the Core Committee.
>
> I'll bring up other points as they occur to me.
>
>
> --
>
> Paul M. Jones
> http://paul-m-jones.com
>
>
>
> --
> 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
> <mailto:php-fig%2Bunsu...@googlegroups.com>.
> >
> > *
> > *If you prefer it as one big Google Doc, that is available here:
> >
> >
> *https://docs.google.com/document/d/1ZlJiOB-Ab_c-8-6BHpQhu0ZqE2Rr1kP7sWoWBbM7v_Q/edit?usp=sharing
>
> Regarding this line ...
>
> "FIG Secretaries will also represent the FIG as a whole to the
> general community and public on matters relating to the FIG's
> activities."
>
> ... is that an appropriate duty of a secretary? Their
> operations seem entirely internal to me. If there is to be a
> "face", I would say it should be (or be from) the Core Committee.
>
> I'll bring up other points as they occur to me.
>
>
> --
>
> Paul M. Jones
> http://paul-m-jones.com
>
>
>
> --
> 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
> <mailto:php...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/76C481EC-6387-4EC8-8C50-4227D97ACC10%40gmail.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+u...@googlegroups.com
> <mailto:php-fig+u...@googlegroups.com>.
> https://groups.google.com/d/msgid/php-fig/76C481EC-6387-4EC8-8C50-4227D97ACC10%40gmail.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+u...@googlegroups.com
> To post to this group, send email to php...@googlegroups.com
> <mailto:php...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/CAAqcDMghwntAq4t2wOvTB5W3o-6eh%3DE%3DStWNzKKELmLLfFjKpw%40mail.gmail.com
> <https://groups.google.com/d/msgid/php-fig/CAAqcDMghwntAq4t2wOvTB5W3o-6eh%3DE%3DStWNzKKELmLLfFjKpw%40mail.gmail.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 php-fig+u...@googlegroups.com
> <mailto:php-fig+u...@googlegroups.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+u...@googlegroups.com
> To post to this group, send email to php...@googlegroups.com
> <mailto:php...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/CALDVupK-2U6zwqMrE4skCFz-MMANdR2YEREvSf21NYL37Trbwg%40mail.gmail.com
> <https://groups.google.com/d/msgid/php-fig/CALDVupK-2U6zwqMrE4skCFz-MMANdR2YEREvSf21NYL37Trbwg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--Larry Garfield
Paul Jones
Apr 22, 2016, 5:45:55 PM4/22/16
to php...@googlegroups.com
Hi all,
As a matter of historical record, it seems to me that as bylaws and administrative rules have increased, productivity in the form of finished PSRs has decreased.
When grouping PSR production using the 1.0/2.0 categories provided by Larry & Michael, there were four PSRs produced entirely under 1.0, two PSRs produced that began under 1.0 and finished under 2.0, and one that began and finished under 2.0.
- FIG 1.0
- PSR-0
- PSR-1
- PSR-2
- PSR-3
- FIG 1.0-2.0 (transitional)
- PSR-4
- PSR-6
- FIG 2.0
- PSR-7
For what it's worth, these are (to the best of my knowledge) the approximate dates of the relevant PSRs and bylaws:
- 2010 Nov: PSR-0 (1.0)
- 2012 Jun: PSR-1 (1.0)
- 2012 Jun: PSR-2 (1.0)
- 2013 Jan: PSR-3 (1.0)
- 2013 Mar: Membership bylaw (2.0 ?)
- 2013 Aug: Workflow bylaw (2.0)
- 2013 Dec: PSR-4 (transitional)
- 2015 May: PSR-7 (2.0)
- 2015 Dec: PSR-6 (transitional)
Perhaps there are other factors than the volume of bylaw regulation. Even so, given this particular historical correlation, adding bylaws seems to decrease the productive output of the group, not increase it. If true, that bodes poorly for the stated mission.
As a matter of historical record, it seems to me that as bylaws and administrative rules have increased, productivity in the form of finished PSRs has decreased.
When grouping PSR production using the 1.0/2.0 categories provided by Larry & Michael, there were four PSRs produced entirely under 1.0, two PSRs produced that began under 1.0 and finished under 2.0, and one that began and finished under 2.0.
- FIG 1.0
- PSR-0
- PSR-1
- PSR-2
- PSR-3
- FIG 1.0-2.0 (transitional)
- PSR-4
- PSR-6
- FIG 2.0
- PSR-7
For what it's worth, these are (to the best of my knowledge) the approximate dates of the relevant PSRs and bylaws:
- 2010 Nov: PSR-0 (1.0)
- 2012 Jun: PSR-1 (1.0)
- 2012 Jun: PSR-2 (1.0)
- 2013 Jan: PSR-3 (1.0)
- 2013 Mar: Membership bylaw (2.0 ?)
- 2013 Aug: Workflow bylaw (2.0)
- 2013 Dec: PSR-4 (transitional)
- 2015 May: PSR-7 (2.0)
- 2015 Dec: PSR-6 (transitional)
Perhaps there are other factors than the volume of bylaw regulation. Even so, given this particular historical correlation, adding bylaws seems to decrease the productive output of the group, not increase it. If true, that bodes poorly for the stated mission.
Jordi Boggiano
Apr 22, 2016, 6:54:18 PM4/22/16
to php...@googlegroups.com
I don't always agree with Paul, and I am not sure that those numbers are
statistically very relevant, but they help illustrate a feeling that I
share, so here goes.
While I do appreciate the amount of work that went into this endeavor,
it scares me a little as well. Clarifying the group's purpose has my
vote for sure, but the other layers of bureaucracy TBH I think we
already have too much of it.
Obviously another problem is just that there aren't a million things
that are fit for PSRs, but even if I had an idea, I would think twice
before even attempting it right now because I'd have to read through so
much bylaws to make sure I don't mess up the process that I would
probably give up.
I realize there are various schools of thought, and we won't all agree
on this. That's fine, maybe I just don't belong in a standards body. I
wouldn't take that personally :) Just had to give my 2c here.
Best Regards,
Jordi
Jordi Boggiano
@seldaek - http://seld.be
statistically very relevant, but they help illustrate a feeling that I
share, so here goes.
While I do appreciate the amount of work that went into this endeavor,
it scares me a little as well. Clarifying the group's purpose has my
vote for sure, but the other layers of bureaucracy TBH I think we
already have too much of it.
Obviously another problem is just that there aren't a million things
that are fit for PSRs, but even if I had an idea, I would think twice
before even attempting it right now because I'd have to read through so
much bylaws to make sure I don't mess up the process that I would
probably give up.
I realize there are various schools of thought, and we won't all agree
on this. That's fine, maybe I just don't belong in a standards body. I
wouldn't take that personally :) Just had to give my 2c here.
Best Regards,
Jordi
@seldaek - http://seld.be
Larry Garfield
Apr 23, 2016, 12:24:42 AM4/23/16
to php...@googlegroups.com
I appreciate the reticence toward "moar rules", but looking beyond the
surface what Paul is describing is a very clear correlation fallacy,
even if we leave aside the highly problematic approach of treating PSR
throughput as a measure of FIG's "success".
To start off, PSR-0 I wouldn't call FIG 1.0. More FIG 0.1. :-) That
structure for FIG wasn't really a structure and didn't really last.
Then PSR-1 and PSR-2 came as, essentially, a matched set, as they
started off as the same spec and split late, and were voted on back to
back. That means, practically, FIG 1.0 had 2 specs (PSR-1/2 and PSR-3),
there were 2 "transitional" specs (PSR-4, PSR-6), and one purely FIG 2.0
spec (PSR-7.) Hardly a strong case for any particular model there.
If we look at those specs that took an uncomfortably long time (PSR-6)
or have been stalled out or de facto abandoned (5, 9, 10), in none of
those cases is "too much process" the problem. On the contrary, the
common pattern I see in those is:
* inter-personal issues exacerbated by lack of clarity around the
relationship between the listed Editor and other contributors.
* Too broad a scope.
* Editor burnout from being the only person really paying attention.
The revised Working Group structure, in fact, seeks to address those
issues precisely by giving the Working Group more clarity, and a clearer
set of people within whom to spread the load. Raising the barrier to
entry from "1 person wants to work on it, 2 thing it's a good idea, and
everyone else thinks it's at least not harmful" to "5 people want to
work on it, and everyone else thinks it's at least not harmful." That
is, specs that don't really have a reasonable level of vested interest
are likely to not be able to form in the first place, and if they do but
the Editor ends up having the time for it there are 4 other active and
interested parties that can take over.
(Would that mean that, for instance, PSR-9 or 10 may not have made it to
an Entrance Vote if there wasn't enough interest? Maybe. In which case
that's probably a good thing. Or it would have incentivised more
interested parties to get involved from the beginning, and we would have
less of a single-point-of-failure issue later. Either way, that's a win
over the status quo.)
For most people who just want to work on a PSR, there's no need to read
a 13 page document. The PSR process section specificlally is not
appreciably longer than what we already have; all it adds is the larger
working group and a "you have to actually try and build this thing"
phase, which is also a real problem that multiple people have pointed
out with our current process.
So it's not really a "more process vs. less process" question at all.
It's identifying the actual, demonstrable pain points and proposing
targeted changes to address them.
The rest is just wordsmithing.
--Larry Garfield
surface what Paul is describing is a very clear correlation fallacy,
even if we leave aside the highly problematic approach of treating PSR
throughput as a measure of FIG's "success".
To start off, PSR-0 I wouldn't call FIG 1.0. More FIG 0.1. :-) That
structure for FIG wasn't really a structure and didn't really last.
Then PSR-1 and PSR-2 came as, essentially, a matched set, as they
started off as the same spec and split late, and were voted on back to
back. That means, practically, FIG 1.0 had 2 specs (PSR-1/2 and PSR-3),
there were 2 "transitional" specs (PSR-4, PSR-6), and one purely FIG 2.0
spec (PSR-7.) Hardly a strong case for any particular model there.
If we look at those specs that took an uncomfortably long time (PSR-6)
or have been stalled out or de facto abandoned (5, 9, 10), in none of
those cases is "too much process" the problem. On the contrary, the
common pattern I see in those is:
* inter-personal issues exacerbated by lack of clarity around the
relationship between the listed Editor and other contributors.
* Too broad a scope.
* Editor burnout from being the only person really paying attention.
The revised Working Group structure, in fact, seeks to address those
issues precisely by giving the Working Group more clarity, and a clearer
set of people within whom to spread the load. Raising the barrier to
entry from "1 person wants to work on it, 2 thing it's a good idea, and
everyone else thinks it's at least not harmful" to "5 people want to
work on it, and everyone else thinks it's at least not harmful." That
is, specs that don't really have a reasonable level of vested interest
are likely to not be able to form in the first place, and if they do but
the Editor ends up having the time for it there are 4 other active and
interested parties that can take over.
(Would that mean that, for instance, PSR-9 or 10 may not have made it to
an Entrance Vote if there wasn't enough interest? Maybe. In which case
that's probably a good thing. Or it would have incentivised more
interested parties to get involved from the beginning, and we would have
less of a single-point-of-failure issue later. Either way, that's a win
over the status quo.)
For most people who just want to work on a PSR, there's no need to read
a 13 page document. The PSR process section specificlally is not
appreciably longer than what we already have; all it adds is the larger
working group and a "you have to actually try and build this thing"
phase, which is also a real problem that multiple people have pointed
out with our current process.
So it's not really a "more process vs. less process" question at all.
It's identifying the actual, demonstrable pain points and proposing
targeted changes to address them.
The rest is just wordsmithing.
--Larry Garfield
Dracony
Apr 23, 2016, 4:48:52 AM4/23/16
to PHP Framework Interoperability Group
Tbh this starts to sound like rules of a complex board game rather than a living group of people.
Giving votes to anyone who has just 5 posts per year on the mailing list is much too relaxed. I'm sure this will be a reason for a flud of unhelpful posts by everyone who just wants to vote in elections. At this point it's probably better to just use a regular twitter poll and spare the mailing list from that fate.
Niels Braczek
Apr 23, 2016, 6:48:54 AM4/23/16
to php...@googlegroups.com
Am 23.04.2016 um 06:24 schrieb Larry Garfield:
> So it's not really a "more process vs. less process" question at all.
> It's identifying the actual, demonstrable pain points and proposing
> targeted changes to address them.
Really great proposal! As a non-member, I can see the value for the
> So it's not really a "more process vs. less process" question at all.
> It's identifying the actual, demonstrable pain points and proposing
> targeted changes to address them.
community at large.
Just one thing: Not only the number of posts on the ML should give
legitimation to vote, but also contributions to the repo.
Regards,
Niels
--
| New Stars on the Horizon: GreenCape · nibralab · laJoom |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
Jonathan Eskew
Apr 23, 2016, 12:16:02 PM4/23/16
to PHP Framework Interoperability Group, nbra...@bsds.de
I understand the motivation for having a smaller, more engaged group, but if all PSR votes are handled by a working group or the core committee, then what's the point of being a member project?
Correct me if I missed anything, but it appears that members would only vote on secretary elections, bylaw proposals, and matters of membership.
Richard Fussenegger
Apr 23, 2016, 12:51:03 PM4/23/16
to PHP Framework Interoperability Group
+1 from my side, looks nice. :)
Tbh this starts to sound like rules of a complex board game rather than a living group of people.Giving votes to anyone who has just 5 posts per year on the mailing list is much too relaxed. I'm sure this will be a reason for a flud of unhelpful posts by everyone who just wants to vote in elections. At this point it's probably better to just use a regular twitter poll and spare the mailing list from that fate.
I do not have Twitter and I do not want to have Twitter, so I am out right? I actually find it already highly disturbing that I have to write on Google Groups. A state requires only that you are a citizen and not a proof of intelligence for voting. ;)
Larry Garfield
Apr 23, 2016, 2:26:30 PM4/23/16
to php...@googlegroups.com
Member projects would also have a "fast
track" into a Working Group, if it was something they had to offer
there. For example, if there were to be a Queue working group
Taylor Otwell (Laravel, which IIRC has a queue system in it in
some form) would be welcome to join it by default, unless there
was some reason that he would be actively counter-productive.
Non-members seeking to join the WG have to show that they would
have something to add (possibly by helping out for a while first,
if they're not part of the initial team).
It's not a huge difference in practice (I doubt anyone's going to get really fussy about someone wanting to help either way unless they're really being a disruptive jerk), but it does emphasize that member projects are the "first round" of people we would expect to have useful input.
Largely, we're just formalizing what is already the case. What's the point of being a member project today? Most member projects (and their representatives) rarely post on anything other than a membership vote to begin with. Most who vote on a PSR vote do so after saying nothing at all or nearly nothing the entire time, so whether they were even paying attention is debatable. A few times we've not been able to make quorum on a vote as a result.
Meanwhile, several non-members are active on the list, or with a particular PSR, despite not being a project rep. And that's something we've generally encouraged.
For most member projects, therefore, there's not actually much difference in the status quo from right now other than member project votes not having a quorum any more. Rather, it makes it easier for projects to only pay attention to those PSRs that would directly affect them and to which they have something unique to add and ignore the rest (which is already what happens).
--Larry Garfield
It's not a huge difference in practice (I doubt anyone's going to get really fussy about someone wanting to help either way unless they're really being a disruptive jerk), but it does emphasize that member projects are the "first round" of people we would expect to have useful input.
Largely, we're just formalizing what is already the case. What's the point of being a member project today? Most member projects (and their representatives) rarely post on anything other than a membership vote to begin with. Most who vote on a PSR vote do so after saying nothing at all or nearly nothing the entire time, so whether they were even paying attention is debatable. A few times we've not been able to make quorum on a vote as a result.
Meanwhile, several non-members are active on the list, or with a particular PSR, despite not being a project rep. And that's something we've generally encouraged.
For most member projects, therefore, there's not actually much difference in the status quo from right now other than member project votes not having a quorum any more. Rather, it makes it easier for projects to only pay attention to those PSRs that would directly affect them and to which they have something unique to add and ignore the rest (which is already what happens).
--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+u...@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/9fd19453-accf-4dde-97d9-8d3010d2db45%40googlegroups.com.
Larry Garfield
Apr 23, 2016, 2:38:22 PM4/23/16
to php...@googlegroups.com
On 04/23/2016 05:48 AM, Niels Braczek wrote:
> Am 23.04.2016 um 06:24 schrieb Larry Garfield:
>
>> So it's not really a "more process vs. less process" question at all.
>> It's identifying the actual, demonstrable pain points and proposing
>> targeted changes to address them.
> Really great proposal! As a non-member, I can see the value for the
> community at large.
>
> Just one thing: Not only the number of posts on the ML should give
> legitimation to vote, but also contributions to the repo.
>
> Regards,
> Niels
That's also a possibility. Our assumption was that someone who is
> Am 23.04.2016 um 06:24 schrieb Larry Garfield:
>
>> So it's not really a "more process vs. less process" question at all.
>> It's identifying the actual, demonstrable pain points and proposing
>> targeted changes to address them.
> Really great proposal! As a non-member, I can see the value for the
> community at large.
>
> Just one thing: Not only the number of posts on the ML should give
> legitimation to vote, but also contributions to the repo.
>
> Regards,
> Niels
contributing directly to a working group is going to be active on the
list anyway, so would be caught by the same filter.
To respond to both you and Dracony here, Michael and I went back and
forth a couple of times on how to define "active and engaged" members of
the broader community. We do feel it is important to have a broader
base of support for the CC, to give non-project-affiliated people a
voice and to help show FIG as involved in the whole community. However,
that can certainly go too far; just throwing up a Twitter poll or Reddit
thread for anyone in the world (who may not even have touched PHP in
their lives) is not viable, even if it were remotely manageable to run
such an election. However, at the other extreme "well everyone knows
Cal, so we'll just go with him" isn't really a viable approach either.
:-) (No offense, Cal.) We need some middle-ground.
The idea here is that if someone has posted at least 5 times, they're
probably at least reasonably informed and engaged. Not perfectly,
perhaps, but at least well-enough. I'm flexible on the exact number,
and open to suggestions for other filtering mechanisms that achieve the
same goals above.
I am not radically concerned about "vote stuffing" as Dracony suggests
by people posting nonsense just to get a vote. For one, the Secretaries
are given leave to filter out "trivial" posts and determine the eligible
voter list. For two, if someone cares enough about FIG to go to that
trouble then they're probably engaged enough to have some input to begin
with. For three, if someone is doing so maliciously then, wow, they are
a very sad human being to have nothing better to do with their time. :-)
For four, we've never actually seen that problem to my knowledge in the
Drupal Association At Large Director elections. Those are elected
annually from a pool of "anyone with a Drupal.org account who's logged
in within the last year." I'd originally argued for only paid DA
members, but was overrruled. Still, even in our last election we had
maybe a 1.5% voter turnout. Most people just don't care enough to pay
attention. I would be shocked if enough people had strong enough
opinions about FIG to join and post just to get a vote, and somehow
managed to NOT post at least 5 non-troll, non-trivial posts in a year.
Also, there has been talk of moving voting off of the list to a
dedicated voting tool to make tallying easier. I fully support this,
and it would also eliminate the "too many people voting so the list gets
flooded with vote messages" problem, and present a clear place to list
the vetted "voter roll".
--Larry Garfield
Lukas Kahwe Smith
Apr 24, 2016, 2:51:59 AM4/24/16
to php...@googlegroups.com
Aloha,
I have only read the below summary but I do like the things about the working group. It goes along with the things I have suggested in the past in the same direction.
regards,
Lukas
PS looking at the JSR process, it doesn't seem like there is a shortage of things to standardize even if we just cover a 10th of what JSR covers ...
I have only read the below summary but I do like the things about the working group. It goes along with the things I have suggested in the past in the same direction.
regards,
Lukas
PS looking at the JSR process, it doesn't seem like there is a shortage of things to standardize even if we just cover a 10th of what JSR covers ...
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/571A37FB.2030709%40garfieldtech.com.
> 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.
Michael Cullum
Apr 24, 2016, 10:13:13 AM4/24/16
to FIG, PHP
Firstly, thanks all for your constructive comments. Your support and suggestions are very much appreciated.
The primary objection I've heard from those in this topic, and on other mediums such as reddit, is that this proposal adds a significant amount of bureaucracy to what really matters, creating PSRs and fixing PHP problems. However, this proposal actually doesn't really change the PSR workflow. The main change is who is doing the voting through the formalisation of the working groups and introduction of a core committee.
Instead of the entire membership voting on proposals entrance and acceptance votes, we have the core committee, to whom voting on such matters is essentially delegated to by the project representatives and other community members who are active in FIG affairs. The Core Committee's primary responsibilities are that of maintaining the FIG's reputation and quality as well as ensuring that Working Groups appropriately considers all view points and that the product of working groups is high quality. The Working Group contains the relevant expertise and a specification cannot proceed without those relevant to the problem space's support. Essentially what was once a single entrance vote where everyone had a single vote has been split up into a vote of relevant projects to ensure problem-space quality, and a vote of elected people to ensure overall quality and standardization.
It's been inferred by many in this topic and I'm sure most agree, standardising more things (more PSRs) is what we want to see but we need to maintain quality and around PSR-6 in particular, there were some raucous discussions that we'd all rather see avoided. Essentially, aiming for high quality and quantity whilst avoiding drama. These changes are designed to open up the PHP FIG to be a group in which we can have a number more standards coming through (It is significantly more scalable than the current model), but also provide safeguards against PSRs with little support, are unlikely to pass, have stalled, or are of a sub-par quality.
There is lots of discontent with the PHP FIG, and you don't have to go far to find it. For a number of years, and more recently in particular since becoming Secretary, I've had discussions about the FIG with people from all different parts of the PHP community, from well known people and those less well known, and nobody has said the FIG is perfect. Now, perhaps this won't make the FIG perfect, but this I hope is one step in making the FIG a better organisation that can serve the whole PHP community better and will allow us to stop arguing about points of process, and focus on what really matters.
--
Michael C
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/9625C5FF-B929-4361-944B-0958DD54D38F%40pooteeweet.org.
Lukas Kahwe Smith
Apr 25, 2016, 5:16:22 AM4/25/16
to php...@googlegroups.com
> On 24 Apr 2016, at 02:38, Larry Garfield <la...@garfieldtech.com> wrote:
>
>> On 04/23/2016 05:48 AM, Niels Braczek wrote:
>>> Am 23.04.2016 um 06:24 schrieb Larry Garfield:
>>>
>>> So it's not really a "more process vs. less process" question at all.
>>> It's identifying the actual, demonstrable pain points and proposing
>>> targeted changes to address them.
>> Really great proposal! As a non-member, I can see the value for the
>> community at large.
>>
>> Just one thing: Not only the number of posts on the ML should give
>> legitimation to vote, but also contributions to the repo.
>>
>> Regards,
>> Niels
>
> That's also a possibility. Our assumption was that someone who is contributing directly to a working group is going to be active on the list anyway, so would be caught by the same filter.
>
> To respond to both you and Dracony here, Michael and I went back and forth a couple of times on how to define "active and engaged" members of the broader community. We do feel it is important to have a broader base of support for the CC, to give non-project-affiliated people a voice and to help show FIG as involved in the whole community. However, that can certainly go too far; just throwing up a Twitter poll or Reddit thread for anyone in the world (who may not even have touched PHP in their lives) is not viable, even if it were remotely manageable to run such an election. However, at the other extreme "well everyone knows Cal, so we'll just go with him" isn't really a viable approach either. :-) (No offense, Cal.) We need some middle-ground.
>
> The idea here is that if someone has posted at least 5 times, they're probably at least reasonably informed and engaged. Not perfectly, perhaps, but at least well-enough. I'm flexible on the exact number, and open to suggestions for other filtering mechanisms that achieve the same goals above.
regards,
Lukas
Korvin Szanto
Apr 27, 2016, 3:19:36 PM4/27/16
to php...@googlegroups.com
Hi Lukas,
I'd definitely recommend setting aside the time to read the proposal and all of the details. I agree that the 5 message rule is a bit arbitrary, but these are still going to be organic processes run by people not by a machine. So as long as we are not just blindly voting people in because of their message count, it really shouldn't matter at all.
I'd be sad if someone who is super bright shows up on the list and has all of the qualifications but doesn't get to run because of some extra high barrier of entry we added to stop purported issues of "too much activity".
... right now we suffer a lot from people drowning this list as it would be a chat room. This is one of the main reasons why I have become less active.
This sounds like a reply for the thread proposing we switch to a forum.
Thanks!
Korvin
regards,
Lukas
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/C9D464E7-3343-42AF-9280-99D69272D3D0%40pooteeweet.org.
Dracony
Apr 29, 2016, 6:27:30 PM4/29/16
to PHP Framework Interoperability Group
I read through the proposal and I think we should go with it, but maybe set aside some time for refactoring in the future if it is accepted. E.g. try it out and then finalize the rules after we get some feedback. Especially for things like the t message rule, etc
Larry Garfield
Apr 29, 2016, 7:58:19 PM4/29/16
to php...@googlegroups.com
On 04/29/2016 05:27 PM, Dracony wrote:
> I read through the proposal and I think we should go with it, but maybe set aside some time for refactoring in the future if it is accepted. E.g. try it out and then finalize the rules after we get some feedback. Especially for things like the t message rule, etc
T message rule?
> I read through the proposal and I think we should go with it, but maybe set aside some time for refactoring in the future if it is accepted. E.g. try it out and then finalize the rules after we get some feedback. Especially for things like the t message rule, etc
(Any bylaws are always subject to tweaking over time, just as this is a
particularly large tweak of our current bylaws.)
--Larry Garfield
Michael Cullum
Apr 30, 2016, 6:28:29 AM4/30/16
to FIG, PHP
Larry, As 5 is above t I assume he meant the 5 message rule for community members voting in elections.
Dracony, I'd say that's something we could do sure, but I'd be wary about dwelling too much on structure and bylaw changes and discussions in the future. The idea of this is to shift discussions towards the actual specifications themselves but of course if something isn't working how we want it to, we can fix that.
--
Michael C
--
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.
To view this discussion on the web visit