Structure and purpose

[Larry Garfield]

There's a couple of related topics being discussed in a few separate
threads right now. Although they're in different threads, I believe the
voter turnout question, the mission statement question, the community
involvement question, and a few long-standing issues are all
inter-related. I will therefore attempt to address all of them in a
single (hopefully) coherent statement. Knowing me this will be long, so
grab some coffee. :-)

Problem 1: Voter turnout from voting representatives is embarrassingly
low. That has the potential to undermine FIG's work, as well as the
legitimacy of FIG's work in the broader community.

Problem 2: Who is FIG's target audience? Member projects? The PHP
community at large? PHP projects that want to interface with member
projects? There are inconsistent answers to this question.

Problem 3: How DO we want people other than FIG voting reps to be
involved in FIG? Or do we?

Problem 4: What projects should or should not be FIG members?

The status quo
=========

First off, to make sure we're all on the same page, as of today (and for
the past few years) FIG is, officially on paper, a consortium of
*projects*. I often equate it the United Nations of PHP. We voting
representatives are ambassadors of our respective projects, here to pass
non-binding resolutions that member projects may or may not ignore.
(Just like the UN...) We are not individuals, we are ambassadors of
projects, only. In some cases the ambassador of a project is also the
head of state; in some cases the ambassador is just a proxy for a core
team that takes their own vote; in some cases the ambassador has
basically free-reign from his/her project. That's up to each project to
determine.

Whatever we want FIG to be, whatever it once was, whatever it has the
potential to be, whatever some wish it were, that is, on paper, what FIG
is today.

That structure also does call into question the "community
representative" role, as it's essentially the "Other" project.

Membership
========

Because we never took the time to define qualifications for membership,
or expectations of membership (other than "don't be a jerk"), FIG
membership has come to be seen as mark of legitimacy. That is, most
people, including us (and including me), make one of the following errors:

1) "I want my project to be a member of FIG because that means it's an
official big-boy project."

2) "We should have project X as a member because project X has insight
to offer", although we never define what insight that is. (Guilty!)

3) "I want to be a member of FIG because I have insights to offer."

That is, we've conflated membership and participation. We're all guilty
of this. That is, I think, a key part of our voter turnout issue and
simply trying to coerce more people to vote is not going to solve the
root issue: What does membership even mean?

Our current standard of membership is, effectively, "people don't
dislike you/your project enough to feel bad for saying no." That is, to
be blunt, an abdication on our part to build an important part of this
group's definition. It is a problem, which is also a direct cause for
our low voter turnout. Yet I think we're afraid to define a metric for
fear that some, perhaps many, current projects wouldn't qualify for it
and grandfathering them all would undermine any changes we make.

Take, as an example, the recent async proposals. Until very recently,
the only member project that had anything to do with async was Guzzle.
So for "us", collectively, async doesn't matter at all and we shouldn't
be interested. Drupal, Symfony, Zend, Stash, Composer, none of them do
anything with async, so have no experience to offer, and are unlikely to
be doing anything with async in the near future. Which means... what do
we have to do with it?

If were were to JUST vote on behalf of our projects, then pretty much
all of us except Guzzle would be voting+0 if at all since it doesn't
affect us. At which point the Promise, Event Loop, etc. proposals would
never pass an entrance vote, or if they did it would be with one +1 and
15 +0s, which would technically pass but I think we'd all think
something fishy was going on. :-)

Yet we actively invited certain projects to join, specifically for these
specs, because we wanted their input. Which directly undermines our
repeated statement that you don't need to be a voting member to be
involved in FIG! We're being rather hypocritical on this front, and I
don't exclude myself from that statement.

There has been much discussion in IRC of late about the "cost" of
membership, which is basically zero. That's part of the problem, and
encourages "I care about PHP so I want to be a member" and "I implement
a bunch of PSRs, so I should be a member". There's nowhere we ask, of
projects, "ask not what FIG can do for you but what you can do for
FIG." In a large part that's because we don't want to require projects
to implement PSRs (because we know full well many will balk at doing so,
and rightly so), but it means we have a gap that is not filled by
anything. the cost/reward for projects to join FIG is all askew, which
is also why we have low turnout. We don't, as Paul Jones likes to put
it, "have skin in the game".

As an aside, this is one reason I didn't get around to voting on
phpSpec's application. I am in the process of re-evaluating my criteria
for when I would support a new member, and I'm not sure yet what
standard I would apply. I'd prefer to have that be an explicit
discussion, and for us to, yes, establish some common semi-objective
criteria that goes beyond "we don't hate you yet".

There are some that argue for "the person has shown they will contribute
to FIG", which while a laudable criteria... misses the point. Because
we are supposed to be voting on the *project*, not the person. So an
individual *person* being active may or may not have anything to do with
the value the *project* brings to the table, and vice versa. This split
personality disorder we have is not sustainable.

History
=====

As others have noted, FIG's origin story is rather controversial. Its
initial launch as the PHP Standards Group generated a lot of backlash,
which mostly boiled down to "Who the f* are you to declare standards
that I'm supposed to use? GTFO!" I was one of those people saying that,
in fact. :-) I believe most, although probably not all, of the "just
for us, please ignore us if you want" attitude that some have is
left-over from that whole affair. It's a way to deflect criticism
(whether legitimate or not).

(Fun fact, if you check the ancient FIG archives you'll find a brief
discussion about adding new members, which included "what about that
Larry guy from Drupal? He seemed involved" followed by "Ugh, that jerk".
<g> I don't rightly recall who said the latter, and I've not gone back
to refresh my memory in the interests of peaceful coexistence.)

Perception is everything
===============

Be that as it may, that was six and a half years ago. FIG has changed a
lot since then, as has its relationship with the community. I believe
Anthony is very correct on this point: Whether it was intended or not,
whether we want it to be or not, FIG is effectively the PHP Standards
Group. We don't need another standards body; despite the name, FIG is
it. I know there are some that don't like that and are still in denial
about it, but we don't get to vote on that.

PSR-2 may have been "just for us", and I've made no secret of my dislike
for some portions of it, but it *is* the coding standard of PHP now,
whether members or not, and has been since IDEs started offering it as a
preset. PSR-7 may have been "just for us", but it is rapidly becoming
the way future PHP projects will deal with HTTP handling, whether
members or not. PSR-3... honestly I don't know how we can pretend that
was "just for us", since it was made very clear during the discussion at
the time that the target audience was "libraries that need logging", the
vast majority of which are not us.

We do have a responsibility to the broader PHP community at this point.
We may or may not want it, but that is, to be frank, irrelevant. We
have it, whether we asked for it or not. We may have no "hard power"
ability to enforce a PSR on anyone, but we have a great deal of "soft
power" influence on the whole ecosystem, which we should use wisely.

Does that itself necessitate some massive change in FIG's structure?
Not on its own, necessarily. It does necessitate a small change in our
own behavior, though: Quite simply, any time you say "it's just for
member projects, everyone else can ignore it if they want so we
shouldn't care about them"... you're wrong. You're harming FIG, and
you're harming PHP. Please stop.

Relationship to the community
==================

This ties into several of the previous points. Just what is FIG's
relationship with non-voting-rep PHP developers? To what extent should
we be reaching out to them deliberately? Again, we've been extremely
inconsistent on this front, to the point of incoherence.

1) Do we want people to get involved individually, reviewing PSR or as
the editor of a PSR?

2) Do we want people to pipe down, instead contributing through their
voting reps?

These are mutually exclusive positions, yet I've seen both stated even
just in the last few days. Every time we tell someone they should talk
to Cal on behalf of the community, we're telling them they shouldn't
engage directly. The subtly in "talk on your own, but talk to your
voting rep on the side about voting" is, I fear, lost on the Interwebs,
especially when that's not how we say it explicitly. This mixed
messaging is problematic and off-putting.

At the same time, which community do we mean? We speak as if there's a
single entity called the PHP community. That's not true. 5 years ago I
would have said that's not even remotely true. The Renaissance of the
past few years and the intensely hard work by many many people have
managed to remove the "remotely" from that sentence, but PHP is still an
enormous ecosystem so we can't really speak of it as a single entity.

Which PHP community? Conference-goers? Reddit Regulars? The
Twitterati? The thousands of people on php-general still trying to
figure out how a for loop works? Facebookies? Internals devs? People
who forget that not everyone installs PECL modules? Those that don't
know what PECL is? The hundreds of thousands of outsourcing consultants
in the US and Europe that clock in, spew some code, and go home? The
hundreds of thousands of outsourcing consultants in India or Southeast
Asia that clock in, spew some code, and go home?

And that's not even getting into project affiliations, who are probably,
in the broad scheme of PHP, a minority. (Meaning Cal nominally
represents likely 1000x as many people as the rest of us do. Some of us
represent a development team of 2-3, or perhaps even 1 for some libraries.)

If even 0.000001% of the entire PHP ecosystem joined this list, we'd
probably melt the server. It is, simply, impossible for all of them to
have a direct voice, and I'd wager that the majority of them don't care
to. Yet far more than that will be impacted by our work, long-term.

Side note: That should be an unsettling thought. If it's not, you
haven't been paying attention. :-)

So while promoting FIG's work in other venues sounds good, and is
probably a good idea... what's the goal? To get more people to know
about FIG? To get more people on the list, by which I mean warm
bodies? To get more people with "skin in the game" (whatever that
means) on the list? To get more people talking to "their" FIG reps
outside of FIG? What is the problem we're trying to solve?

Quality vs. Quantity
============

This question overlaps with the "Relationship with the community" topic,
and the "Membership" question. And it comes down to this very
important, but not always comfortable, statement: Not all contributions
or contributors are equally useful. Cf,

http://www.garfieldtech.com/blog/experts-opinions

Part of what makes this question tricky is that it can also be highly
contextual. There are areas where I am very experienced, and frankly
people should listen to me. :-) Async is not one of those, so when it
comes down to it, Aaron or Chris's voice should be listened to far more
than mine on the "right" way to build an async event loop. In other
areas, it's the other way around.

Does that mean only people above a certain threshold of experience or
cluefulness should be able to vote on a given topic? Or give input on
it? Or that we should somehow explicitly denote those who are topical
experts?

I'm not saying yes to any of those, just that they're fair, if
uncomfortable, questions.

By the same token, though, quantity of input does not guarantee quality
of output. In fact, it may reduce it. That's one reason I'm reticent
to put out a call for everyone in the world to come give input on
proposed PSRs. Adding 100 drive-by reviews of a PSR does not improve
it. If anything I'd say it's harmful if those drive-bys are unaware of
the context and background in question. If multiple non-expert people
are confused by a given point that is valuable input, but it only takes
a few people. In usability testing, diminishing returns start around
5-6 participants. Beyond that, you're not getting any new information.
We have 5-6 uninformed people on any topic we could consider, even just
amongst our own current voting members. :-)

Similarly, there is not a great deal of value to be found in repeating
the same feedback over and over. I'm sure Matthew can relate to this as
well; once a topic has been considered and chewed through and a
conclusion reached, there is little value in rehashing it again and
again and again. Sometimes something useful comes of it, if a new angle
can be brought forward that wasn't previously considered, but the same
raw opinion (not data, but opinion) adds only a little more value the
second time, barely any the third, and by the 5th none at all. At that
point, the quantity of feedback, if it is not of high quality, becomes
counter-productive.

How many of us have seen issues in our own projects stalled out not for
technical reasons but because a few loud voices simply shouted it down,
or worse, was derailed by someone coming in on step 15 of 20 to insist
on reopening step 3? I know I've seen that more times than I want to
remember in Drupal.

I know it's politically incorrect to discourage involvement, or to say
that someone's input is not valuable. You're not supposed to do that,
because "everyone has something to add" and all that. However, that
platitude is not actually true. And we implicitly admit that every time
we tell people to go through their voting reps (eg, Cal) rather than
speaking up on the list directly. In a sense, we push the task of
filtering the useful vs unuseful input to the voting reps off-channel. :-)

I don't have a specific action item for this section, other than
reminding everyone to not confuse quantity and quality. Sometimes a
small, uninterrupted group of experts or committed parties is far more
effective than a broad but shallow group. Depth over breadth.

Where do we go from here?
=================

All of that being said, and at great length... now what?

There are X things I would say we need to do, as a group, in order to
move forward, and as they're all inter-related this is not necessarily
in order:

1) Decide if the UN model really is the right way to organize FIG. On
paper we are. In practice, we're a sort of hybrid between that and "the
cool kids", which is part of the problem. If we want to be just "the
cool kids", that could be valid, but we'd need to define explicitly what
our definition of "cool kids" is, and it would need to NOT include "is
lead of a project that we think is cool by some unclear definition". Or
we could stay with the UN model, but be much clearer on it. The current
split-personality situation is, I believe, harmful. In either case, we
need to have an explicit, written set of criteria for membership that
goes beyond "well we don't hate you so meh".

2) Figure out explicitly, and document, what the benefits are of FIG
membership and the costs. Currently the only cost is "you vote
occasionally", which is too low. There needs to be some ongoing
responsibility and commitment that a project (or person, if we go that
route) makes to FIG's mission statement.

3) Figure out a proper mission statement, which acknowledges the role we
play in the broader PHP ecosystem beyond just the individuals and/or
projects listed on the web site.

4) Figure out a formal way that we want input from non-members (whatever
non-members means), and ensure that it's consistent and not double-speak.

I highly recommend we look into how other standards bodies are organized
for insight before we start brainstorming possible "costs" for
membership. It may even be advisable to get some formal consultation
services.

There is a very good chance that these steps will result in a number of
our current member projects no longer being eligible. It's
uncomfortable to acknowledge, especially when it could be you that may
end up disqualified, and not necessarily just on "size". However, I
think we need to bite that bullet. I've been down this road before,
when the Drupal Association transitioned from a working board to a
policy board and dropped a number of board members. We made sure it was
a graceful process and didn't come off as "kicking out" anyone, but it
did change the composition of the board, and as an organization we've
been far better for it.

For those who are still awake after reading all of that, I'm impressed.
:-) I firmly believe that we cannot look at these various questions in
isolation, which is why I've attempted to document how they all link
together. My hope is that it has made some semblance of sense.

--Larry Garfield

[Shefik]

Larry,

Thank you for taking the time to write this in such detail.

- Shefik

> --
> 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/566D0EE6.8010805%40garfieldtech.com.
> For more options, visit https://groups.google.com/d/optout.

[Jeremy Lindblom]

I agree with everything you just said.

--
Jeremy Lindblom - Guzzle Rep

[Christopher Pitt]

Hey Larry,

Thanks for taking the time to put this together. Just want to chime in regarding the "the value the *project* brings to the table" and where the async projects fit in. Async isn't a centrepiece of the PHP community, but it touches many aspects of the frameworks and "common code".

• Symfony ships a concurrent process library (Symfony\Process). A library Composer depends on.
  
• Laravel has one of the best deferred processing libraries out there (Illuminate\Queue).
  
• SilverStripe has another deferred processing, message queue based library, although it uses vastly different underpinnings to the Laravel implementation, and ships with a CMS interface.
  
• There is a long-running, open pull request to embed ReactPHP into Composer; to parallelise downloads.
  
• Guzzle (which you did mention) and AWS SDK have some of the best async APIs out there.
  
• Joomla has a deferred processing, message queue based library.
  

I could go on and on. The point I am trying to make here is that the PHP ecosystem is walking down a path that will lead to coexistence of sync and async architectures, as developers realise these are tools equally supported in PHP. And ReactPHP, AMPHP, and Icicle are at the forefront of this. They may not have been around since before Symfony, but I challenge you to ask "how to async in PHP?" on Reddit...

Let's not forget, we invited them to apply for membership. We invited them. We did so after I raised the topics of PSRs for Promises and Event Loops, and many people showed an interest in those.

Perhaps another example would be more fitting to describe what you are trying to describe. Let's not diminish the effort these projects have put into the PHP ecosystem, or cast aspersions on "the value the [they can bring] to the table". They have been doing it for years. We're only just noticing.

With the greatest of respect for you and your efforts,

Chris

[Adam Culp]

Thanks for taking the time on this Larry. I agree with it mostly. Here are some points on my mind in regards:

• I understand what you are saying in regards to the recent async voting. You are using it as a figurehead to highlight your point because it was recent. Because I feel my thoughts on this particular vote is relevant: I voted on the two async projects differently, based on my perception of those projects. I voted +1 for React because I see other projects working with it, and therefore there was interoperability. So why shouldn't React have a say in what that "looks" like? However, I voted +0 for Icicle because I didn't see so much interoperability there...yet. So didn't feel a +1 vote was warranted. The +0 was because I may not have been aware of all criteria, so didn't want to reflect negatively but wanted to ensure I voted.
• I feel that the points about membership should include the following:
• Does a project bring value to the FIG? Meaning, is there interoperability they can provide some insight into?
• Will the representative play a part in the communications and voting?
• And to some degree, does/will the member project utilize the PSRs? If not, why should they have a say in them? (at least should use some)
• Should never be about "cool kids".
• Should never be about feeling guilty to say "no".
• And finally, a member project should be able to state clearly "why" they feel they belong as a voting member...or move on.
• As for community folks. I feel the current message, though on the surface, can seem mixed. However, I feel this not really the case. You mentioned the UN as an example, and to some degree most representational governments are similar. You have voting members who create rules/laws, and the country/community around them voice their opinions through forums. So asking people to voice their opinions, but trust the few to vote, should not feel too abnormal. In fact, it works well in most cases.
• Sure, we can do a better job of informing the various communities at large about HOW they can get involved. But overall I think the current methods for getting involved are fine and should remain intact.
• Let's not delude ourselves, the greater community does not necessarily follow the PSRs for the sake of having a standard imposed on them. They follow the PSRs so that their own codebases are similar, and moving between their code and that of our frameworks and libraries is trivial. This reduces excessive time reading code, thus more time creating code. Makes it easier to onboard new people. And ensures their projects are able to work with the mainstream projects well. Yes, we should somewhat take the overall community into consideration, but ultimately we need to ensure our respective projects are as interoperable as possible...for the overall community to use them.

Regards,

Adam Culp

IBMiToolkit

[Larry Garfield]

I should clarify here:

The proposed PSRs, Promises and Event Loops, are currently niche needs in the PHP world.  The point of having PSRs for them, as I understand it, is to help them become less niche, and to bring those sorts of tools more effectively to the broader PHP community.  From the earlier discussion it seems like most here are fully in favor of using FIG to that end, myself included!

I'm aware we invited React to join; I was there at the meeting where we decided we should do so.  That's my point.  If we are a "just for us" group, then... we invited another project in just so that we could claim that Promises were now part of "us". :-)  Yet at the same time, we keep saying "you don't need to be a member to contribute".  There's a cognitive dissonance there that we need to acknowledge and address, because it's not healthy.

I don't mean to cast aspersions on React. Rather, I am casting aspersions on our membership process and how it is completely broken inconsistent with a "just for us" mission statement, which is in practice no longer valid anyway.

(Side note: I consider Promises and event loops different from a background queueing system; Drupal has one of those too.  I actually think there would be value in a common queue processing interface that could be backed by either persistent queues or cron-polling queues, but that's off topic at the moment and we've enough PSRs floating about the list already. <g>)

--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/492ac6c4-acaa-45d9-a30a-9eea0eba870d%40googlegroups.com.

[Larry Garfield]

On 12/13/2015 09:07 AM, Adam Culp wrote:

• I feel that the points about membership should include the following:
• Does a project bring value to the FIG? Meaning, is there interoperability they can provide some insight into?
• Will the representative play a part in the communications and voting?
• And to some degree, does/will the member project utilize the PSRs? If not, why should they have a say in them? (at least should use some)
• Should never be about "cool kids".
• Should never be about feeling guilty to say "no".
• And finally, a member project should be able to state clearly "why" they feel they belong as a voting member...or move on.

That's essentially our standard now, which is not working.  How do we evaluate "value"?  Right now we don't, at all.  And insight into what?

Drupal, as an institution, has very little insight into Promises or Event Loops as we don't use either. We have a little insight into Containers, but not much that Symfony wouldn't cover for us (as we're using the Symfony DependencyInjection component).  So does that mean Drupal shouldn't be a member, or shouldn't get a vote on those PSRs?  Conversely, Drupal probably has far more insight into, say, security advisories than most projects, as we're an old project with tens of thousands of add-on modules we also manage security advisories for.  So should a project that's never had a security advisory be admitted?  If we go with "well, on anything really", then we allow in basically every project ever.  Which is almost what we do now. :-)

We've never had a formal expectation of projects using PSRs.  Do we want to add such a requirement? "Must use at least X% of the PSRs published?"  I'm not sure I'd support that, although it is a viable objective metric we could consider.

We shouldn't feel guilty about saying no, I agree.  But we do, because we're humans and by and large nice people who don't like saying no to people.

We need more mission-driven, less fuzzy criteria. That's my point.

• As for community folks. I feel the current message, though on the surface, can seem mixed. However, I feel this not really the case. You mentioned the UN as an example, and to some degree most representational governments are similar. You have voting members who create rules/laws, and the country/community around them voice their opinions through forums. So asking people to voice their opinions, but trust the few to vote, should not feel too abnormal. In fact, it works well in most cases.
• Sure, we can do a better job of informing the various communities at large about HOW they can get involved. But overall I think the current methods for getting involved are fine and should remain intact.

I disagree.  As I noted, the following two messages we put out are inherently contradictory:

1) If you're interested, get involved and review stuff!

2) If you're interested, talk to your project's rep (or Cal if you're not tightly related to a given project) and get them to say it for you.

Do you disagree that we're giving off both messages right now, or that they're contradictory and confusing mixed messages?

• Let's not delude ourselves, the greater community does not necessarily follow the PSRs for the sake of having a standard imposed on them. They follow the PSRs so that their own codebases are similar, and moving between their code and that of our frameworks and libraries is trivial. This reduces excessive time reading code, thus more time creating code. Makes it easier to onboard new people. And ensures their projects are able to work with the mainstream projects well. Yes, we should somewhat take the overall community into consideration, but ultimately we need to ensure our respective projects are as interoperable as possible...for the overall community to use them.

I didn't say they follow them for the sake of being imposed upon.  That would be silly. :-)  They follow them because our work does have benefit to the broader PHP community, as you say, and we do them and ourselves a disservice by pretending otherwise.  We need to accept and acknowledge that "soft power" we have, which I believe is what Anthony has been saying.  We have to care about what non-members are doing and will do with our work.

--Larry Garfield

[Paul M. Jones]

Prepare for incoming:

<https://www.reddit.com/r/PHP/comments/3wownq/how_do_you_see_the_phpfig/>

I'll have more thoughts on this later.



--
Paul M. Jones
pmjo...@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

[Korvin Szanto]

I'd like to posit that perhaps the community treats us as a standards group simply because there /is no/ PHP standards group. Perhaps instead of turning the FIG into something we don't necessarily want it to be, we should create a new standards group from our ranks. 

A new standards group made up of individuals who may or may not represent a project that can simply adopt the PSRs (or a subset) as the initial standards would quickly gain support IMHO. That would leave the FIG to remain as a group meant to increase interoperability between frameworks.

Thoughts?

--
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/566D0EE6.8010805%40garfieldtech.com.

[Woody Gilk]

On Sun, Dec 13, 2015 at 12:23 AM, Larry Garfield <la...@garfieldtech.com> wrote:

Quite simply, any time you say "it's just for member projects, everyone else can ignore it if they want so we shouldn't care about them"... you're wrong.  You're harming FIG, and you're harming PHP.  Please stop.

To me, this is the most important statement in what you wrote, Larry. 

On Sun, Dec 13, 2015 at 5:06 PM, Korvin Szanto <korvin...@gmail.com> wrote:

I'd like to posit that perhaps the community treats us as a standards group simply because there /is no/ PHP standards group. Perhaps instead of turning the FIG into something we don't necessarily want it to be, we should create a new standards group from our ranks. 

Korvin, the problem with your suggestion is "from our ranks". If the FIG is meant to be "for frameworks" then the group has no right to decide who should be part of a standards group. In fact, this is the entire problem with a standards group: in order for it to be legitimate, it has to be sanctioned from an official source.

Right now, FIG fills this void (perhaps indirectly) because PHP leadership has chosen not to create a standards group. Just as an example, Go includes gofmt [1] to automatically format your Go program according to a standard, and includes a bunch of documentation that suggests additional idioms [2]. Nothing like this exists for PHP, officially. Just like the birth of FIG, I think a self-proclaimed standards body would be rejected by the community. An official announcement by PHP itself would probably also be rejected by some, but have much better chance of gaining traction.

Just my $0.02

[1]: https://blog.golang.org/go-fmt-your-code

[2]: https://golang.org/doc/effective_go.html

--
Woody Gilk
http://about.me/shadowhand

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CANeXGWWOAfQPNrZ_WsOkRBJBSg1pCVa%3DbpsD1QQ4raXZiQ65hQ%40mail.gmail.com.

[Evert Pot]

On Sunday, December 13, 2015 at 1:23:49 AM UTC-5, Larry Garfield wrote:

I personally have always strongly believed that:

1. PHP-FIG voters should be people, not projects.
2. Voters should be accepted in solely on merit.
3. 'Merit' should primarily be based on past contributions in the group. If your first email to the list is a membership request, you will get a -1 from me. Don't care who you are or who you know.
4. I would love to see a way where we can allow projects to be "PHP-FIG members" without giving them voting rights. I think half of the membership requests we get stem from wanting to simply be part of the group. If we can find some way where projects can benefit from being listed on the site as "offical PHP-FIG" member, we might be able to disconnect the group of people who actually intend to  contribute, and the ones who are mainly looking to legitimize the project they are working on.
5. Similarly there's a few projects that are obviously not active here. We need a way to make these projects not influence votes, without them losing their project status as "member". Perhaps then some of the projects that have obviously not done much on the list would not feel as bad in stepping forward and volunteer to relinquish their status as voter.
   

So if we would put a vote forward that would:

• Make people voters, not projects,
• Make voting rights non-transferrable,
  
• Convert all existing representative to members,
• Exclude all representatives that have not participated in (non-voting) threads on the list in the last 12 months,
  

Well, then you'd definitely have my vote. If we can make it easier to people to both gain and lose their status as voter, perhaps there's less psychological weight in losing or gaining it.

Everybody wants to vote, but a much smaller group is actually interested in doing something. Clearly this must imply that there's some other merit in being a voter, and I think it's 'status in the community', and we need to see that as a big problem within this group and work towards solving that.

Evert

--Larry Garfield

[Christopher Pitt]

@Evert - that is an interesting suggestion. How would the voter application process work? "Status in the community" seems a little open to interpretation, and could lead to a dwindling pool of voters (read: people taking responsibility to do work)...

[Evert Pot]

On Sunday, December 13, 2015 at 8:29:12 PM UTC-5, Christopher Pitt wrote:

@Evert - that is an interesting suggestion. How would the voter application process work? "Status in the community" seems a little open to interpretation, and could lead to a dwindling pool of voters (read: people taking responsibility to do work)...

Just to be clear, I think the 'status in the community' thing is a bad thing, and we should try to take it out of the equation. Being a voter should be an unglamorous burden. Something you need to work for.
If that implies that we end up with a very small group of voters, all who actually care and put some effort in... I don't see that as a problem =)

Evert

[Christopher Pitt]

Ah, I misread that. I agree as unglamorous as possible is a good idea. I don't think there's a problem with a small pool of hard-working people, but it is daunting to newcomers if the criteria for joining is nebulous and subjective. Even if it's awfully hard to earn a place...

[Dracony]

Having people as voters won't really work imho.  You need key project members to be voters since they are the ones actually implementing all that stuff, also it at least sets some tangible requirement: actually having a project. If you accept "people voters" the amount of membership requests will actually increase, and if the requirement becomes "past contributions to the group" you have a huge chance of favoring people who talk over those who code, and get complaints like "i posted around more than that guy over there".  The only people who should come up with standards are those who actually code it ( hence my old suggestion that only relevant projects should really vote on specific PSRs like the async one).

Actually according to the current rules its fairly simple to get your PSR running if you're not a voting member: 

1) Find 3 relaveant other projects

2) Make a post on FIG saying: we are guys from these projects, and want to make a PSR on this specific subject, sponsor us please

3) Pass the PSR entry vote

E.g. some time ago when I proposed a task-runner PSR, I had a thread with devs that were working on task runners, we came up with ideas, and although it didnt really take off in the end, we got through all the process with none of us being a voting member. So that is why I'm really not buying the whole "people don't participate and it's FIGs fault" mentality.

If you think the problem is that people just want to get on the list, well, remove the list from the website. If there is no nicely-designed list that problem pretty much solves itself =)

But seriously, all we need is just the Secratary to moonitor this, and approach projects that are not participating to either commit to the group or hand out their vote. We should get rid of the idea of a permanent voting membership, a project only gets a vote while it is useful. 

[Larry Garfield]

On 12/13/2015 05:19 PM, Woody Gilk wrote:

On Sun, Dec 13, 2015 at 12:23 AM, Larry Garfield <la...@garfieldtech.com> wrote:

Quite simply, any time you say "it's just for member projects, everyone else can ignore it if they want so we shouldn't care about them"... you're wrong.  You're harming FIG, and you're harming PHP.  Please stop.

To me, this is the most important statement in what you wrote, Larry. 

On Sun, Dec 13, 2015 at 5:06 PM, Korvin Szanto <korvin...@gmail.com> wrote:

I'd like to posit that perhaps the community treats us as a standards group simply because there /is no/ PHP standards group. Perhaps instead of turning the FIG into something we don't necessarily want it to be, we should create a new standards group from our ranks. 

Korvin, the problem with your suggestion is "from our ranks". If the FIG is meant to be "for frameworks" then the group has no right to decide who should be part of a standards group. In fact, this is the entire problem with a standards group: in order for it to be legitimate, it has to be sanctioned from an official source.

Right now, FIG fills this void (perhaps indirectly) because PHP leadership has chosen not to create a standards group. Just as an example, Go includes gofmt [1] to automatically format your Go program according to a standard, and includes a bunch of documentation that suggests additional idioms [2]. Nothing like this exists for PHP, officially. Just like the birth of FIG, I think a self-proclaimed standards body would be rejected by the community. An official announcement by PHP itself would probably also be rejected by some, but have much better chance of gaining traction.

Just my $0.02

[1]: https://blog.golang.org/go-fmt-your-code

[2]: https://golang.org/doc/effective_go.html

Which is exactly why FIG, despite the name, is the most viable effective PHP Standards Group right now.  The "PHP Group" (which holds the trademark and basically does nothing else right now) and Internals generally have actively declined to "lead" in this regard.  Whether that's good or bad is beside the point at the moment, but it means that there is no person or group that can "bless" standards officially.

Except us, because FIG has, effectively, filled that gap.  And over the past 6 years since its poorly handled launch, it seems like it's earned "enough" respect and reached a broad enough audience that it's already there.  We didn't get permission from anyone to become that, but it's happened anyway organically.  Trying to launch a new "non-Framework PHP Standards Group" would be starting over from zero, 6 years behind, and not really offer anything that FIG doesn't. Despite the name, in fact, we've long-since moved beyond being "just" frameworks.  Witness the membership of Drupal and concrete5 :-), plus various stand-alone libraries.

As evidence for FIG filling that gap, I would cite:

1) The overwhelming majority of projects on Packagist use PSR-0/4 for autoloading, even non-FIG projects.
2) I can't recall the last time I ran across a random project on Packagist that wasn't using PSR-1/2, or at least something mostly like it, even non-FIG projects.
3) As of November 2015, PSR-3 had 1277 dependant projects on Packagist and 18 million installs. PSR-7 had 278 dependant projects and 1.4 million installs. There are 40-some-odd member projects.  Clearly lots of projects besides us are using these.

--Larry Garfield

[Gary Hockin]

Larry, as usual makes excellent points very well. I wholeheartedly agree with nearly all of what he says.

I also completely agree with Evert's points on having people as members. At the risk of sounding self serving, I think that inviting people to join the FIG because of their contributions as a non-member (so to speak) works for itself. Someone who has been reviewing PRs, involved in discussion and generally contributing because they want to, will make an excellent voting member who has actually proved themselves before being invited.  

'...if the requirement becomes "past contributions to the group" you have a huge chance of favoring people who talk over those who code, and get complaints like "i posted around more than that guy over there"...'

I entirely disagree with this statement, because I don't believe that being someone who talks or someone who codes are mutually exclusive. I would take an average coder who is fairly active over a brilliant coder who is never active. Ideally we want brilliant coders who are always active of course. It also opens the door to inviting contribution from perceived "experts" when the situation dictates it. If there is a PSR that is handling some aspect of security, then asking Anthony Ferrera or Chris Cornutt (to name but 2 people) would be an excellent idea in my opinion. Obviously, this is just an example to illustrate a point.

To reinforce Larry's point about the placing of the FIG in the community, for me, the FIG are not creating standards for interoperability any more. Arguably, PSR-2 has no impact on interoperability at all (if I pull in your code to use or extend, what do I care about it's style unless I want to monkey patch it?). The FIG is perceived by the greater community as being a creator of standards, the word "interop" has become meaningless (even if it ever existed in a dictionary, which I'm not convinced it did). Using statements like "you don't have to use it" is just plain wrong and a cop out. If you want to use any of the libraries that have become de-facto for certain problems (like Monolog is to logging), you will be using PSRs on multiple levels - not least to autoload the package (probably), so yes, unless you're coding everything from scratch, you pretty much need to use PSR driven code.

I applaud the discussion around this topic, and I genuinely hope that some solutions to these problems can be found. The group and PHP will be much stronger for it if they are solved.

Gary

--

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/566E2C8A.9020304%40garfieldtech.com.

[Roman Tsjupa]

I don't see the problem with FIG being that non-project people cannot vote and thus cannot contribute. People opinions were all over the place when PSR-2 was in the works.

It looks like the gist of the proposal boils down to: "allowing non-projects to vote will make people more eager to contribute", but we already know that is not the case. We already have project members that don't vote and a swarm of +0s. Allowing non-project memberships will just swing the membership doors wide open.

Imho the FIG should stay an "interoperability" and not a "standards" group. Because "interoperability" is something tangible, the whole reason people started using the PSRs was because the frameworks used them. If the fframework code is in PSR-2 it is very likely the user code will also be in that. When framewoks adapt PSR-6 for caching it is likely that caching libraries will have to support the standard to be suable with the frameworks. The whole push comes from the projects behind FIG, that is why it is so important that those projects enforce the PSRs in their own codebase. PSRs became "standards" because of their acceptance in important projects like Symfony2.

Also allowing non-project memberships will tilt the voting towards large projects, imagine if like 7 core Symfony2 devs join? Bam, Symfony2 now gets 7 votes. The Drupal ecosystem is so vast that if they wanted they could turn this into a "Drupal standards" group and bring Drupal code style as the new PSR =)) 

--
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/oqO1ZH5tJKU/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/CAAueXOV%2B5kBPs65ZRMnBB0M0BcPb32WbXWWXUQxHJMcEYM8DTw%40mail.gmail.com.

[Andrew Carter]

From the voting on the Reddit thread started by pmjones, it is looking very much like that community want FIG to fill the role of a userland standards group.

https://www.reddit.com/r/PHP/comments/3wownq/how_do_you_see_the_phpfig/

Almost all of the up-voted comments are pushing for pmjones's third option and almost all of the down-voted are pushing for his first.

I know there are better ways to conduct a community survey, but it does seem as though the opposition to FIG being a general standards group is mainly internal (even if it wasn't always).

[Paul M. Jones]

> On Dec 14, 2015, at 07:00, Andrew Carter <andrewca...@gmail.com> wrote:
>
> From the voting on the Reddit thread started by pmjones, it is looking very much like that community want FIG to fill the role of a userland standards group.
>
> https://www.reddit.com/r/PHP/comments/3wownq/how_do_you_see_the_phpfig/
>
> Almost all of the up-voted comments are pushing for pmjones's third option and almost all of the down-voted are pushing for his first.
>
> I know there are better ways to conduct a community survey, but it does seem as though the opposition to FIG being a general standards group is mainly internal (even if it wasn't always).

Beware of premature speculation; it's not even been 24 hours. Let it get closer to 3 days.

[Roman Tsjupa]

I really would not consider a reddit thread that as of now only has 40 total votes for the actual thread and the highest comment of 27 upvotes to be a "representation of the PHP community" by any stretch of the imagination. This actually represents the problem I would have with non-project members: vocalilty mistaken for majority.

--
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/oqO1ZH5tJKU/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/192B4514-224C-40E6-B788-41644DBC31F1%40gmail.com.

[Andrew Carter]

Not sure where you got those quotation marks from?

... to be a "representation of the PHP community" by any stretch of the imagination ...

Not sure if it was your intention, but you appear to be quoting me with something that I didn't say (which I'd rather you didn't do!).

My actual statement was: "it is looking very much like that community want FIG to fill the role of a userland standards group".

I take pmjone's point to wait for it to play out - but (from what I've seen on Reddit) I think that time will support that assertion.

[Roman Tsjupa]

That was not a quote, I just used them for emphasis

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/236b7f83-543e-4e8b-b85e-1d8bb29503c2%40googlegroups.com.

[Paul M. Jones]

Hi all,

The fundamental problem here stems from a mischaracterization of the group. That the mischaracterization has been ensconced "on paper" in a bylaw does not change the fact of the mischaracterization, it only popularizes that mischaracterization.

The true character of the FIG is this: the group was originally, and continues to be, constituted primarily **not** of projects, but of **persons** (more specifically, of persons-with-projects; more on that later).

Using a less-accurate mental model of reality leads to problems that can be resolved only by using a more-accurate model. The less-accurate model is that of "projects." the more-accurate model is that of "persons" with ideas, biases, interests, histories, and desires of their own.

More below; all quotes are from Dec 13, 2015, at 00:23, by Larry Garfield <la...@garfieldtech.com>.

* * *

> The status quo
> =========
>
> First off, to make sure we're all on the same page, as of today (and
> for the past few years) FIG is, officially on paper, a consortium of
> *projects*. I often equate it the United Nations of PHP. We voting
> representatives are ambassadors of our respective projects, here to
> pass non-binding resolutions that member projects may or may not
> ignore. (Just like the UN...) We are not individuals, we are
> ambassadors of projects, only. In some cases the ambassador of a
> project is also the head of state; in some cases the ambassador is
> just a proxy for a core team that takes their own vote; in some cases
> the ambassador has basically free-reign from his/her project. That's
> up to each project to determine.
>
> Whatever we want FIG to be, whatever it once was, whatever it has the
> potential to be, whatever some wish it were, that is, on paper, what
> FIG is today.
>
> That structure also does call into question the "community
> representative" role, as it's essentially the "Other" project.

The above quote contains one literally true statement: that the FIG is "on paper" constituted of projects. That statement is also only trivially true, because what the bylaw states is in contradiction to reality. Acknowledging that reality will go long way toward helping resolve the problems we face, such as they are.

Some background; other founding members, please correct my history as needed.

When the FIG (nee "php-standards") was founded, we at the table wanted to find a way to define quantifiable membership qualifications. We wanted qualified, experienced, well-considered *persons* to presented and discuss their thoughts and ideas. But you never know who's going to have a good idea, and if membership is wide open to any person can speak, it's too easy to lose the signal in the noise.

As such, we settled on one fundamental membership qualification: that the person have at least one *project* through which their ideas had already been tried and tested in a community of others. Thus, the person's basic qualification for membership was that a number of others already subscribed to their ideas, by fact of using their project(s). It was a *minimum* qualification; that is, necessary but not sufficient. The founding members were satisfied to apply individual arbitrary criteria of their own for sufficiency.

The followup issue was that of people who were "known" (by the founders) to have valuable opinions, without attachment to any specific codebase or project. Thus was formed the "community" position, currently held by Cal Evans. It is a unique position.

This foundational element of the FIG, that a person needs to have a project to be a voting member, was sometime after described in shorthand as "projects not people". Later, a bylaw was passed that attempted to formalize the shorthand form without regard to its origins. Thus, we have a bylaw that at the time of its passing did not accurately describe the constitution of the FIG membership, and did not then nor does it now accurately describe reality.

The first thing to do, then, is realize the truth: that *persons* vote in this organization. The persons are members only because they have critical involvement in some project, but note: the project is not what thinks. The project is not what speaks. The project is not what proposes, defends, criticizes, and refines ideas. The project is not what votes. The *person* does all these things, sometimes as an individual and sometimes as a voice for other persons. That person is a member here only because they have something "tangible" (as tangible as things can be in software) to base their opinion on: a project on which their ideas are based and in which they find form.

> Because we never took the time to define qualifications for
> membership, or expectations of membership (other than "don't be a
> jerk"),

As noted earlier, the very first defined qualification for members was that they have a project of some sort. The point of this qualification was to help separate the wheat from the chaff, as it were. Certainly some wheat is lost with that kind of qualification; there are lots of people out there with valuable opinions but no project codebase. However, the vast majority (might I say all?) of the chaff was also sorted out.

> FIG membership has come to be seen as mark of legitimacy. That
> is, most people, including us (and including me), make one of the
> following errors:
>
> 1) "I want my project to be a member of FIG because that means it's an
> official big-boy project."
>
> 2) "We should have project X as a member because project X has insight
> to offer", although we never define what insight that is. (Guilty!)
>
> 3) "I want to be a member of FIG because I have insights to offer."

These are all directly related to the mischaracterization of the organization as one primarily of projects and not of persons.

> That is, we've conflated membership and participation.

AFAICT, the points offered above do not support that summary.

> That is, I think, a key part of our voter turnout
> issue and simply trying to coerce more people to vote is not going to
> solve the root issue: What does membership even mean?
>
> Our current standard of membership is, effectively, "people don't
> dislike you/your project enough to feel bad for saying no."

Exactly. *Persons* vote. They have their project as a qualification for being allowed to vote in the first place.

> Yet I think we're afraid to define a
> metric for fear that some, perhaps many, current projects wouldn't
> qualify for it and grandfathering them all would undermine any changes
> we make.
>
> Take, as an example, the recent async proposals. Until very recently,
> the only member project that had anything to do with async was Guzzle.
> So for "us", collectively, async doesn't matter at all and we
> shouldn't be interested. Drupal, Symfony, Zend, Stash, Composer, none
> of them do anything with async, so have no experience to offer, and
> are unlikely to be doing anything with async in the near future.
> Which means... what do we have to do with it?

This problem, such as it is, stems from misapprehending this group as a collection primarily of projects, instead of persons.

> If were were to JUST vote on behalf of our projects, then pretty much
> all of us except Guzzle would be voting+0 if at all since it doesn't
> affect us. At which point the Promise, Event Loop, etc. proposals
> would never pass an entrance vote, or if they did it would be with one
> +1 and 15 +0s, which would technically pass but I think we'd all think
> something fishy was going on. :-)

This is why it's important to see this group as it really is: that is, as a group of thinking persons, with ideas and biases and backgrounds and desires.

> Yet we actively invited certain projects to join, specifically for
> these specs, because we wanted their input. Which directly undermines
> our repeated statement that you don't need to be a voting member to be
> involved in FIG! We're being rather hypocritical on this front, and I
> don't exclude myself from that statement.

Again, this stems from the misunderstanding of the true nature of this group. Frankly, I see no need to invite *projects* here. If instead *persons* with a track record of valuable thought and opinion (as evidenced by a project of some sort) seek to become voting members, that is a different thing.

> There has been much discussion in IRC of late about the "cost" of
> membership, which is basically zero. That's part of the problem, and
> encourages "I care about PHP so I want to be a member" and "I
> implement a bunch of PSRs, so I should be a member". There's nowhere
> we ask, of projects, "ask not what FIG can do for you but what you can
> do for FIG." In a large part that's because we don't want to require
> projects to implement PSRs (because we know full well many will balk
> at doing so, and rightly so), but it means we have a gap that is not
> filled by anything. the cost/reward for projects to join FIG is all
> askew, which is also why we have low turnout.

The reason we don't require implementation of PSRs is because the persons running those projects may not wish to do so. The person is a member so that they can vote up-or-down on thoughts and ideas, not so they can be shackled involuntarily to a summary decision they disagree with.

> There are some that argue for "the person has shown they will
> contribute to FIG", which while a laudable criteria... misses the
> point. Because we are supposed to be voting on the *project*, not the
> person. So an individual *person* being active may or may not have
> anything to do with the value the *project* brings to the table, and
> vice versa. This split personality disorder we have is not
> sustainable.

What is *supposed* to be true, is not in fact true. We evade that fact to our own detriment.

Each member here, with few if any exceptions, votes on the *person* as a member, whether they say that out loud or not. The project is secondary, or at best corollary, to the person. That's because, among other things, the project is evidence of the person's ability to contribute thoughts and ideas, and defend or criticize ideas; the project is not the contribution itself.

> We do have a responsibility to the broader PHP community at this
> point. We may or may not want it, but that is, to be frank,
> irrelevant. We have it, whether we asked for it or not. We may have
> no "hard power" ability to enforce a PSR on anyone, but we have a
> great deal of "soft power" influence on the whole ecosystem, which we
> should use wisely.

I'll totally grant the "soft power" point. Having said that, let's not pre-emptively cloak ourselves in a formal responsibility that others don't actually see us as having. Time will tell more certainly on that point.

> Does that itself necessitate some massive change in FIG's structure?
> Not on its own, necessarily. It does necessitate a small change in
> our own behavior, though: Quite simply, any time you say "it's just
> for member projects, everyone else can ignore it if they want so we
> shouldn't care about them"... you're wrong. You're harming FIG, and
> you're harming PHP. Please stop.

Please stop telling other people what to please stop doing.

I will respond to the remainder of Larry's post at a future time.

[Larry Garfield]

Paul, while I will grant you what the original discussion around the
table may have been back at php[tek] 2009 (I wasn't there), the "on
paper" reality is far more relevant and important than you give it
credit for. However, the dissonance between people and projects is, I
will agree, a major problem for FIG and one of the things I was pointing
out.

I, at least, do look more at the project than the person on application
votes, unless the person in question has shown themselves to be a jerk I
don't want to deal with. Eg, I'd never met or heard of the new React
representative, but I definitely know React.

That said, you are essentially arguing that the standard is and should
be "you can be one of the cool kids only if you have proven it by
leading a project." Which is, to be blunt, a horrifically bad filtering
mechanism. If you want a goal of "people", then tying "people" to
"projects" is recognizing and respecting only a very narrow sliver of
the sort of contributions that people can offer. Then you're creating a
"project leads club", which while potentially valuable is a very, very
different animal. It's also one that I have no particular desire to be
part of, nor would I be eligible for as I am not the lead of Drupal.
:-) (Yet at the same time, we have a dozen project leads on this group
whose involvement consists of occasionally remembering to vote, which is
not helpful to anyone.)

If, suppose, I were to step away from Drupal and decide to do something
else techy with my life, should that disqualify me as a voting rep? If
we're a collection of projects, probably yes. If we're a collection of
people, I'd argue no. But if the only way for me to "prove myself" as a
person is to be a project lead, then we're really talking about
projects, not people, after all.

That is precisely the dissonance that I am actively calling out as harmful.

So to those who want this to be an organization of people, not projects,
find a definition of "sufficiently cool person" that does NOT include
"leads a project of some undefined coolness". Because that definition
is, frankly, one of the causes of our current problematic situation.

--Larry Garfield

[Roman Tsjupa]

Well if you remove the project from the equation and have people members you actually increase the "personal coolness" factor.  The whole point of having projects imho is that the project representative represents the ideas of the people within that project and consults as much of them as possible before the vote. So when I see "+1 from Drupal" I consider this as you have talked to some key project members and vote for them. To me it's far more logical than just having a personal opinion behind a vote.

If you leave the Drupal project, your opinion still matters and you can continue posting here, but you no longer represent a vast number of developers, so why should you have a vote?

--
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/oqO1ZH5tJKU/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/566F0196.9010608%40garfieldtech.com.

[Larry Garfield]

There's currently no requirement that I (or any other rep) consult X
number of people in our respective projects. For the past several
months, anyone that I'd consult has been far too busy getting D8 out the
door to even think about FIG. :-) And opinions about FIG within
Drupal's leadership vary widely from "yay" to "<censored> those
busybodies." I vote based on my experience with Drupal and software
architecture generally. Eg, my input on PSR-7 was informed by my work
with Drupal 8's routing and core pipeline (which is largely based on
Symfony 2), but I didn't consult with Dries directly on it.

Here's the catch: "Represent a vast number of developers." There are
many projects here that have combined fewer developers active on them
then the top 20 Drupal modules. Being a project lead doesn't itself
imply "I can legitimately speak for X number of people who will do what
I say." Most projects have a very small number of significant
contributors. That's normal. A *community lead* may be able to make
such a statement, but not all projects have large communities around
them and not all communities are necessarily built around a project and
one person's vision therein.

Which just goes back to my point: "We can tell if you're a cool enough
developer by whether or not you are listed as the project lead of a
project" is a crappy metric, and one we should not rely on. If we want
to switch from Projects to People, on paper, then we need to find a
metric for People that is not based on such a poor metric.

> <mailto:la...@garfieldtech.com>>.

> <mailto:php-fig%2Bunsu...@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/566F0196.9010608%40garfieldtech.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>.

> 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/CANamvv0DSupKSTXdAwVnYNRgoDgLUuf8Vs%2B620TfXrAaa3Qhug%40mail.gmail.com
> <https://groups.google.com/d/msgid/php-fig/CANamvv0DSupKSTXdAwVnYNRgoDgLUuf8Vs%2B620TfXrAaa3Qhug%40mail.gmail.com?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout.

--
--Larry Garfield

[Stefano Torresi]

Hello list,

First of all I strongly agree with Evert Pot and PMJ about the whole point of "we say it's projects, not people, but it's actually the other way around".
In fact, I've already expressed my opinion on the matter about one year ago, but I was predictably shut down by the bylaws.

IMHO, I the group will never find a metric that can comprehensively describe the eligibility of individuals. Or even of projects, for that matter... right now it's just arbitrary and pretty much personal, there are no objective parameters in place; you just need a sponsor, then it comes down to the votes.

So can't we just make things simpler? Want to apply? Find n (let's say three) number sponsors and tell why.
You have a well known project legitimating your potential contribution? Ok, make it only one sponsor, just like now.
Let's just admit there are no metrics, membership applications will be evaluated by the votes, and the only barrier is the sponsorship. Just like now.
Is someone previously voted in not contributing at all, or even damaging the group activity? Vote him out.

Then you only need to fix the voting system, and stop the "+0 because don't want to be rude" nonsense.
Am I the only one thinking that a Github authenticated mechanism would be of great help for this?

Also I don't think the SNR issue and "filtering applicants" is an issue: if you look at past PSR threads, most of the noise was actually from non member peers, as opposed to some members who have been awfully quiet.

Just my 2 cents.

Ciao

[Phil Sturgeon]

Why are we rehashing the people vs projects thing that has been discussed over and over and over and over? 

Larry hits the nail on the head. It's saying "The only way you can prove that you matter to the FIG is by leading a project." is pretty awful.

Multiple projects have proved that being able to swap people out is beneficial. Zend, PyroCMS, AWS and at some point soon the League have all benefitted from being able to switch things around. 

I agree with most of Larry's post up top. I'd answer one of his questions with something I've been thinking about recently:

2) Figure out explicitly, and document, what the benefits are of FIG 
membership and the costs.  Currently the only cost is "you vote 
occasionally", which is too low.  There needs to be some ongoing 
responsibility and commitment that a project (or person, if we go that 
route) makes to FIG's mission statement. 

Kick projects the f**k out for not voting. It's been said for a long time, and votes are tracked in a spreadsheet, but nobody has had the grits to actually do this. Do it. Kick projects out for not voting.

Get rid of the 0. You either have an option or you don't. 

Extend the review period to a month. Extend the voting period for acceptance too. 

Maybe even go a step further and force projects to vote on the acceptance.  If you have a month, and in the time you cannot be bothered to read the review, then maybe you overestimated your ability to contribute to the group.

I know a lot of people who signed up to look good then do barely anything other than vote when DMed, and some don't even bother doing that.

As for the concerns around "PSR-6 of last minute feedback being ignored", maybe PHP secretaries can be listed somewhere really public, and we can say "Having a problem with getting your feedback heard? Email secre...@php-fig.org and one of these three folks will make sure you get answers."

Maybe those folks can be responsible for halting a vote if some massive feedback pops up and it gets ignored. Coordinators are meant to do this, and still can, but maybe having somebody neutral in there to say "Hold on a minute" when something scary surfaces would have value.

I think there are lots of improvements to the existing goals and existing workflows that can be made, and I'll be happy to help with any of this. Changing the core concepts to make it seem like even more of an ego-centric circle jerk of PHP developers who are better than everyone else and get to tell them how to work instead of a serious group of people dedicated to building quality standards (regardless of the audience) is just not something that needs to happen.

[Phil Sturgeon]

Also, add a blog, so announcements are louder. The ones with the best feedback were blogged on personal blogs each step of the way, but an official one would be better.

Tweet, so interested people can see whats happening with votes without having to follow the noise on here. 

Post on Reddit to see what people think with different versions of the PSR. Sure 80% of it is pure garbage fire, but some good stuff floats up.

There is a lot you can do to make the situation better. I did all of this with PSR-4 and it added a lot of value. Y'all could do the same. 

[Gary Hockin]

A blog of a good idea, I'm happy to help with creation and posts.

G

--

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/6bd9d0b1-a4c2-4cad-8f62-f6a6e4ee5146%40googlegroups.com.

[Dracony]

Phil, aren't you concerned that removing +0's will result in less truthful votes and basically turn them into +1s for a lot of things?

Discussions in other threads usually reached the consensus that +0 is really beneficial for certain times. Although that might be somewhat mitigated by extending the voting period, but still.

On Sunday, December 13, 2015 at 7:23:49 AM UTC+1, Larry Garfield wrote:

There's a couple of related topics being discussed in a few separate
threads right now.  Although they're in different threads, I believe the
voter turnout question, the mission statement question, the community
involvement question, and a few long-standing issues are all
inter-related.  I will therefore attempt to address all of them in a
single (hopefully) coherent statement.  Knowing me this will be long, so
grab some coffee. :-)

Problem 1: Voter turnout from voting representatives is embarrassingly
low.  That has the potential to undermine FIG's work, as well as the
legitimacy of FIG's work in the broader community.

Problem 2: Who is FIG's target audience?  Member projects? The PHP
community at large? PHP projects that want to interface with member
projects?  There are inconsistent answers to this question.

Problem 3: How DO we want people other than FIG voting reps to be
involved in FIG? Or do we?

Problem 4: What projects should or should not be FIG members?

The status quo
=========

First off, to make sure we're all on the same page, as of today (and for
the past few years) FIG is, officially on paper, a consortium of
*projects*.  I often equate it the United Nations of PHP.  We voting
representatives are ambassadors of our respective projects, here to pass
non-binding resolutions that member projects may or may not ignore.  
(Just like the UN...)  We are not individuals, we are ambassadors of
projects, only.  In some cases the ambassador of a project is also the
head of state; in some cases the ambassador is just a proxy for a core
team that takes their own vote; in some cases the ambassador has
basically free-reign from his/her project. That's up to each project to
determine.

Whatever we want FIG to be, whatever it once was, whatever it has the
potential to be, whatever some wish it were, that is, on paper, what FIG
is today.

That structure also does call into question the "community
representative" role, as it's essentially the "Other" project.

Membership
========

Because we never took the time to define qualifications for membership,

or expectations of membership (other than "don't be a jerk"), FIG

membership has come to be seen as mark of legitimacy. That is, most
people, including us (and including me), make one of the following errors:

1) "I want my project to be a member of FIG because that means it's an
official big-boy project."

2) "We should have project X as a member because project X has insight
to offer", although we never define what insight that is. (Guilty!)

3) "I want to be a member of FIG because I have insights to offer."

That is, we've conflated membership and participation.  We're all guilty

of this.  That is, I think, a key part of our voter turnout issue and

simply trying to coerce more people to vote is not going to solve the
root issue: What does membership even mean?

Our current standard of membership is, effectively, "people don't

dislike you/your project enough to feel bad for saying no."  That is, to
be blunt, an abdication on our part to build an important part of this
group's definition.  It is a problem, which is also a direct cause for

our low voter turnout.  Yet I think we're afraid to define a metric for

fear that some, perhaps many, current projects wouldn't qualify for it
and grandfathering them all would undermine any changes we make.

Take, as an example, the recent async proposals.  Until very recently,
the only member project that had anything to do with async was Guzzle.  
So for "us", collectively, async doesn't matter at all and we shouldn't
be interested.  Drupal, Symfony, Zend, Stash, Composer, none of them do
anything with async, so have no experience to offer, and are unlikely to
be doing anything with async in the near future.  Which means... what do
we have to do with it?

If were were to JUST vote on behalf of our projects, then pretty much
all of us except Guzzle would be voting+0 if at all since it doesn't
affect us.  At which point the Promise, Event Loop, etc. proposals would
never pass an entrance vote, or if they did it would be with one +1 and
15 +0s, which would technically pass but I think we'd all think
something fishy was going on. :-)

Yet we actively invited certain projects to join, specifically for these
specs, because we wanted their input.  Which directly undermines our
repeated statement that you don't need to be a voting member to be
involved in FIG!  We're being rather hypocritical on this front, and I
don't exclude myself from that statement.

There has been much discussion in IRC of late about the "cost" of
membership, which is basically zero.  That's part of the problem, and
encourages "I care about PHP so I want to be a member" and "I implement
a bunch of PSRs, so I should be a member".  There's nowhere we ask, of
projects, "ask not what FIG can do for you but what you can do for
FIG."  In a large part that's because we don't want to require projects
to implement PSRs (because we know full well many will balk at doing so,
and rightly so), but it means we have a gap that is not filled by
anything.  the cost/reward for projects to join FIG is all askew, which

is also why we have low turnout.  We don't, as Paul Jones likes to put
it, "have skin in the game".

As an aside, this is one reason I didn't get around to voting on
phpSpec's application. I am in the process of re-evaluating my criteria
for when I would support a new member, and I'm not sure yet what
standard I would apply.  I'd prefer to have that be an explicit
discussion, and for us to, yes, establish some common semi-objective
criteria that goes beyond "we don't hate you yet".

There are some that argue for "the person has shown they will contribute
to FIG", which while a laudable criteria... misses the point.  Because
we are supposed to be voting on the *project*, not the person.  So an
individual *person* being active may or may not have anything to do with
the value the *project* brings to the table, and vice versa.  This split
personality disorder we have is not sustainable.

We do have a responsibility to the broader PHP community at this point.  
We may or may not want it, but that is, to be frank, irrelevant.  We
have it, whether we asked for it or not.  We may have no "hard power"
ability to enforce a PSR on anyone, but we have a great deal of "soft
power" influence on the whole ecosystem, which we should use wisely.

Does that itself necessitate some massive change in FIG's structure?  
Not on its own, necessarily.  It does necessitate a small change in our
own behavior, though: Quite simply, any time you say "it's just for
member projects, everyone else can ignore it if they want so we
shouldn't care about them"... you're wrong.  You're harming FIG, and
you're harming PHP.  Please stop.

2) Figure out explicitly, and document, what the benefits are of FIG
membership and the costs.  Currently the only cost is "you vote
occasionally", which is too low.  There needs to be some ongoing
responsibility and commitment that a project (or person, if we go that
route) makes to FIG's mission statement.

[Paul Dragoonis]

On Tue, Dec 15, 2015 at 6:16 PM, Gary Hockin <ga...@hock.in> wrote:

A blog of a good idea, I'm happy to help with creation and posts.

With regards to FIG blog - I've covered this in a post in 14th Oct

https://groups.google.com/forum/#!searchin/php-fig/blog/php-fig/VjWVd-zLQ-0/iF_5AGLlBgAJ

We just need someone with the capacity to clone parts of what we already have on the website to pull in markdown files as news, instead of markdown files for the PSR's.

I'm hoping someone has the capacity to get stuck in.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAAueXOUEaapm-iFaxHw6%2B%3DXbGdVr_k3UBzCf%2B-Z%2BcapuF5NNiQ%40mail.gmail.com.

[Phil Sturgeon]

Dracony, I'm not concerned that removal of +0 would end in dishonest votes. Right now I think a lot of project use them as "I don't like this thing but I'm gonna be nice and not -1 it" which is not helpful, and disruptive.

[Christopher Pitt]

Phil, I think "0" can also represent "I don't have an opinion on this and defer to the group", which is not the same as "-1" (this has been mentioned by a few people before now).

[Phil Sturgeon]

On Tuesday, December 15, 2015 at 3:33:04 PM UTC-5, Christopher Pitt wrote:

Phil, I think "0" can also represent "I don't have an opinion on this and defer to the group", which is not the same as "-1" (this has been mentioned by a few people before now).

Fair enough. I put a maybe on the front, because maybe if you don't have an opinion enough to do anything other than shrug when the 1 or 2 PSRs a year are being finalized then you aren't really helping out or pulling your weight. Not that I suggested this for acceptance votes only. Projects shouldn't only vote on PSRs that directly affect them, and somebody on the team should have an opinion.

Just ideas. 

[Phil Sturgeon]

* Note that I suggested this for acceptance votes only.

Sorry. Important typo.

[Derrick Nelson]

On Tuesday, December 15, 2015 at 3:33:04 PM UTC-5, Christopher Pitt wrote:

Phil, I think "0" can also represent "I don't have an opinion on this and defer to the group", which is not the same as "-1" (this has been mentioned by a few people before now).

"I don't have an opinion" has no place in a group like this.  It's obvious that not every topic will be relevant to every project, but voting members should be here to research, learn about, participate in discussions for, and ultimately vote on *all* topics (subject to practicality), not just the ones that tickle their respective fancies.  If you don't have an opinion, odds are it's because you didn't put forth sufficient effort into learning about the topic.  The notion that one must be one of the domain experts in order to feel justified in casting a vote is so disappointing to me.  This group has a responsibility to its members to educate each other well enough that everyone feels qualified to vote on everything.  If you're a domain expert for a given proposal, you should be taking it upon yourself to make sure everyone else in the discussions understands the big picture, if not also the relevant nuances being debated.  If you're on the opposite side of that fence, you should *speak up* about your ignorance.  Not being familiar with a problem space is not shameful, and this group is comprised of a very professional bunch of folks who, I'm sure, would much rather have another intelligent voice in the discussion than another non-voting lurker.

Ultimately, I don't think person vs. project or frameworks vs. community matter much.  What's going to make the biggest difference overall is focusing and molding the group into a more passionate entity.  That means culling members that don't get (and stay) involved, regardless of prestige or popularity.  It means actively engaging the other members who you aren't seeing in a discussion.  It means polling the community or other sources when outside opinions might be valuable.  So on and so forth.

At least, this is the FIG that I want to see become a reality.  The rest of it is just noise.

[Larry Garfield]

Well, we've now had 2 very directly opposed opinions expressed on this
point by different people (which is good, because it gives us something
concrete to discuss):

1) PSRs should be decided on by those they impact.

2) Whether they impact you or not, voting reps should be informed enough
to vote on everything.

To pick on the forthcoming Promises PSR again (no offense guys, it's
just an obvious target for this topic), quick poll. Which of the
following more closely represents your position:

1) A Promises spec should be developed and decided on primarily by
people involved in React, Icicle, Guzzle, and other Promises-using
projects, and the rest of us should STFU.

2) All FIG members should become sufficiently versed in Promises as a
concept (with the help of those with domain knowledge already) to cast
an informed +1/-1 vote. Voting reps who are too lazy to do more than
cast +0 should GTFO.

(This is a poll for everyone, although please note if you're a voting
rep or not as I'm curious if there's a difference.)

--
--Larry Garfield

[Christopher Pitt]

2, voting rep

[Jason Walker]

2, not voting rep

[Adam Culp]

2, voting rep (but need to ensure there is enough time to gain knowledge)

[Brian Retterer]

2, voting rep

Agree with Adam on the time though.

[Niels Braczek]

Am 16.12.2015 um 02:30 schrieb Larry Garfield:

> 1) A Promises spec should be developed and decided on primarily by
> people involved in React, Icicle, Guzzle, and other Promises-using
> projects, and the rest of us should STFU.
>
> 2) All FIG members should become sufficiently versed in Promises as a
> concept (with the help of those with domain knowledge already) to cast
> an informed +1/-1 vote. Voting reps who are too lazy to do more than
> cast +0 should GTFO.

I'm not a voting member.
Preferring no.2.

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 |
------------------------------------------------------------------

[Andrew Carter]

2, not voting rep

[Gary Hockin]

+0

--
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/4935ef1b-28fb-4163-b880-6abaeb4b6138%40googlegroups.com.

[Gary Hockin]

Sorry, I meant 

2 - not voting rep

[Roman Tsjupa]

Voting rep, I stand with 1.
It is effectively like that already, ultimately its the working group that decides 99% of things and the rest of the members just pitch ideas to it.

--
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/oqO1ZH5tJKU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.

[David Négrier]

Not a voting member, clearly preferring #1.

Let me elaborate a bit:

A lot of projects have needs for interoperability. These projects usually need a set of common interfaces to be able to work together.
There is a huge need for this. The topic can be quite obscure for the rest of the PHP community (like Async stuff...). Nonetheless, there is a need for interoperability and this is what FIG is all about.

Now, not all PSRs are made equal. PSR-0, 1, 2, and 4 are clearly applying to any project out there.
A Promise PSR is really targeting a smaller set of projects.

I think PHP-FIG should really focus on encouraging more projects working together (whatever the standard they reach). For PSRs targetting a small set of projects (on very obscure topics), there is no need to ask all voting members to participate and become experts in a topic they are not interested in. This is actually dangerous (as voting member could take uninformed decisions). Of course, for PSRs with a wide audience, we want all voting members to invest some time.

So here is a proposal that is a bit "out of the box". What about having different "grades" for PSRs:

- Gold PSR: A PSR as it is today: well documented, universally accepted, widely implemented by member projects (think PSR 0-1-2-4... maybe PSR 3)
- Silver PSR: A PSR that targets a subset of projects. Widely implemented amongst project that care for this topic
- Bronze PSR /  Wooden PSR: A PSR that targets only a subset of projects. Not officially accepted by anyone, but already implemented by some members (for instance, an interface providing interoperability between at least 2 projects from 2 different authors could qualify as a Wooden PSR :) ) You get the idea: PHP-FIG should not stop any attempt to increase interoperability between PHP packages. Instead, it should encourage interoperability by any possible means. Wooden PSRs could be a test-bed for implementing projects. When a Wooden PSR has enough projects implementing projects, it can evolve to a Bronze/Silver PSR...

Think about things could have been very different for PSR-Cache if it had started with a set of projects implementing a "bronze PSR"

I've just has the idea, it is far from perfect and I'm sure there is a lot to be discussed. The important parts are that:

- depending on the topic addressed, the process should not be the same
- PHP-FIG should foster interoperability, even for very narrow topics (nothing says PHP-FIG should only address topics that are relevant to all its member)
- we need agility (i.e. the ability to iterate for some member projects without having to wait for 4 years that everybody agrees upon a golden standard)
- PHP-FIG should embrace a bottow-up approach (a few projects implementing a standard and aggregating other projects over time) rather than a top-down approach

++
David.

[Andrew Carter]

I disagree strongly with these statements:

"The topic can be quite obscure for the rest of the PHP community (like Async stuff...)"

"A Promise PSR is really targeting a smaller set of projects."

Asynchronous programming techniques should be familiar to all of the voting reps in this group. These techniques might be a bit different in PHP, but any well trained programmer should be familiar with them.

Besides, this group is focused on interoperability - how can a project know if a proposal affects them or not if they do not even bother to spend a couple of hours reading the meta docs and/or a relevant wikipedia page?

Membership of this group shouldn't be free. We have something like 12 accepted proposals over the course of a few years, it's a tiny commitment to spend a couple of ours looking at each of them over this timespan.

[Andrew Carter]

hours*

-.-

[Cal Evans]

2.

Cheers!

=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/5670BEC0.6030202%40garfieldtech.com.

For more options, visit https://groups.google.com/d/optout.

--

Culture of Respect

How to find, hire, and retain developers

[Tristan Darricau]

For the record, I'm not a voting rep.

For me it's one for two reasons, let me explain:

The first one is project versus people. If I'm voting for myself it can be one. Otherwise, if it's for a project it's 1, because if I'm representing a project I'll ask the rest of the team before voting but... if the project has no interest in async and will likely never use async, why would the project vote on it? And it's not a matter of knowledge, just that why should the project voting in favor or against an interrop interface that he will never use?

The second one is time. Finding enough time to read the documents and having an opinion about it is not an issue. But I talked with a friend yesterday and he kinda said that for him you shouldn't vote before reading all the discussion related to the subject on the mailing list and I kinda agree with him. But reading all the message sent to the ML is quite difficult and time consuming. Maybe it's just because of the format of the ML (I think a forum could help here by having the topics more organized) maybe not.

To sum-up:
- If voting for a project: 1
- If voting for myself and if I have to read all the message sent to the ML every day before voting: 1
- Otherwise: 2

Tristan Darricau

[Andrew Carter]

Tristan,

I genuinely can see now reason why an project will have zero interest in asynchronous PHP.

Even if they are not considering such techniques at the moment, I don't think any sane PHP project can rule out ever having an interest in non-blocking I/O or other async concepts.

The time taken to learn about these things is tiny and should be considered a cost of membership in the group.

[Woody Gilk]

2, not voting rep

--
Woody Gilk
http://about.me/shadowhand

--
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/4935ef1b-28fb-4163-b880-6abaeb4b6138%40googlegroups.com.

[Tristan Darricau]

A lot of application doesn't need these concept. The I/O is often restricted to 3 things: simple file-system access, DB and echo and imho none of them is enough to justify asynchonous. It may change in the future if the project add the integration of a third service using an Http call. But I don't think it's related.

If you are voting on a project behalf you are taking in account the current and planned need of interrop, not whatever could happen in the next 10 years. And if you don't have any async call and don't have any async call in your backlog either I don't think you can honestly be involved in an interrop process. Imagine the question: "What are your needs?", you answer should be something like "I don't know, I'm not interested and I'm not planing to use it".

It's not a matter of tech knowledge but a matter of "Will we ever have any use of that?". But that's valid only in the case of an interrop group for projects (and so where you are voting on a project behalf).

Imho, if you are voting on everything even if you don't are not planning to use it at all because you don't need the feature then you are positioning yourself more like a standard body than an interrop body.

[Matthew Weier O'Phinney]

2, as a voting rep.


--
Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/

[Mike van Riel]

How can I take this poll seriously?

> 'and the rest of us should STFU'
> ‘Voting reps who are too lazy to do more than cast +1 should GTFO’

You seriously bring this down to a black and white ‘STFU' or ‘You’re lazy, GTFO'?

I refuse to partake on such a polarizing and limited poll. And yes, I feel offended: I had missed the voting deadline for PSR-6 but intended to vote +0 as a courtesy to defer my opinion to those more knowledgeable on that area. I refuse to have that diminished to being too lazy. Return when you can come up with a serious poll.

[Alessandro Pellizzari]

First of all: I vote for 2, and am a not a voting rep.


This is my idea: remove +0 votes. Increase quorum to 2/3, and need 50%+1
of the voters to pass.

This means that at least 1/3 of the projects must vote +1 for it to pass.

If many projects have no need or no idea about the Promises PSR, and the
quorum is not met, it means the PSR is not needed (or not enough
projects participate in the FIG), and it does not pass. It can be
proposed again when there will be more interest.


The alternative I was thinking about in the last few days is to leave +0
votes, but require 50%+1 of the total participants (not the voters) for
a PSR to pass, with a 2/3 quorum. Projects that do not vote for 3
consecutive PSR lose their right to vote.

This way you can vote +0 to meet the quorum (and maintain your right to
vote), but only much needed (and agreed on) PSRs pass.

The entrance vote before the discussion should show if there is interest
in the PSR, and alleviate the number of non-passing PSRs, and the ending
vote should prove the discussion has been useful.

Bye.

> --
> 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>.

> 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/bb9d3919-5653-41e8-be84-90a96d6ba2e1%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/bb9d3919-5653-41e8-be84-90a96d6ba2e1%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Josh Lockhart]

Voting rep, I choose #2 with the assumption that learning resources (links?) are provided upon PSR proposal acceptance in the meta doc or something similar.

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/56717D2B.3000601%40amiran.it.

[Phil Sturgeon]

 

1) A Promises spec should be developed and decided on primarily by 
people involved in React, Icicle, Guzzle, and other Promises-using 
projects, and the rest of us should STFU. 
2) All FIG members should become sufficiently versed in Promises as a 
concept (with the help of those with domain knowledge already) to cast 
an informed +1/-1 vote. Voting reps who are too lazy to do more than 
cast +0 should GTFO. 

If everyone can excuse the clearly jovial tone of this wording (I getcha Larry!) then yes, 2. 

There are a lot of reasons other than being lazy that a group might not be able to come to a decision for a vote, but if that keeps happening then it looks like this isn't working out. Right?

The relatively recent additions of meta docs to accompany standards and blogging for the masses (avoiding overly complex CS terms that confuse the average developer like myself) means that nobody should fail to create an opinion either way for an acceptance vote.

Saying "Fuck it I don't cache stuff" should not be a reason to +0. Either the standard looks good and you're confident that raised concerns have been heard, or it's the opposite of that and -1. Shrugs are not helpful.

This is not the only problem that needs to be solved, see my previous wall of text for other suggestions.

[Korvin Szanto]

#2 for me as well, I'm a voting rep

--

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/bc3d0d74-8212-4e14-9b66-0ccb9ff7c1a1%40googlegroups.com.

[Mike van Riel]

On 16 Dec 2015, at 19:25, Phil Sturgeon <pjstu...@gmail.com> wrote:

There are a lot of reasons other than being lazy that a group might not be able to come to a decision for a vote, but if that keeps happening then it looks like this isn't working out. Right?

What isn’t working out? I have read the walls of text but I don’t really understand what problem we are trying to solve here; or at the very least: how addressing this will solve anything.

Is it that we want members to be more involved? Getting rid of abstains will not help; people will just stop voting instead meaning that they will get less involved.

Is it that we feel that votes pass too easily, hence diluting the quality of the work that we deliver?

Why are we even focusing on +0’s? Is this indeed the most important issue that we face? To me it sounds like the conversation has digressed into a detail and that focus on the initial statement by Larry has been lost.

The relatively recent additions of meta docs to accompany standards and blogging for the masses (avoiding overly complex CS terms that confuse the average developer like myself) means that nobody should fail to create an opinion either way for an acceptance vote.

Saying "Fuck it I don't cache stuff" should not be a reason to +0. Either the standard looks good and you're confident that raised concerns have been heard, or it's the opposite of that and -1. Shrugs are not helpful.

To me, PSR-6 and the discussions around it have been confusing and did not inspire me with the confidence that I knew what the quality of what I was voting on was sufficient. The number of concerns addressed, ignored, put up, brought back, put down and sat aside raised far above my level of expertise with the innards of caching. That does mean to me that I cannot in good conscience give a +1 nor a -1. 

And frankly, without trying to get a level of understanding equal to that of Doctrine or Stash; or someone in my community that had a clear level of expertise here I do not see how I could have gained that level. So why is it bad to say: I like the proposal as document and what is described but I cannot attest to the technical accuracy and hence defer that to people who do know. 

Or is it the opinion of others that a -1 is then in order because the standard is apparently too technical in nature?

[Larry Garfield]

My intent was not to offend; rather, the goal of channeling my inner
Phil was to anchor the extremes that had been presented so we could get
a sense for different people's visions for this group. Most who know me
know I don't STFU. :-)

I wasn't thinking of PSR-6 or +0s specifically at all when asking this
question, nor of your vote specifically. Rather, I was trying to get at
your statement "defer my opinion to those more knowledgeable in that
area". Should we be encouraging that, or encouraging getting
knowledgeable enough to not need to defer your opinion?

Those are contradictory goals, but we need to establish a collective
agreement on them as it's rather core to what FIG is and how it operates.

At the moment, it feels like #2 is winning although I've not counted
specifically.

--
--Larry Garfield

[Cees-Jan Kiewiet]

2, voting rep. It will create more involvement in a PSR and a if that means reading up on something and expanding knowledge not just for me but also in the FIG and the community as a whole I can only welcome that. On the other side of the coin, if that means writing up something explaining Promises or doing a couple of hangouts explaining them I'll be up for it. There is no practical use in a standards body deciding something they don't know anything about.

--
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/5671C2BF.1040304%40garfieldtech.com.

[Ben Marks]

Non-voting person here. I want to say that #2 is the right choice (and I get the hyperbolic tone), but I bristle that "+0" equates to "lazy". I think it's essential.

What does abstention mean? It seems a lot of people on this thread assume it means one of two things: that the voting member just wants to be counted as present, and/or that he or she was too lazy to study up. That conclusion itself seems lazy, or at least over-simplified. For one thing, at least the member posted something, as opposed to not bothering to cast a vote. Most importantly: NONE of the markers indicate that a voting member did the necessary homework to understand the topic! We have to trust that members are casting well-informed votes, and we should consider that they have all necessary options to accurately participate, even if that participation is, "I don't know." Removing +0 means that voting members are required to support, oppose, or appear to not participate in the vote at all. Tristan Darricau has a decent point to consider regarding a +1/-1 only approach:

Imho, if you are voting on everything even if you don't are not planning to use it at all because you don't need the feature then you are positioning yourself more like a standard body than an interrop body.

In compromise, perhaps add a bylaw along the lines of, "X number of abstain votes by a member project within X number of votes = expulsion" (though I think this too encourages shoddy +/- 1 voting).

Ben / Magento

[Mike van Riel]

> On 16 Dec 2015, at 20:59, Larry Garfield <la...@garfieldtech.com> wrote:
>
> On 12/16/15 9:01 AM, Mike van Riel wrote:
>>>
>>> (This is a poll for everyone, although please note if you're a voting rep or not as I'm curious if there's a difference.)
>> How can I take this poll seriously?
>>
>>> 'and the rest of us should STFU'
>>> ‘Voting reps who are too lazy to do more than cast +1 should GTFO’
>> You seriously bring this down to a black and white ‘STFU' or ‘You’re lazy, GTFO'?
>>
>> I refuse to partake on such a polarizing and limited poll. And yes, I feel offended: I had missed the voting deadline for PSR-6 but intended to vote +0 as a courtesy to defer my opinion to those more knowledgeable on that area. I refuse to have that diminished to being too lazy. Return when you can come up with a serious poll.
>
> My intent was not to offend; rather, the goal of channeling my inner Phil was to anchor the extremes that had been presented so we could get a sense for different people's visions for this group. Most who know me know I don't STFU. :-)

Sorry about that Larry, I have been unable to discern the light-heartedness in your post. I am afraid that may have been because I’m not used to that style by you (it suits Phil better ;)), that previous posts by various authors about the +0 vote stroke that same tone but then in all seriousness (and this felt as a continuation of that trend), and not unimportantly: a rather foul mood on my behalf.

> I wasn't thinking of PSR-6 or +0s specifically at all when asking this question, nor of your vote specifically. Rather, I was trying to get at your statement "defer my opinion to those more knowledgeable in that area". Should we be encouraging that, or encouraging getting knowledgeable enough to not need to defer your opinion?

I think the devil is in the details; this is also the problem that I have with this poll and the associated discussion. Voting +0 seems to be reduced by some to a simple ‘do not care’ or ‘too lazy’, which is an awfully negative way to approach this and I find it rather condescending towards those that have voted +0 in the past. Heck, I _seldom_ vote +0 but the tone struck at this just makes me feel sad and disappointed. It doesn’t inspire me with confidence that this discussion can be held in a constructive manner.

Mastering the details on some of these topics feels like a challenge. PSR-0 through 4 is easy, that is a matter of having an informed opinion. PSR-6 and PSR-7 is something which I found a lot harder as these are technically deeper topics of which I, personally, found PSR-6’s depth to be out of my comfort zone. I still do not feel that I can explain PSR-6 in detail, which triggers me not to vote +1 specifically but it felt and feels like a solid standard and that made me adverse to voting -1. Which option remains then? Do I want to be a roadblock by not voting (endangering quorum or triggering complaints about a lack of interaction), or vote -1 because _I_ nor the phpDocumentor community can provide an informed opinion? Or would you have expected me to vote +1, even if I do not think that I, or my community, can oversee the consequences enough?

[Larry Garfield]

On 12/17/15 12:09 PM, Ben Marks wrote:
> In compromise, perhaps add a bylaw along the lines of, "X number of
> abstain votes by a member project within X number of votes =
> expulsion" (though I think this too encourages shoddy +/- 1 voting).

There's already a clause for "you can be expelled if you miss X
consecutive votes or all votes within X months, whichever is longer".
(We deliberately kept it a very low bar.) We can easily change that to
say a +0 doesn't count as participation for the purposes of establishing
attendance, if we want a middle-ground on that.

--
--Larry Garfield

[Larry Garfield]

On 12/17/15 1:40 PM, Mike van Riel wrote:
>> I wasn't thinking of PSR-6 or +0s specifically at all when asking this question, nor of your vote specifically. Rather, I was trying to get at your statement "defer my opinion to those more knowledgeable in that area". Should we be encouraging that, or encouraging getting knowledgeable enough to not need to defer your opinion?
> I think the devil is in the details; this is also the problem that I have with this poll and the associated discussion. Voting +0 seems to be reduced by some to a simple ‘do not care’ or ‘too lazy’, which is an awfully negative way to approach this and I find it rather condescending towards those that have voted +0 in the past. Heck, I _seldom_ vote +0 but the tone struck at this just makes me feel sad and disappointed. It doesn’t inspire me with confidence that this discussion can be held in a constructive manner.
>
> Mastering the details on some of these topics feels like a challenge. PSR-0 through 4 is easy, that is a matter of having an informed opinion. PSR-6 and PSR-7 is something which I found a lot harder as these are technically deeper topics of which I, personally, found PSR-6’s depth to be out of my comfort zone. I still do not feel that I can explain PSR-6 in detail, which triggers me not to vote +1 specifically but it felt and feels like a solid standard and that made me adverse to voting -1. Which option remains then? Do I want to be a roadblock by not voting (endangering quorum or triggering complaints about a lack of interaction), or vote -1 because _I_ nor the phpDocumentor community can provide an informed opinion? Or would you have expected me to vote +1, even if I do not think that I, or my community, can oversee the consequences enough?

I agree that it can vary by spec, and in some cases by part of the
spec. For instance, with PSR-7 I spent a great deal of time sussing
through attribute handling, body parsing, mutability vs. immutability,
and so on, because those are areas I know about (through integrating
Symfony components into Drupal) and that I'm particularly interested
in. However, I never did read the RFC on URIs, and didn't get too
involved in all of the nuance there. It's not an area that I know much
about, nor are most of the nuances there relevant to my daily work. I
did, though, keep track of the on-list conversations that Matthew and
Evert were having, and even though I didn't grok all of it I did trust
that they had covered the topic sufficiently, as the topic experts
there. Ideally, that's the OSS way of doing it: Contribute to the parts
you can, trust in those who know more in the parts you can't.

Key in that is:

1) Contributing at least something, even if it's just oversight.
2) Trust in those doing the work that they're doing at least a halfway
decent job.
2) On-list conversations(!!!) so that others can decide if that trust is
justified.

Which I suppose puts me closer to option 2, but not solidly, 100% option
2. Maybe 1.7 or 1.8. :-)

--
--Larry Garfield

[Ben Marks]

There's already a clause for "you can be expelled if you miss X 
consecutive votes or all votes within X months, whichever is longer".   
(We deliberately kept it a very low bar.)  We can easily change that to 
say a +0 doesn't count as participation for the purposes of establishing 
attendance, if we want a middle-ground on that. 

• Agree that there should be a threshold for expulsion of members abstaining from votes over a given period/number of votes
• Disagree that a +0 should be codified as non-participation; rather, too many +0 votes in a given window is an indication that the member is too limited in his or her expertise to provide meaningful input

[Bernhard Schussek]

+1 to what Ben said.

Cheers,

Bernhard

--
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/2f7ab60f-4a54-42f8-bd50-b7952ff51cf0%40googlegroups.com.

[Gary Hockin]

• "Agree that there should be a threshold for expulsion of members abstaining from votes over a given period/number of votes"

Agreed, but does count +0 as abstaining?

• "Disagree that a +0 should be codified as non-participation; rather, too many +0 votes in a given window is an indication that the member is too limited in his or her expertise to provide meaningful input"

Or too busy to provide meaningful input, either way, my question is why does someone who is too limited in their expertise, or too busy to provide meaningful input, have a vote?

G

--
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/216b6093-607a-4939-b038-497e73bb4af9%40googlegroups.com.

[Bernhard Schussek]

On Fri, Dec 18, 2015 at 11:24 AM Gary Hockin <ga...@hock.in> wrote:

Or too busy to provide meaningful input, either way, my question is why does someone who is too limited in their expertise, or too busy to provide meaningful input, have a vote?

Remember that voters in here represent a project, i.e. a group of people. A +0 could be caused by the people in that project not reaching a consensus.

A +0 could also be caused by the voter seeing an equal number of pros and cons. I'd rather translate +0 with "can't decide" instead of "don't care".

I think that +0 votes are very valuable, as they indicate that a PSR may need some more work. -1 OTOH is a clear sign against the current state of a PSR.

Cheers,

Bernhard

[Gary Hockin]

"I think that +0 votes are very valuable, as they indicate that a PSR may need some more work. -1 OTOH is a clear sign against the current state of a PSR."

I would say a +0 isn't indicating a PSR needs more work, it's a "I have no opinion", whereas a -1 is definitely a sign that a PSR needs more work.

--

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/CAHjTTqOECouVYWN_oWyynRRZchoP-V3e5X3h7FrYeT6jmHFQ7g%40mail.gmail.com.

[Andrew Carter]

Agreed - if the opinion is that a PSR needs more work the vote should be a definite '-1'.

[Ben Marks]

why does someone who is too limited in their expertise, or too busy to provide meaningful input, have a vote?

These are not the only two reasons to abstain. I'd expect someone who is too busy to vote to just not vote. That's allowed.

Bottom line: I think the world should be able to look at a table of votes by project and see who voted (+1,+0,-1, [no vote]).

[Derrick Nelson]

"Too busy to vote" is not really a thing. Are you actually too busy to take 3 minutes to vote out of a 2 week voting period? Really?

More likely you mean "too busy to be involved with the proposal enough to feel comfortable voting". Which is perfectly understandable. However, it's also not a very desirable quality for a voting body member. Membership is voluntary, but it isn't whimsical - it does come with responsibility.

Now, if lots of members are finding it hard to keep up, then draft/review phases may need to be lengthened. However, we're seeing members abstaining from voting on proposals years in the making. That's not "too busy", it's "uninterested".

[Ben Marks]

"Too busy to vote" is not really a thing... More likely you mean 'too busy to be involved with the proposal enough to feel comfortable voting'."

This framing is exactly why I strongly support +0 as an option when voting! I was referring to the non-act of not responding to a voting thread. At the very least, +0 shows that the member at least sees that a vote is taking place and can demonstrate that it wasn't missed due to lack of attention.

It is indeed undesirable that a member miss any vote. That's why there are bylaws involving potential expulsion for repeated failure to vote.

[Hari K T]

That's why there are bylaws involving potential expulsion for repeated failure to vote.

Something just in paper.

[Derrick Nelson]

On Saturday, December 19, 2015 at 5:49:01 AM UTC-5, Ben Marks wrote:

"Too busy to vote" is not really a thing... More likely you mean 'too busy to be involved with the proposal enough to feel comfortable voting'."

This framing is exactly why I strongly support +0 as an option when voting! I was referring to the non-act of not responding to a voting thread. At the very least, +0 shows that the member at least sees that a vote is taking place and can demonstrate that it wasn't missed due to lack of attention.

It is indeed undesirable that a member miss any vote. That's why there are bylaws involving potential expulsion for repeated failure to vote.

Voting +0 is equivalent to abstention for all practical purposes that matter to the FIG and its goals.  You aren't doing anyone any good by showing up to the final class to raise your hand during roll call after missing the rest of the semester.  And to be perfectly blunt: nobody cares that you managed not to miss the voting thread.  If you weren't engaged in the proposal for the previous months/years, then you've already missed everything that matters, and showing up in the voting thread to say "I'm here, but I have no idea what you guys are talking about" is wholly unhelpful and unproductive.

The draft/review/voting phases are all long enough to account for members' real lives, commitments, etc.  We aren't talking about members going on vacation and completely missing a PSR from start to finish here.  These things are around for months, if not years.  If you're legitimately too busy to be involved enough in a proposal over that generous amount of time to feel comfortable voting on it, then - quite frankly - you're too busy to be a FIG voting member.  And there's nothing wrong with that; plenty of folks just don't have the time to invest in a group like this, and that's fine.

[Ben Marks]

Voting +0 is equivalent to abstention for all practical purposes that matter to the FIG and its goals

Voting +0 literally IS abstention according to the FIG bylaws. [1] To me, the way you phrased this point sounds like you're saying that +0 is some thing that just came around which the FIG tolerates, which isn't the case.

You aren't doing anyone any good by showing up to the final class to raise your hand during roll call after missing the rest of the semester. And to be perfectly blunt: nobody cares that you managed not to miss the voting thread. If you weren't engaged in the proposal for the previous months/years, and showing up in the voting thread to say "I'm here, but I have no idea what you guys are talking about" is wholly unhelpful and unproductive.

That is absolutely not at all what an abstain vote is, nor is it how an abstain vote comes about. It is entirely reasonable that a project can cast a vote of abstention after having contributed to the discussion. Reference previous votes and and discussions, for example the first PSR-4 vote [2]. Your characterization implies that ezPublish,  AWS, Symfony, and PPI Framework couldn't be arsed to engage with the spec.; I'm sure that's not what you are implying.

The draft/review/voting phases are all long enough to account for members' real lives, commitments, etc. We aren't talking about members going on vacation and completely missing a PSR from start to finish here.

Actually, yeah, that's the kind of thing I'm talking about. A few points:

1. The voting phase is two weeks. I can imagine that someone might get a little too busy and miss a vote in a period this short. It's not a good thing, for sure, and that's why failing to vote is the ONLY criterion for which a member can be expelled. I'm surprised that three votes is a threshold, as opposed to two.
2. A vote of abstention can be arrived at after diligent participation in draft and review phases.
3. The current (LONG) thread is trying to assess whether some of these phases are long enough; that the PhpSpec membership vote couldn't achieve quorum seemed to kick this off.

Again, I think that it's important for a project to VOTE, always. I think it's a legitimate case that a project may want - for whatever rare reason - to demonstrate that they were there for a vote, but were not willing to support or oppose it. Removing the abstain vote means that not casting a vote is ambiguous. (Did they miss it for some reason, could they just not decide a position, or...? Perhaps the exact allowable reason(s) for an abstain vote can be spelled out.). I believe there are four options when it comes to votes: +1, -1, +0, [no vote]. Once the secretary thing is sorted, I'd love to see a table of votes by project linked from the PSR page [3], and these four options should be easy to represent.

Hope I'm clear, and I hope that we're not talking by each other. This seems like the kind of discussion which devolves into pained nuances here online, when it could be quickly and easily sorted in person.

Ben / Magento

[1] http://www.php-fig.org/bylaws/voting-protocol/#voting-protocol

[2] https://groups.google.com/forum/?fromgroups#!searchin/php-fig/PSR-4$20voting/php-fig/NWfyAeF7Psk/_xk2QQuCYsIJ

[3] http://www.php-fig.org/psr/

[Derrick Nelson]

On Saturday, December 19, 2015 at 4:54:56 PM UTC-5, Ben Marks wrote:

Voting +0 is equivalent to abstention for all practical purposes that matter to the FIG and its goals

Voting +0 literally IS abstention according to the FIG bylaws. [1] To me, the way you phrased this point sounds like you're saying that +0 is some thing that just came around which the FIG tolerates, which isn't the case.

You aren't doing anyone any good by showing up to the final class to raise your hand during roll call after missing the rest of the semester. And to be perfectly blunt: nobody cares that you managed not to miss the voting thread. If you weren't engaged in the proposal for the previous months/years, and showing up in the voting thread to say "I'm here, but I have no idea what you guys are talking about" is wholly unhelpful and unproductive.

That is absolutely not at all what an abstain vote is, nor is it how an abstain vote comes about. It is entirely reasonable that a project can cast a vote of abstention after having contributed to the discussion. Reference previous votes and and discussions, for example the first PSR-4 vote [2]. Your characterization implies that ezPublish,  AWS, Symfony, and PPI Framework couldn't be arsed to engage with the spec.; I'm sure that's not what you are implying.

The draft/review/voting phases are all long enough to account for members' real lives, commitments, etc. We aren't talking about members going on vacation and completely missing a PSR from start to finish here.

Actually, yeah, that's the kind of thing I'm talking about. A few points:

1. The voting phase is two weeks. I can imagine that someone might get a little too busy and miss a vote in a period this short. It's not a good thing, for sure, and that's why failing to vote is the ONLY criterion for which a member can be expelled. I'm surprised that three votes is a threshold, as opposed to two.
2. A vote of abstention can be arrived at after diligent participation in draft and review phases.
3. The current (LONG) thread is trying to assess whether some of these phases are long enough; that the PhpSpec membership vote couldn't achieve quorum seemed to kick this off.

Again, I think that it's important for a project to VOTE, always. I think it's a legitimate case that a project may want - for whatever rare reason - to demonstrate that they were there for a vote, but were not willing to support or oppose it. Removing the abstain vote means that not casting a vote is ambiguous. (Did they miss it for some reason, could they just not decide a position, or...? Perhaps the exact allowable reason(s) for an abstain vote can be spelled out.). I believe there are four options when it comes to votes: +1, -1, +0, [no vote]. Once the secretary thing is sorted, I'd love to see a table of votes by project linked from the PSR page [3], and these four options should be easy to represent.

Hope I'm clear, and I hope that we're not talking by each other. This seems like the kind of discussion which devolves into pained nuances here online, when it could be quickly and easily sorted in person.

Here are the reasons I can think of why a member might be tempted to vote +0, and why I don't think it's a good idea in each case.  Hopefully this clears up any nuances that you're absolutely correct about:

1. To mean "I was too busy".  The member has not done her due diligence, and this is a sign of poor engagement.  A +0 here is, for all practical purposes, indistinguishable from a [no vote], which is something we should be strongly discouraging.  We want members to be engaged enough that they are never too busy to follow a proposal.  As well, draft/review/voting phases should all be long enough that they can't be used as an excuse here either.

2. To mean "I don't know enough to cast an informed vote".  Either the member has not done her due diligence, or the other members have not done their part in helping her understand the measure and concepts.  Both reasons are better resolved through improving engagement all around than explicitly allowing a +0 to account for poor engagement.

3. To mean "I can't decide".  The member has done her due diligence, but still can't make up her mind.  I contend that this should actually be a -1, not a +0.  Everything becomes much easier if you view -1 as "I don't explicitly support passing this measure" instead of "I explicitly support rejecting this measure".  It's not actually as subtle of a semantic difference as it appears at first glance.  It's the same distinction that divides guilty vs. not guilty in jury deliberation (not guilty does NOT mean innocent), atheism vs. agnosticism, etc.

4. To mean "I don't care".  The member has done her due diligence, but is simply neutral about whether the measure passes or fails.  This is a problematic from an empathy point of view.  While a member may not personally be invested in a particular measure, she should still have an opinion, based on the quality of the measure itself and whether it would work well for those who are invested.

5. To mean "I don't really support this measure, but -1 seems too harsh".  The member is essentially using +0 as a soft -1, because of the negative connotations that surround -1.  This is problematic both because the member misrepresented her actual vote, and because with the current bylaws, a +0 actually indirectly aids in the passing of a measure due to quorum and simple majority rules.

[Ben Marks]

Perfect, thank you. I believe that the differences of opinion have been thoroughly and objectively stated, and whoever may decide on this has what they need.

+1 for clarity!

[Paul M. Jones]

> On Dec 14, 2015, at 07:30, Paul M. Jones <pmjo...@gmail.com> wrote:
>
>
>> On Dec 14, 2015, at 07:00, Andrew Carter <andrewca...@gmail.com> wrote:
>>
>> From the voting on the Reddit thread started by pmjones, it is looking very much like that community want FIG to fill the role of a userland standards group.
>>
>> https://www.reddit.com/r/PHP/comments/3wownq/how_do_you_see_the_phpfig/
>>
>> Almost all of the up-voted comments are pushing for pmjones's third option and almost all of the down-voted are pushing for his first.
>>
>> I know there are better ways to conduct a community survey, but it does seem as though the opposition to FIG being a general standards group is mainly internal (even if it wasn't always).
>
> Beware of premature speculation; it's not even been 24 hours. Let it get closer to 3 days.

After two weeks, I think we have some useful responses to work with. I think the entire thread bears reading:

https://www.reddit.com/r/PHP/comments/3wownq/how_do_you_see_the_phpfig/

Thoughts?


--
Paul M. Jones
pmjo...@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

[Larry Garfield]

On 12/29/2015 01:39 PM, Paul M. Jones wrote:
>> On Dec 14, 2015, at 07:30, Paul M. Jones <pmjo...@gmail.com> wrote:
>>
>>
>>> On Dec 14, 2015, at 07:00, Andrew Carter <andrewca...@gmail.com> wrote:
>>>
>>> From the voting on the Reddit thread started by pmjones, it is looking very much like that community want FIG to fill the role of a userland standards group.
>>>
>>> https://www.reddit.com/r/PHP/comments/3wownq/how_do_you_see_the_phpfig/
>>>
>>> Almost all of the up-voted comments are pushing for pmjones's third option and almost all of the down-voted are pushing for his first.
>>>
>>> I know there are better ways to conduct a community survey, but it does seem as though the opposition to FIG being a general standards group is mainly internal (even if it wasn't always).
>> Beware of premature speculation; it's not even been 24 hours. Let it get closer to 3 days.
> After two weeks, I think we have some useful responses to work with. I think the entire thread bears reading:
>
> https://www.reddit.com/r/PHP/comments/3wownq/how_do_you_see_the_phpfig/
>
> Thoughts?

I just went through and read the thread. I didn't do a formal count of
comments (difficult because many of them are "me too" comments where
it's difficult to know if they should count or not), but there's
definitely a trend I saw (and it's the same one that was there at the
beginning):

1) The highest-rated comments are those that say "it's 2, moving to 3,
and that's a good thing." I'd say that's the most common and most
highly rated position.

2) The really negative comments are all further down. Really they don't
start until halfway down the page.

3) One of the main things people object to with FIG (but granted not the
only) is precisely this confusion. "They say they're for-them-only, but
the messaging from lots of people is that FIG standards==modern
professional PHP. Stop being two-faced!"

4) PSR-1/2 are still controversial, as is PSR-6. But I think *every*
PSR we've passed has someone in that thread that hated it for one reason
or another. Yes, even PSR-0/4.

----------

I've highlighted a number of quotes (with references) below that I think
are particularly relevant.

A very succinct summary of FIG's history:

"They started off trying to be #3 accidentally ... quickly backtracked
into #2 ... but have since become a defacto #3 ..."
https://www.reddit.com/r/PHP/comments/3wownq/how_do_you_see_the_phpfig/cxynin7

A pretty good summary of the current status within FIG. (I don't know
which of us gets to wear the blue uniforms):

"I truely believe as a whole they lie somewhere between 1 and 2 currently.
I really want them to become 3.
Here is how I see it. There are those within the PHP-FIG that think it
should become a Userland Standards Group. There are those within PHP-FIG
that do not. There will be a period of civil war within the group where
people will pick their sides. I really do think it is an A or B choice."
https://www.reddit.com/r/PHP/comments/3wownq/how_do_you_see_the_phpfig/cxype3t

On the need for a standards body:

"If FIG doesn't wanna be 3, then it'd be nice if somebody would."
https://www.reddit.com/r/PHP/comments/3wownq/how_do_you_see_the_phpfig/cxy7zvy

And here's a very well-stated point on why FiG inevitably ends up as #3,
whether we want it to or not, simply because of the network effect:

"The thing is, imho, that most PSRs are meant as #2 but as soon as the
major projects are involved and agree, it becomes a standard defacto
because people are using these projects: If the major frameworks are
using PSR-7 and you don't want to use PSR-7, you have to use your own
framework? If the major cache libraries are using PSR-6 and you don't
want to use PSR-6, you have to write your own cache library?"
https://www.reddit.com/r/PHP/comments/3wownq/how_do_you_see_the_phpfig/cxyqqv5

----------

Once Symfony, Zend, Laravel, and Drupal agree on something, it's a PHP
standard. Whether you want it to be or not, it becomes one. And if
PHPStorm, NetBeans, and Eclipse offer automated tooling for it, it
becomes a standard, whether you want it to be or not. The network
effect means that it's impossible, in practice, for this group to be
"just for us", no matter how much we or anyone else want that to be the
case. Plus, it seems from the thread above that there's a very large,
very vocal population that wants us to become/accept that fact and
broader role; even some of our detractors do, because it's our refusal
to do so that is causing problems for them.

--Larry Garfield

[Paul M. Jones]

> On Dec 31, 2015, at 11:38, Larry Garfield <la...@garfieldtech.com> wrote:
>
> Once Symfony, Zend, Laravel, and Drupal agree on something, it's a PHP standard.

Well then, I guess everyone else can tender their resignations now. /me rolls eyes

[Larry Garfield]

On 12/31/2015 04:21 PM, Paul M. Jones wrote:
>> On Dec 31, 2015, at 11:38, Larry Garfield <la...@garfieldtech.com> wrote:
>>
>> Once Symfony, Zend, Laravel, and Drupal agree on something, it's a PHP standard.
> Well then, I guess everyone else can tender their resignations now. /me rolls eyes

Your sarcasm not withstanding, do you disagree with the underlying concept?

Once a majority of significant projects adopt a certain convention, that
convention becomes the de facto rule for most other projects, too. Take
PSR-3 as an example. If you want your logger library to be usable by
Symfony developers and Zend devleopers, you need it to implement PSR-3
(even if by an adapter). Since you know both Symfony and Zend can offer
a PSR-3 compatible logger, if you develop a library that should log
things then having it take a LoggerInterface dependency makes it
compatible with both Symfony and Zend. And, along the way, makes it
easier to integrate into Drupal 8.

If you want to swap out Monolog for X in Symfony, it's easy to do iff
it's using PSR-3. If you want to integrate your random library into
Symfony, it's easier if it's using PSR-3. s/Symfony/any other
PSR-3-using system/.

That lower barrier to swappability is precisely the point of a spec like
PSR-3.

But that does mean that, over time, non-PSR-3-using logger libraries are
at an inherent disadvantage, and would need an adapter. And
non-PSR-3-using libraries-to-be-logged are at an inherent disadvantage,
and would need adapters. You could write adapters to everything (as was
done in the past), or just an adapter to PSR-3. At which point... why
not just use PSR-3?

Similarly, when PHPStorm added PSR-1/2 as their default coding style
because that's what FIG put out, that means the default coding style for
any new project is PSR-1/2. It takes an extra active step for someone
to NOT use it (as someone who now switches between PSR-2 and Drupal
coding styles regularly, I can attest this is a very annoying step), and
we know from ample research that most people will use whatever defaults
they're given. (cf, "Nudge".) That means PSR-2 becomes not "the FIG's
coding standard" but "PHP's coding standard", even without any active
work by FIG members to make that happen. (Although there is such effort
going on, too.)

That's the network effect I mean, and it's why FIG's reach and influence
is larger and wider than "just" the voting member projects, no matter
how much some people (both inside and outside FIG) wish that weren't the
case.

Do you deny this fact?

--Larry Garfield

[Paul M. Jones]

> On Jan 1, 2016, at 16:25, Larry Garfield <la...@garfieldtech.com> wrote:
>
> On 12/31/2015 04:21 PM, Paul M. Jones wrote:
>>> On Dec 31, 2015, at 11:38, Larry Garfield <la...@garfieldtech.com> wrote:
>>>
>>> Once Symfony, Zend, Laravel, and Drupal agree on something, it's a PHP standard.
>> Well then, I guess everyone else can tender their resignations now. /me rolls eyes
>
> Your sarcasm not withstanding, do you disagree with the underlying concept?

...

> Do you deny this fact?

Do network effects exist? Sure. Does that prove that "Once Symfony, Zend, Laravel, and Drupal agree on something, it's a PHP standard" ? No.

[Larry Garfield]

On 01/01/2016 06:02 PM, Paul M. Jones wrote:
>> On Jan 1, 2016, at 16:25, Larry Garfield <la...@garfieldtech.com> wrote:
>>
>> On 12/31/2015 04:21 PM, Paul M. Jones wrote:
>>>> On Dec 31, 2015, at 11:38, Larry Garfield <la...@garfieldtech.com> wrote:
>>>>
>>>> Once Symfony, Zend, Laravel, and Drupal agree on something, it's a PHP standard.
>>> Well then, I guess everyone else can tender their resignations now. /me rolls eyes
>> Your sarcasm not withstanding, do you disagree with the underlying concept?
> ...
>> Do you deny this fact?
> Do network effects exist? Sure. Does that prove that "Once Symfony, Zend, Laravel, and Drupal agree on something, it's a PHP standard" ? No.

I cited those as four of the biggest, and therefore most
network-effect-influencing, PHP projects. WordPress is of course
larger, but there's far less network effect there; Drupal used to have
far less, too. It was not a statement that those are the only four PHP
projects that matter, rather that once "big players" come to a consensus
on something that tends to make it a de facto requirement for everyone
else. (Even Drupal has gotten some pressure over not adopting PSR-2,
both internal and external.) Or to quote a famous ambassador, "The
avalanche has started; it is too late for the pebbles to vote."[1]

--Larry Garfield

[1] Nerd points for the first person who can identify the speaker.

[Richard Griffith]

Speaking as one of the pebbles, an avalanche is a pretty good sign that things are going down hill, fast.

Re: [1] For the record, B5 was a ground breaking production, that used some revolutionary new techniques made possible by the Video Toaster, which in turn depended on the Amiga line of computers. I spent a lot of time working in that area at the time. Today, all that tech is long gone. The lesson here was that the important players in any given niche can change fast. What seems perfect today may not be viable tomorrow. Also, Kosh was a jerk.

I do have to agree with Paul M. Jones. Further, I have to observe, that elitist attitude, dismissive of the pebbles, is one reason the community at large might view the FIG as a self-serving circle jerk. An opinion is judged more by who expressed it than on its actual merits. Gravity, not logic, nor experience, determines the outcome.

Just what it looks like from here,

-Richard 

[Woody Gilk]

I have to agree with Paul and Richard on this, Larry. Just because Drupal, Symfony, and Zend have a majority share in the total number of PHP websites, it does not mean that these projects necessarily represent thought leaders. Just as an example... Symfony still has no release that uses PSR-7. At the same time Paul has been instrumental in promoting a PSR-7 middleware pattern that has been adopted by at least 20 separate open source projects [1], which represents a significant network effect. Drupal 8 depends on Zend components. (Does that mean Drupal is less valuable than Zend?)

To effective dismiss the value of every project except Symfony, Zend, and Drupal hugely undermines the value of FIG is detrimental to both FIG and the community's perception of FIG. And quite frankly, it makes you look like a jerk.

Personally I would see this as a pretty serious political blunder and would expect an apology for the FIG for effectively dismissing the fundamental value of the organization. Your statement could be perceived as the FIG existing simply to justify the desires of these three projects and naught else.

[1]: https://packagist.org/packages/relay/relay/dependents

--
Woody Gilk
http://about.me/shadowhand

--

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/29832ffc-af9f-4390-8c5a-eac953137b51%40googlegroups.com.

[Christopher Pitt]

Richard: thanks for speaking up. It's refreshing to hear more from the community. I do not think Larry's point was elitist: are you referring to something in the reddit thread, or prior to Larry's comment (Jan 1st)?

Woody: I think we're getting off point here. The topic is "should we become a PHP standards group or stay a framework interoperability group" [1]. What I read from Larry is this idea that once some far-reaching projects adopt the interoperability recommendations, they tend to become PHP standards by another name. I don''t think it's healthy to push that sentiment in the direction of "these are the only projects that matter". That's not what was said. 

Let's all take a step back and return to the topic: [1]

[Woody Gilk]

On Fri, Jan 1, 2016 at 11:48 PM, Christopher Pitt <cgp...@gmail.com> wrote:

Woody: I think we're getting off point here.

I don't think so at all. As I stated, Larry's comments directly undermine the idea that FIG is the "PHP Standards Body", which is a concept I fully support.

[Woody Gilk]

On Fri, Jan 1, 2016 at 11:48 PM, Christopher Pitt <cgp...@gmail.com> wrote:

the direction of "these are the only projects that matter"

And FWIW, that's exactly what Larry implied, implicitly or explicitly. A stance which I do not support at all, nor do I think that the rest of FIG (outside of Zend, Symfony, and Drupal) support.

[Larry Garfield]

On 01/02/2016 12:36 AM, Woody Gilk wrote:

On Fri, Jan 1, 2016 at 11:48 PM, Christopher Pitt <cgp...@gmail.com> wrote:

the direction of "these are the only projects that matter"

And FWIW, that's exactly what Larry implied, implicitly or explicitly. A stance which I do not support at all, nor do I think that the rest of FIG (outside of Zend, Symfony, and Drupal) support.

No, Woody, that's not what I implied at all.  I said that there is a network effect (which no one has disputed), so once several large players start doing something it has far-reaching implications beyond just those projects.  I cited 4 large and influential projects, all of whom are FIG members.  Note that one of them doesn't use PSR-2 (Drupal), and yet there is pressure for it to do so "because everyone else is doing it".

That network effect is present regardless of whether the thing being done is good or bad.  I at no point claimed that only those projects "necessarily represent thought leaders."  Your words, not mine.

> To effective dismiss the value of every project except Symfony, Zend, and Drupal

Which is not what I did. At all.  For one, you're forgetting Laravel (which I also mentioned).  For another, I did not dismiss the value of other projects.  I pointed out that what large projects do, others often tend to follow.  That *does not mean those other projects are not valuable*.  At all.  Guzzle, eg, is incredibly valuable and influential, and contrary to your claims I am certainly not going to dismiss the impact of Relay, or Slim 3, or Guzzle 6, or Zend Expressive in pushing PSR-7.  The groundswell around PSR-7 has been great to see.

> Symfony still has no release that uses PSR-7.

Untrue.  Symfony released a PSR-7 bridge for HttpFoundation rather quickly.  It hasn't replaced HttpFoundation with PSR-7 yet, true, but it does support PSR-7 request/response objects.

> Drupal 8 depends on Zend components. (Does that mean Drupal is less valuable than Zend?)

... Really dude?  Really?  Do I need to bother responding to that?

If your beef is that I used (shock) an example for the presence of a network effect that happened to offend you, then I'm sorry if you couldn't see past the example.  I will accept in advance your apology for making up things I didn't even remotely say.

--Larry Garfield

[Woody Gilk]

On Sat, Jan 2, 2016 at 1:01 AM, Larry Garfield <la...@garfieldtech.com> wrote:
>
>
> > To effective dismiss the value of every project except Symfony, Zend, and Drupal
>
> Which is not what I did. At all.

But you also said:

> Once Symfony, Zend, Laravel, and Drupal agree on something, it's a PHP standard. Whether you want it to be or not, it becomes one.

Which could certainly be construed as dismissing every other project.

And FWIW, I did not include Laravel because it stands almost
exclusively on the back of other projects, Symfony in particular.
Purely my own personal opinion, but I have yet to see Laravel be a
thought leader in any way within the PHP ecosystem.

[Christopher Pitt]

I have yet to see Laravel be a thought leader in any way within the PHP ecosystem. 

Well shit. If Larry's words could be construed as dismissive, that is an axe to the face. How about we get back on topic, gents? 

[Woody Gilk]

Chris, luckily I am not a representative.

On Sat, Jan 2, 2016, 1:25 AM Christopher Pitt <cgp...@gmail.com> wrote:

I have yet to see Laravel be a thought leader in any way within the PHP ecosystem. 

Well shit. If Larry's words could be construed as dismissive, that is an axe to the face. How about we get back on topic, gents? 

--

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/a20386b2-0f60-45f5-b3c6-86e7b23b1baa%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Christopher Pitt]

I don't think one needs to be a representative to show some respect for the work of others. Nobody is dismissing every project. I'm sure Larry can confirm that in his own words (if it has not been abundantly obvious so far). Let's steer away from this and back onto the main topic, please?

[Richard Fussenegger]

I think that the PHP-FIG should stay as what it is, framework only. However, a new group could be created (e.g. PHP-STD) that applies an IETF RFC comparable system. The main problem of the FIG is imho that it works like the ISO and other standardization bodies, whereas an IETF RFC based system has many advantages compared to them and works well for huge communities. In other words, for me, the FIG is #1 and #2 and that is fine if it would really be that and only that. #3 cannot coexist with #1 and therefor needs a system that is better suited for huge communities like the PHP community.

The acceptance of such a new group would be the main problem. However, it would work if it finds enough supporters (including the blessing of some big names of the community).