Zitat von Paul Jones <pmjone...@gmail.com>:
Dear Voting Members,
There is another way to solve the problems listed in the [FIG 3.0
summary][1]: formally encourage the creation of a *-interop project
as a prerequisite to a FIG entrance vote. (Look to container-interop
and async-interop as examples.)
IMO the WGs are the formal creation of what used to be interop
projects. Lessons learned from these projects have sure been taking
into account when creating the ideas of working groups. At least
that's my personal impression.
* * *
Point by point from the FIG 3.0 tl;dr:
Everyone has equal say on FIG PSRs, no matter their expertise or
their project’s relevance in the PSR’s problem space
A *-interop project concentrates on its particular problem, and can
invite (or draw the attention of) those who have relevant expertise.
Both container-interop and async-interop were able to this
successfully.
There are lots of clever awesome people involved in the FIG who are
not project representatives
A *-interop project need not be limited to only project
representatives. It can accept (or refuse) anyone it wants.
Member projects find it difficult to engage in everything going on
in the FIG
Interested parties can enagage in as many, or as few, *-interop
projects as they like.
There is an ongoing question if the FIG produces PSRs for member
projects or for the wider community; especially when the wider
community pays it so much attention due to its de-facto status as
‘the php standards body’.
Each *-interop project can define for itself the audience it addresses.
Besides that latter, all this applies to the FIG 3.0 WGs too. And I
don't think that each group should define its own audience. For
consistency and relevance reasons, this should be defined by the FIG
as a whole. If a WG considers the audience too narrow for their
purposes, they can start a discussion to broaden the audience on the
FIG level.
* * *
This has several advantages over the FIG 3.0 approach.
- fewer rules changes (perhaps only one!)
This is not necessarily an advantage on its own.
- less bureaucracy
While I consider this generally a good idea, I would also say that
more rules make some discussions less necessary. Or even meaningful.
Also, for a standardization entity, a very formal approach is making
the outcome more transparent and confident.
- less centralization
This is also achieved by the FIG 3.0 proposal.
- reduced hierarchy
Didn't work in the past where the whole FIG body discussed and decided
everything. I suggest we see more hierarchy as distributed
responsibility instead.
- fewer committees
See above.
- more flexibility
Not necessarily a good goal for a standardization body.
- greater openness
I don't see this.
Each *-interop gets to operate in the way it likes, according to its
own project members.
Again, not necessarily good in standardization processes. Who trusts a
standardization group if the groups processes aren't standardized too?
Each *-interop can work through its ideas among a smaller set of
interested participants, perhaps with implementation trials, without
having the pressure of "being a standard" from the outset.
Once a *-interop project feels it has solved its particular problem,
it can petition for FIG entrance under current FIG bylaws.
Like the WG.
If there is more than one *-interop groups tackling the same problem
in different ways, FIG can pick from the different groups, or ask
that they merge their efforts before entrance.
This shouldn't even happen right from the start. That's why the CC is
a good idea.
FIG can also see how broadly the work of *-interop group has been
accepted, providing real-world information as to the value of the
work before the entrance vote.
* * *
Please consider this the opening of the 2-week discussion that
occurs prior to a vote; of course, it may go on longer than that.
[1]: https://medium.com/@michaelcullumuk/fig-3-0-91dbfd21c93b#.4fhp3srq0
--
Paul M. Jones
http://paul-m-jones.com
--
Jan Schneider
The Horde Project
http://www.horde.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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/20160809080550.Horde.9sAhhSqf3Qh0QSo_kW5u7qU%40neo.wg.de.
For more options, visit https://groups.google.com/d/optout.
