I actually see little in the suggestion below that isn't already
implicit in FIG 3. *-interop is, really, just the Working Groups. If
people want to work informally on something before coming to FIG to form
a WG, we certainly can't stop them. If they'd rather form a formal WG
early on for better visibility, I'm good with that too.
All the proposal below is saying is "please talk a lot informally before
you come to us". Which, while a nice thought and one that I do not
oppose, doesn't address the structural issues that FIG has at all.
--Larry Garfield
On 08/08/2016 10:58 AM, Alessandro Lai wrote:
This is a really nice proposal.
I also think that this does not solve anyway the issues of the FIG
itself; maybe the best option could be to push for both approaches?
Nothing in the FIG 3.0 proposal forbids that!
In fact, I think that the FIG 3.0 modification are good anyway, and
that the *-interop groups can still be formed and promoted, even
outside of the FIG reach; then, each *-interop can choose to "be
embraced" by the FIG, where the work (which is already done) can be
formalized as a PSR, with little work and two simple votings.
What do you think?
Il giorno lunedì 8 agosto 2016 15:57:39 UTC+2, pmjones ha scritto:
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.)
* * *
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.
* * *
This has several advantages over the FIG 3.0 approach.
- fewer rules changes (perhaps only one!)
- less bureaucracy
- less centralization
- reduced hierarchy
- fewer committees
- more flexibility
- greater openness
Each *-interop gets to operate in the way it likes, according to
its own project members.
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.
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.
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
<https://medium.com/@michaelcullumuk/fig-3-0-91dbfd21c93b#.4fhp3srq0>
--
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 [email protected]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/b14f9c91-265b-4606-80c0-fdbfcbf37169%40googlegroups.com
<https://groups.google.com/d/msgid/php-fig/b14f9c91-265b-4606-80c0-fdbfcbf37169%40googlegroups.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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/46fe7ecd-6024-a748-d102-5977caf6da4c%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
