Groups keyboard shortcuts have been updated
Dismiss
See shortcuts
[Proposal] FIG 3.0
2,066 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 https://groups.google.com/d/msgid/php-fig/5723F514.3030206%40garfieldtech.com.
Roman Tsjupa
Apr 30, 2016, 7:28:00 AM4/30/16
to PHP FIG
Cool then ) lets get this show on the road)
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/h3wrQePdzfc/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAAqcDMg-baLd%2BQg4L03ZikX6VJcCXVwGtP0CJEZTzkxjMSM%3DWg%40mail.gmail.com.
Adam Culp
May 13, 2016, 11:42:52 AM5/13/16
to PHP Framework Interoperability Group
Thanks to Michael and Larry for putting together such a comprehensive document. (FIG 3.0 doc) I think it was well thought out, and will help carry "some" organization into the future. However, I do not feel it should be the PHP-FIG.
Many speak in favor of some sort of body to define standards to be used by the PHP ecosystem at large. And many recent PSRs are indicative of this desire. But this is not, and has never been, the PHP-Fig. (See current FAQs on the goals and purpose of the PHP-FIG athttp://www.php-fig.org/faqs/) Those FAQs are very clear on the purpose and mission of the FIG. To quote: "The idea behind the group is for project representatives to talk about the commonalities between our projects and find ways we can work together." Then it goes on to describe how the rest of the PHP ecosystem is free to use these standards if they choose.
The PHP-FIG doesn't need to change in scope to serve it's important mission, and should continue to do what the group was intended to do.
Now, don't get me wrong...I think some additional tweaking to the group can, and should, happen. But at it's core it should still retain it's original mission.
I am against opening the group up as many have urged. Opening the group will add conflict, politics, and never ending arguments. (Which we have enough of already, due to the emotions behind what we do.)
Let there be a new body created, separated from the FIG, and let them do as they wish. If they adopt PSRs created by the FIG, so be it. If the FIG finds some things in this new org that meet with their mission, so be it.
However, and this is important, this new body should work WITH the FIG. Not above it and not as a subordinate. But hand-in-hand to create standards that work both for the projects AND for the community.
But please, let's not confuse and convolute the important work done by the FIG. Take the arguments of "tabs versus spaces" elsewhere and let the very busy framework and library maintainers continue striving to create consistent standards for themselves.
If 2 of them happen to be project reps, that's OK. We divorce those
Dracony
May 13, 2016, 4:59:49 PM5/13/16
to PHP Framework Interoperability Group
On the flip side: there are so many people complaining that FIG is not open enough, yet the actual amount of random community people that come here with their ideas is miniscule. It's not like the FIG gets dozens of ideas and propasals and rejects them with an elitis remark. What kind of openness does the community expect then? A weekly reddit post like "What should we name a method that checks if the cache item is hit or not?". We even have projects that went through the application saying they are really interested in the FIG and then kept in silence afterwards, the community as a whole has actually even less incentive to participate. And it has incentive, where was it until now?
the only counterexample to what I'm saying that I can give is the PSR propasal for a dependency container. That interface and the ideas behind it matured separately and were introduced here later. Isn't that how the whole system should work? But again, it's not like those ideas are coming every day, or every month even.
Larry Garfield
May 15, 2016, 9:19:40 PM5/15/16
to php...@googlegroups.com
I'm going to respond to Adam in
particular as his message below is particularly calm and
considered, but this is more of a general reply to a number of
comments both on the list and elsewhere of late. Please take
note. :-)
A common criticism of FIG doing anything more than "just us" is scope creep. It's not what FIG is "supposed" to do. It's "just for frameworks" (whatever that means). Let "someone else" deal with "the community," we'll just deal with "us" here in the corner, independent of the community.
This is not an argument I have ever found persuasive, and in particular Adam's suggestion (which has been made by others in the past as well) that there should be some other organization that is basically FIG 3.0 and "works with FIG" I find quite bizarre.
First, FIG hasn't been "just frameworks" since late 2009, when projects such as Drupal and Joomla were first admitted. (Drupal's status as a framework is debatable, rather by design, and Joomla at the time was purely a CMS, before the Joomla Framework reorganization happened.) Of our current membership (as defined on the website as of when I write this, which may not be perfectly accurate given recent events), I would break down the member projects to:
Library: 6
Framework: 14
Application: 20
That is, *half* the member projects are applications, not frameworks, and a significant percentage of the rest are stand-alone libraries, not frameworks. Including IBMi Toolkit, the project Adam represents.
So if FIG is really "just for the frameworks", we need to kick out half of the membership, including the projects represented by both Adam and myself.
Second, you may come up with different numbers if you divide "framework", "application", and "library" differently than I did. That's because those lines are horribly fuzzy. What does "framework" mean? That's a rhetorical question, don't answer, but your temptation to try and argue a particular definition is the point: The distinction between "framework" and "not a framework" is, in 2016 PHP, not a meaningful one. For instance, Aura and the League are both "a collection of independent packages with common branding", and so is Symfony for that matter, and Zend is moving that direction; some of them then have additional glue-libraries that bring them together into an opinionated template, others don't. So which of those are frameworks? ¯\_(ツ)_/¯
In short, the word "Framework" in our name is vestigial and has been for many years now.
Third, the "frameworks only" approach is, although I am sure unintentionally so, very elitist. FIG is only for "real frameworks", not for people who write code "without a framework" (whatever that means, as above.) The framework world vs. other dichotomy is a false one, and an increasingly false one every year as Composer, Symfony Components, Zend 3, and so forth continue to make code sharing and collaboration easier. FIG has even helped to encourage that transition, which is very much to FIG's credit. Go us.
But that elitism has cost. It actively de-voices some extremely smart people that would have a great deal of value to add, but are not affiliated with a project. It's telling Davey Shaffik, Liz Smith, Anthony Ferrara, and Sara Golemon (just to name a few examples of scarily-smart well-respected PHP community leaders off the top of my head) that we don't want their input. That's incredibly short-sighted.
Fourth, the implication is that somehow there are standards that are only relevant to "real frameworks" and not to "the PHP coding world", and vice versa. That the non-framework world should go elsewhere and make its own standards body, and "let the very busy framework and library maintainers continue striving to create consistent standards for themselves", because somehow by implication those standards are "not for you mere non-framework people." "Those people" can do their own standards for them.
I cannot begin to process how that distinction even makes sense, given the previous points. What is a "framework-relevant-only spec"? Do we even HAVE any? I don't think we do. What would be a "non-framework-only spec"? Do we even HAVE any? I don't think we do.
Is PSR-2 somehow only relevant to "real frameworks"? Or only relevant to non-frameworks? Do only "real frameworks" benefit from PSR-4? Do only non-frameworks benefit from PSR-4? No, seriously, I don't know how to respond to this point because it simply makes no sense to me whatsoever. "Framework-relevant-only specs" are not even a thing.
Fifth, the suggestion that "opening the group will add conflict, politics, and never ending arguments" I find particularly confusing. This mailing list is already public and open to all ~3 billion people with Internet access. I don't know how it could get more open, despite only a few dozen people ever posting over the course of a year. And, um, yes, we have conflict, politics, and never ending arguments. :-)
If anything, FIG 3.0 proposes closing the group, ever so slightly, in that most decisions of significance become the purview of a dedicated group of 12 people that have an explicit expectation of paying attention and doing their research rather than an ad hoc group of 40 people who occasionally notice something is happening that requires more thought than dashing off a drama comment. (Not to put too fine a point on it...) Clearly that group would need to give due consideration to any valid points raised by anyone who makes them... but that's already the case for FIG today. There's no explicit requirement we listen to everyone who posts on the list, but there's an informal expectation that reasonable people probably should. That doesn't change in any way.
Unless by "opening up the group" Adam means allowing non-project-leads to vote on that group of stewards. (Hm, hey, maybe that's a better name for them?) I really don't see how increasing the voting pool will "add conflict, politics, and never ending arguments" above what FIG already has today. Moreover, to be entirely frank, I highly doubt that more than 10-20 non-project-reps will even quality to vote, much less do so, so we're hardly talking about a flood of thousands of people. Recall: all of those thousands of great unwashed masses are already welcome on the mailing list, today, and only 10-20 of them post even one anyway.
Sixth, let's suppose that, despite all of that, a second Not-Frameworks Interoperability Group were setup, using the FIG 3.0 proposal as its model. That would accomplish... what? Adam suggests "this new body should work WITH the FIG. Not above it and not as a subordinate. But hand-in-hand to create standards that work both for the projects AND for the community." How in the world does that reduce politics and process in any way shape or form? What value does that add, for "projects" OR "the community"? How does having two independent organizations that are supposed to talk to each other and coordinate as if they were a single organization accomplish anything? The only end-game I can see there is either both orgs effectively operating like a bicameral legislature with inter-group coordination meetings to normalize differences between the House and Senate versions of a bill (and this is supposed to reduce process and politics?) or both orgs ignoring each other entirely and PHP having two competing, non-collaborating groups that both preach collaboration. That... seems counter-productive.
Or the new org effectively takes over, and FIG fades out and becomes vestigial and useless. Same net effect as FIG just accepting its role as caring about more than just "frameworks", but much messier and with more confusion and political maneuvering. I don't see that as a win, either.
If it's just so that those that don't want to have to think about "other" projects (ie, non-members) don't have to... those individuals are welcome to not run for the Core Committee. If anything, it means that a project representative can, and should, speak from a bias of their own organization.
Seventh, the general Zeitgeist of the PHP community that I see, and the Reddit thread from Paul Jones back in January supported, is that whether we want it to be or not, FIG is already seen as the PHP community standards body, just a badly organized one. In short, we lost that vote. For FIG to double-down on "no, really, just for us" would be spitting in the wind. An organization such as this, in fact, *cannot* be for "just one part of the community", because the framework/other line is so blurry as to be non-existent. Once the "projects" and "frameworks" adopt something, it becomes really hard for random Joe project or developer to not be impacted by it.
It's the same argument often used with regards to PHP language syntax; even if you don't use a particular feature yourself, if you regularly work with anyone else's code you're going to run into it sooner or later. The same logic applies to PSRs: Using composer and not being aware of/affected by PSR-4 is pretty damned hard.
Even if FIG were to write a mission statement (we currently do not have one, just a defensive FAQ which is not the same thing) that said "we only care about big frameworks" (whatever that means), that doesn't change the fact that our work does have impact beyond just member projects. If anything, it would be declaring "we know that what we do will have impact on others, but we don't care about you at all so if it accidentally makes life harder for you, sucks to be you." That "not my problem" attitude will do nothing to improve FIG's image or efficiency, nor will it do anything to help interoperability and collaboration.
In essence, it sounds like as a practical matter there are two possible courses of action:
1) FIG accepts its role as a PHP institution working for the betterment of interoperability in the PHP community, not just "real projects", and moves forward with a new model better suited to that reality.
2) Some new organization forms with mostly the same people, with FIG's blessing, that takes over that role and FIG itself becomes vestigial, withers, and dies off. However, there's a lot of confusion, mess, miscommunication, and moral panic in the meantime, primarily so that a few people can go down with the "just for we real frameworks" ship.
I find no compelling reason that we should fall on our sword and do a worse job of supporting collaboration and interoperability just to make a statement.
--Larry Garfield
A common criticism of FIG doing anything more than "just us" is scope creep. It's not what FIG is "supposed" to do. It's "just for frameworks" (whatever that means). Let "someone else" deal with "the community," we'll just deal with "us" here in the corner, independent of the community.
This is not an argument I have ever found persuasive, and in particular Adam's suggestion (which has been made by others in the past as well) that there should be some other organization that is basically FIG 3.0 and "works with FIG" I find quite bizarre.
First, FIG hasn't been "just frameworks" since late 2009, when projects such as Drupal and Joomla were first admitted. (Drupal's status as a framework is debatable, rather by design, and Joomla at the time was purely a CMS, before the Joomla Framework reorganization happened.) Of our current membership (as defined on the website as of when I write this, which may not be perfectly accurate given recent events), I would break down the member projects to:
Library: 6
Framework: 14
Application: 20
That is, *half* the member projects are applications, not frameworks, and a significant percentage of the rest are stand-alone libraries, not frameworks. Including IBMi Toolkit, the project Adam represents.
So if FIG is really "just for the frameworks", we need to kick out half of the membership, including the projects represented by both Adam and myself.
Second, you may come up with different numbers if you divide "framework", "application", and "library" differently than I did. That's because those lines are horribly fuzzy. What does "framework" mean? That's a rhetorical question, don't answer, but your temptation to try and argue a particular definition is the point: The distinction between "framework" and "not a framework" is, in 2016 PHP, not a meaningful one. For instance, Aura and the League are both "a collection of independent packages with common branding", and so is Symfony for that matter, and Zend is moving that direction; some of them then have additional glue-libraries that bring them together into an opinionated template, others don't. So which of those are frameworks? ¯\_(ツ)_/¯
In short, the word "Framework" in our name is vestigial and has been for many years now.
Third, the "frameworks only" approach is, although I am sure unintentionally so, very elitist. FIG is only for "real frameworks", not for people who write code "without a framework" (whatever that means, as above.) The framework world vs. other dichotomy is a false one, and an increasingly false one every year as Composer, Symfony Components, Zend 3, and so forth continue to make code sharing and collaboration easier. FIG has even helped to encourage that transition, which is very much to FIG's credit. Go us.
But that elitism has cost. It actively de-voices some extremely smart people that would have a great deal of value to add, but are not affiliated with a project. It's telling Davey Shaffik, Liz Smith, Anthony Ferrara, and Sara Golemon (just to name a few examples of scarily-smart well-respected PHP community leaders off the top of my head) that we don't want their input. That's incredibly short-sighted.
Fourth, the implication is that somehow there are standards that are only relevant to "real frameworks" and not to "the PHP coding world", and vice versa. That the non-framework world should go elsewhere and make its own standards body, and "let the very busy framework and library maintainers continue striving to create consistent standards for themselves", because somehow by implication those standards are "not for you mere non-framework people." "Those people" can do their own standards for them.
I cannot begin to process how that distinction even makes sense, given the previous points. What is a "framework-relevant-only spec"? Do we even HAVE any? I don't think we do. What would be a "non-framework-only spec"? Do we even HAVE any? I don't think we do.
Is PSR-2 somehow only relevant to "real frameworks"? Or only relevant to non-frameworks? Do only "real frameworks" benefit from PSR-4? Do only non-frameworks benefit from PSR-4? No, seriously, I don't know how to respond to this point because it simply makes no sense to me whatsoever. "Framework-relevant-only specs" are not even a thing.
Fifth, the suggestion that "opening the group will add conflict, politics, and never ending arguments" I find particularly confusing. This mailing list is already public and open to all ~3 billion people with Internet access. I don't know how it could get more open, despite only a few dozen people ever posting over the course of a year. And, um, yes, we have conflict, politics, and never ending arguments. :-)
If anything, FIG 3.0 proposes closing the group, ever so slightly, in that most decisions of significance become the purview of a dedicated group of 12 people that have an explicit expectation of paying attention and doing their research rather than an ad hoc group of 40 people who occasionally notice something is happening that requires more thought than dashing off a drama comment. (Not to put too fine a point on it...) Clearly that group would need to give due consideration to any valid points raised by anyone who makes them... but that's already the case for FIG today. There's no explicit requirement we listen to everyone who posts on the list, but there's an informal expectation that reasonable people probably should. That doesn't change in any way.
Unless by "opening up the group" Adam means allowing non-project-leads to vote on that group of stewards. (Hm, hey, maybe that's a better name for them?) I really don't see how increasing the voting pool will "add conflict, politics, and never ending arguments" above what FIG already has today. Moreover, to be entirely frank, I highly doubt that more than 10-20 non-project-reps will even quality to vote, much less do so, so we're hardly talking about a flood of thousands of people. Recall: all of those thousands of great unwashed masses are already welcome on the mailing list, today, and only 10-20 of them post even one anyway.
Sixth, let's suppose that, despite all of that, a second Not-Frameworks Interoperability Group were setup, using the FIG 3.0 proposal as its model. That would accomplish... what? Adam suggests "this new body should work WITH the FIG. Not above it and not as a subordinate. But hand-in-hand to create standards that work both for the projects AND for the community." How in the world does that reduce politics and process in any way shape or form? What value does that add, for "projects" OR "the community"? How does having two independent organizations that are supposed to talk to each other and coordinate as if they were a single organization accomplish anything? The only end-game I can see there is either both orgs effectively operating like a bicameral legislature with inter-group coordination meetings to normalize differences between the House and Senate versions of a bill (and this is supposed to reduce process and politics?) or both orgs ignoring each other entirely and PHP having two competing, non-collaborating groups that both preach collaboration. That... seems counter-productive.
Or the new org effectively takes over, and FIG fades out and becomes vestigial and useless. Same net effect as FIG just accepting its role as caring about more than just "frameworks", but much messier and with more confusion and political maneuvering. I don't see that as a win, either.
If it's just so that those that don't want to have to think about "other" projects (ie, non-members) don't have to... those individuals are welcome to not run for the Core Committee. If anything, it means that a project representative can, and should, speak from a bias of their own organization.
Seventh, the general Zeitgeist of the PHP community that I see, and the Reddit thread from Paul Jones back in January supported, is that whether we want it to be or not, FIG is already seen as the PHP community standards body, just a badly organized one. In short, we lost that vote. For FIG to double-down on "no, really, just for us" would be spitting in the wind. An organization such as this, in fact, *cannot* be for "just one part of the community", because the framework/other line is so blurry as to be non-existent. Once the "projects" and "frameworks" adopt something, it becomes really hard for random Joe project or developer to not be impacted by it.
It's the same argument often used with regards to PHP language syntax; even if you don't use a particular feature yourself, if you regularly work with anyone else's code you're going to run into it sooner or later. The same logic applies to PSRs: Using composer and not being aware of/affected by PSR-4 is pretty damned hard.
Even if FIG were to write a mission statement (we currently do not have one, just a defensive FAQ which is not the same thing) that said "we only care about big frameworks" (whatever that means), that doesn't change the fact that our work does have impact beyond just member projects. If anything, it would be declaring "we know that what we do will have impact on others, but we don't care about you at all so if it accidentally makes life harder for you, sucks to be you." That "not my problem" attitude will do nothing to improve FIG's image or efficiency, nor will it do anything to help interoperability and collaboration.
In essence, it sounds like as a practical matter there are two possible courses of action:
1) FIG accepts its role as a PHP institution working for the betterment of interoperability in the PHP community, not just "real projects", and moves forward with a new model better suited to that reality.
2) Some new organization forms with mostly the same people, with FIG's blessing, that takes over that role and FIG itself becomes vestigial, withers, and dies off. However, there's a lot of confusion, mess, miscommunication, and moral panic in the meantime, primarily so that a few people can go down with the "just for we real frameworks" ship.
I find no compelling reason that we should fall on our sword and do a worse job of supporting collaboration and interoperability just to make a statement.
--Larry Garfield
Adam Culp
May 16, 2016, 11:27:20 AM5/16/16
to PHP Framework Interoperability Group
Thank you for the thoughtful response Larry. I will have another detailed look at the proposal. Perhaps I'm missing something.
Chuck Burgess
May 17, 2016, 8:14:58 AM5/17/16
to php...@googlegroups.com
PEAR is +1 good on this reorg format.
Two side points:
* I think Larry did stumble into a good name for the core group -- the Stewardship Committee.
* since acronym'ing tends to allow for articles and conjunctions to not be explicit in the acronym, perhaps a change of "Framework Interoperability Group" to "Framework & Interoperability Group" would better reflect the mission and constituency, without incurring any *significant* rebranding requirements.
CRB
--
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/f64523c6-c944-48d8-8c01-a2c2b05a12ad%40googlegroups.com.
Damian Mooyman
May 19, 2016, 8:24:58 PM5/19/16
to PHP Framework Interoperability Group
+1 from SilverStripe . Good job Larry!
Daniel Hunsaker
Jul 26, 2016, 10:53:55 PM7/26/16
to PHP Framework Interoperability Group, Demon...@gmail.com
On Tuesday, May 17, 2016 at 6:14:58 AM UTC-6, Chuck Burgess wrote:
PEAR is +1 good on this reorg format.
Two side points:
* I think Larry did stumble into a good name for the core group -- the Stewardship Committee.
* since acronym'ing tends to allow for articles and conjunctions to not be explicit in the acronym, perhaps a change of "Framework Interoperability Group" to "Framework & Interoperability Group" would better reflect the mission and constituency, without incurring any *significant* rebranding requirements.
+1 from non-project dev (I'm arguably one of the most-active devs on PHP-Resque, but that's not a member project, so doesn't qualify)
Also, +1 each on both side points above.
Also, +1 each on both side points above.
- Daniel Hunsaker
Reply all
Reply to author
Forward
0 new messages