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.