--
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.
- 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.
--
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.
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CANeXGWWOAfQPNrZ_WsOkRBJBSg1pCVa%3DbpsD1QQ4raXZiQ65hQ%40mail.gmail.com.
--Larry Garfield
@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)...
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
--
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.
--
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.
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/236b7f83-543e-4e8b-b85e-1d8bb29503c2%40googlegroups.com.
--
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.
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.
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.
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.
A blog of a good idea, I'm happy to help with creation and posts.
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, 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, 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).
--
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.
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.
--
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.
--
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.
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.
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.
--
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.
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?
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.
--
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.
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.
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.
--
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.
--
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.
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?
--
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.
why does someone who is too limited in their expertise, or too busy to provide meaningful input, have a vote?
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".
"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'."
That's why there are bylaws involving potential expulsion for repeated failure to vote.
"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, 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.
Voting +0 is equivalent to abstention for all practical purposes that matter to the FIG and its goalsVoting +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:
- 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.
- A vote of abstention can be arrived at after diligent participation in draft and review phases.
- 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.
--
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.
Woody: I think we're getting off point here.
the direction of "these are the only projects that matter"
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.
I have yet to see Laravel be a thought leader in any way within the PHP ecosystem.
Chris, luckily I am not a representative.
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.