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