Membership cleanup: only one project per representative

[Beau Simensen]

I would like to see the representatives of the following sets of projects nominate just one of their projects to remain on the list of member projects:

• Assetic or Buzz, Kris Wallsmith
  
• Aura Project or Solar Framework, Paul M. Jones
  
• Composer or Packagist, Jordi Boggiano
  
• Wikibase or Semantic MediaWiki, Jeroen De Dauw
  

The other project may be free to make an additional submission to join as a member project if it still meets the criteria. This makes more sense for some sets of projects than others and we should probably take them on a case-by-case basis as each project decides it wants to be request membership.

We have no bylaws for this process specifically, but given how things are setup I would imagine that the current representative should be able to send an email stating something along the lines of:

"Please remove [Project B] from the membership list as it is already being represented by [Project A]'s membership."

This has been discussed in the past. We can discuss if more if needed, but I would hope that this would be a simple process that won't require rounds of back-and-forth.

[Philip Sturgeon]

+1 here. I've said the same before I think.

We are admitting projects, not people. Therefore only one project at a time. 

If those projects have the same BDFL then we can perhaps suggest there is no need to add that 2nd project, but if they do not share a BDFL and that supposed BFL has said multiple times that he is not the damn BDFL then that project should be fine to come on in.

For example, Kris can pick Assetic or Buzz. He won't be adding Buzz as a 2nd group because he owns Buzz. If somebody else takes over Buzz, that new author could probably come on in and represent that.

Simple enough?

[Paul M. Jones]

On Oct 13, 2014, at 12:10 PM, Philip Sturgeon <pjstu...@gmail.com> wrote:

> We are admitting projects, not people. Therefore only one project at a time.

I've stated elsewhere that that was not quite the originating idea; it is a shorthand that I believe has become misunderstood.

Persons vote on behalf of a project they represent; a person has to represent a project so that they have some skin in the game. It is persons who vote, not projects per se. If a person happens to have a significant influence over more than one project, that project is thereby counted in their vote.


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

Modernizing Legacy Applications in PHP
http://mlaphp.com

[Kayla Daniels]

Obviously, I'm not a voting member, but I am very much in favor of this idea. 

This group is about interoperability between frameworks/packages/projects. Therefore, each member project should have a vote. If two projects have the same BDFL, that vote can be consolidated until such time that said BDFL hands off one of the projects to another person. Then, the second project can have it's own representation. 

[Paul M. Jones]

On Oct 13, 2014, at 12:17 PM, Kayla Daniels <kayl...@gmail.com> wrote:

> This group is about interoperability between frameworks/packages/projects. Therefore, each member project should have a vote. If two projects have the same BDFL, that vote can be consolidated until such time that said BDFL hands off one of the projects to another person. Then, the second project can have it's own representation.

This is part of the point that I'm getting at. It is the persons who vote, not the projects. That what were previously 2 votes from 2 different projects, can be consolidated into a single vote shared between them by virtue of the person "running" the project, illustrates this.

[Korvin Szanto]

> If a person happens to have a significant influence over more than one project, that project is thereby counted in their vote.

This is not resonating with me, how do we quantify "significant
influence"? Wouldn't an influencer be likely to join other like minded
projects and influence them? This sounds like a fast track to lopsided
representation.

[Paul M. Jones]

/me nods

Maybe. My concern, such as it is, is to pre-empt at least the appearance of one person or a small group coordinating their votes to the detriment of the whole.

[Korvin Szanto]

> pre-empt at least the appearance of one person or a small group coordinating their votes to the detriment of the whole.

If I wanted to silence a project, I could just join that project and
argue my influence is significant :)
I'm tracking on this quite closely because I'd really like to
contribute to the League and some current member projects, if my
membership is going to prevent me from doing so I will resign.

> --
> 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/F9EA7103-BAE6-4244-8333-B548AC765928%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.

[Kayla Daniels]

It was my understanding that persons voted on behalf of the projects. If a person is the BDFL, then they're conveying their opinion. If the person is a representative of a group that has no BDFL, then they are conveying the opinion of the group they represent. So, it is projects that vote, through the mouth of their representative. 

[Paul M. Jones]

On Oct 13, 2014, at 12:40 PM, Kayla Daniels <kayl...@gmail.com> wrote:

> It was my understanding that persons voted on behalf of the projects. If a person is the BDFL, then they're conveying their opinion. If the person is a representative of a group that has no BDFL, then they are conveying the opinion of the group they represent. So, it is projects that vote, through the mouth of their representative.

Is it your position, then, that two different projects represented by the same person should get two separate votes from that same representative?

[Alexander Deruwe]

On Oct 13, 2014, at 12:10 PM, Philip Sturgeon <pjstu...@gmail.com> wrote:

> We are admitting projects, not people

On Mon, Oct 13, 2014 at 7:40 PM, Kayla Daniels <kayl...@gmail.com> wrote:
> So, it is projects that vote, through the mouth of their representative.

One representative per project for administrative purposes, but it
should be the project that votes. So either allow a single
representative to represent two (or more) projects and have two (or
more) votes, or put in place a restriction that a representative can
only represent one project. Influence is called lobbying and is hard
to regulate ... :)


Alexander

[Pádraic Brady]

On 13 October 2014 18:40, Kayla Daniels <kayl...@gmail.com> wrote:

It was my understanding that persons voted on behalf of the projects. If a person is the BDFL, then they're conveying their opinion. If the person is a representative of a group that has no BDFL, then they are conveying the opinion of the group they represent. So, it is projects that vote, through the mouth of their representative. 

Thus sayeth the membership bylaw ;).
 

On Monday, October 13, 2014 1:19:57 PM UTC-4, pmjones wrote:

On Oct 13, 2014, at 12:17 PM, Kayla Daniels <kayl...@gmail.com> wrote:

> This group is about interoperability between frameworks/packages/projects. Therefore, each member project should have a vote. If two projects have the same BDFL, that vote can be consolidated until such time that said BDFL hands off one of the projects to another person. Then, the second project can have it's own representation.

This is part of the point that I'm getting at.  It is the persons who vote, not the projects. That what were previously 2 votes from 2 different projects, can be consolidated into a single vote shared between them by virtue of the person "running" the project, illustrates this.

 

That said, the membership bylaw doesn't apply retrospectively where we already had multiple projects with a single representative, so effectively in those few cases the representative votes and not the project (otherwise we would logically need to grant them two votes). The mess that makes in our brains explains this thread.

Paddy

--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative

[Taylor Otwell]

I think this is an important point and the idea of "influence" is particularly important.

For example, assume person X has two libraries and gives up "BDFL" status on one project to a friend who has no prior FIG involvement. My concern would be person X basically telling their friend how to vote on a given proposal, especially if the new project manager is not familiar with FIG and does not want to invest the time to read the proposals. Now person X is effectively getting two votes.

[Pádraic Brady]

I have no problem with us just sending the request to each of the mentioned representatives rather than creating a red tape nightmare out of it unless absolutely needed.

--
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/CAAa_vJ%3D-hynZb4DdC62jKQZVLtm4yT2ez_6Fm%3DRkU6P5e6XN3g%40mail.gmail.com.

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

--

[Larry Garfield]

On 10/13/14, 12:15 PM, Paul M. Jones wrote:
>
> On Oct 13, 2014, at 12:10 PM, Philip Sturgeon <pjstu...@gmail.com> wrote:
>
>> We are admitting projects, not people. Therefore only one project at a time.
>
> I've stated elsewhere that that was not quite the originating idea; it is a shorthand that I believe has become misunderstood.
>
> Persons vote on behalf of a project they represent; a person has to represent a project so that they have some skin in the game. It is persons who vote, not projects per se. If a person happens to have a significant influence over more than one project, that project is thereby counted in their vote.

As has been stated elsewhere, Paul, it doesn't matter what the
originating idea was 5+ years ago. The bylaws NOW are clear: We admit
projects, and the projects name a representative.

If you don't like that, propose a bylaw change. But stop mis-stating
what is currently our written and voted-on policy.

--Larry Garfield

[Jordi Boggiano]

On 13/10/2014 16:36, Beau Simensen wrote:
> I would like to see the representatives of the following sets of
> projects nominate just one of their projects to remain on the list of
> member projects:
>

> * Assetic or Buzz, Kris Wallsmith
> * Aura Project or Solar Framework, Paul M. Jones
> * Composer or Packagist, Jordi Boggiano
> * Wikibase or Semantic MediaWiki, Jeroen De Dauw

>
>
> The other project may be free to make an additional submission to join
> as a member project if it still meets the criteria. This makes more
> sense for some sets of projects than others and we should probably take
> them on a case-by-case basis as each project decides it wants to be
> request membership.
>
> We have no bylaws for this process specifically, but given how things
> are setup I would imagine that the current representative should be able
> to send an email stating something along the lines of:
>
> "Please remove [Project B] from the membership list as it is already
> being represented by [Project A]'s membership."

Disclaimer: Did not read the rest of thread due to lack of time

Feel free to boot Packagist off the list. It's kind of under the
Composer umbrella anyway so I never took notice but if people view it as
two then get rid of it :)

Cheers

--
Jordi Boggiano
@seldaek - http://nelm.io/jordi

[Larry Garfield]

Thanks, Jordi.

https://github.com/php-fig/php-fig.github.com/pull/121

Someone merge, please.

--Larry Garfield

[Paul M. Jones]

On Oct 13, 2014, at 6:43 PM, Larry Garfield <la...@garfieldtech.com> wrote:

> The bylaws NOW are clear: We admit projects, and the projects name a representative.

I went back and re-read the membership bylaw, and (if one takes into account the historical narrative I've presented) the bylaw as written seems congruent with that narrative. That's one reason I was not against it when it was voted in. ;-)

> If you don't like that, propose a bylaw change.

I've been thinking about this since you mentioned it; it might be enough merely to add a preamble with the history behind the membership rules, and that would add the proper context for reading the bylaw properly.

[Beau Simensen]

On Tuesday, October 14, 2014 3:13:46 PM UTC-5, pmjones wrote:

On Oct 13, 2014, at 6:43 PM, Larry Garfield <la...@garfieldtech.com> wrote:

> The bylaws NOW are clear: We admit projects, and the projects name a representative.

I went back and re-read the membership bylaw, and (if one takes into account the historical narrative I've presented) the bylaw as written seems congruent with that narrative. That's one reason I was not against it when it was voted in. ;-)


> If you don't like that, propose a bylaw change.

I've been thinking about this since you mentioned it; it might be enough merely to add a preamble with the history behind the membership rules, and that would add the proper context for reading the bylaw properly.

So I'm confused. Are you in favor of removing multiple projects or no? If not, can you explain why you would object to removing Solar from the Aura / Solar pair?

I don't understand why it makes sense for us to have any representative listed with multiple project names. The project is the member, not the pair or the representatives themselves. Listing more than one project per voting representative seems wrong based on everything we currently have written about membership / voting representatives.

At this point, we're down to just three exceptions:

• Assetic or Buzz, Kris Wallsmith
  
• Aura Project or Solar Framework, Paul M. Jones
  

[Philip Sturgeon]

On Monday, October 13, 2014 6:44:01 PM UTC-5, Larry Garfield wrote:

As has been stated elsewhere, Paul, it doesn't matter what the
originating idea was 5+ years ago.  The bylaws NOW are clear: We admit
projects, and the projects name a representative.

If you don't like that, propose a bylaw change.  But stop mis-stating
what is currently our written and voted-on policy.

--Larry Garfield

This. 100 times this.

I am nothing to do with the FIG, other than being a voice for what PyroCMS wanted. While I was project lead for PyroCMS, I would be a strong voice in that decision, but I would obviously consult the team and sometimes even ask the community. At the end of the day, the structure that was PyroCMS made the decisions, and I would make a vote as the final response.

I represent PyroCMS and its interests. PSR-4 was in PyroCMS' interests. 

It's always been PyroCMS, not just "Phil Sturgeon, and I guess PyroCMS seems like a good excuse to have him here."

That is how this group should work. If you work on multiple things then thats just dandy.

Symfony/Silex was a little different, as Silex is really part of the Symfony network. 

PyroCMS is releasing another product. Streams. I would never suggest that Streams had another vote, even if was insanely popular in its own right and they picked another contributor to run that.

But, as with Pyro and the League, then have sweet FA to do with each other, other than I am loosely connected to both. 

Thats a fairly clear distinction, and its what our bylaws say right now.

Change the bylaws, or get with the times.

Projects. Not people.

[Paul M. Jones]

On Oct 14, 2014, at 3:34 PM, Philip Sturgeon <pjstu...@gmail.com> wrote:

> Projects. Not people.

It doesn't actually say that in the bylaw.

[Daniel Ribeiro]

I'm not a voting member, but I've been following this discussion closely.

On Wed, Oct 15, 2014 at 6:55 AM, Paul M. Jones <pmjo...@gmail.com> wrote:

> Projects. Not people.

It doesn't actually say that in the bylaw.

Paul, with all do respect, your stubbornness is quite annoying. If you open the membership bylaw, the first phrase states exactly what Phil is saying:

The membership of the PHP Framework Interoperability Group (PHP-FIG) is comprised of Member Projects. This bylaw defines the rules and rights of membership.

Can we get over our egos and move on?

Daniel Ribeiro

http://danielribeiro.org

[Pádraic Brady]

On Wednesday, October 15, 2014, Paul M. Jones <pmjo...@gmail.com> wrote:

On Oct 14, 2014, at 3:34 PM, Philip Sturgeon <pjstu...@gmail.com> wrote:

> Projects. Not people.

It doesn't actually say that in the bylaw.

Actually, that's exactly what it says which was very much intentional when I wrote it. It also defines "voting representative" just to differentiate between the role of projects as members and people as reps only.

The bylaw is also not applicable retrospectively, also intentional, as a nod to existing members of the day which include a non-project in the form of Cal Evans as "community representative", for example.

Paddy

[Paul M. Jones]

On Oct 15, 2014, at 1:04 AM, Daniel Ribeiro <drgo...@gmail.com> wrote:

> On Wed, Oct 15, 2014 at 6:55 AM, Paul M. Jones <pmjo...@gmail.com> wrote:
> > Projects. Not people.
>
> It doesn't actually say that in the bylaw.
>
> Paul, with all do respect, your stubbornness is quite annoying.

Yes, I do stick my my guns when I believe I am in the right.

> If you open the membership bylaw, the first phrase states exactly what Phil is saying:
>
> The membership of the PHP Framework Interoperability Group (PHP-FIG) is comprised of Member Projects. This bylaw defines the rules and rights of membership.
>
> Can we get over our egos and move on?

This is not about Ego. Again, I challenge you to read the *entire document* and find how it is incongruent with the (accurate, I remind you!) history of this group that I have presented.

[Paul M. Jones]

On Oct 15, 2014, at 2:41 AM, Pádraic Brady <padrai...@gmail.com> wrote:

> On Wednesday, October 15, 2014, Paul M. Jones <pmjo...@gmail.com> wrote:
>
> On Oct 14, 2014, at 3:34 PM, Philip Sturgeon <pjstu...@gmail.com> wrote:
>
> > Projects. Not people.
>
> It doesn't actually say that in the bylaw.
>
> Actually, that's exactly what it says

If you could point me to that phrase in the document, I'd appreciate it.

[Philip Sturgeon]

On Wednesday, October 15, 2014 8:07:39 AM UTC-5, pmjones wrote:

On Oct 15, 2014, at 1:04 AM, Daniel Ribeiro <drgo...@gmail.com> wrote:

> On Wed, Oct 15, 2014 at 6:55 AM, Paul M. Jones <pmjo...@gmail.com> wrote:
> > Projects. Not people.
>
> It doesn't actually say that in the bylaw.
>
> Paul, with all do respect, your stubbornness is quite annoying.

Yes, I do stick my my guns when I believe I am in the right.

You potentially should have added [...regardless of however much evidence or explanation is provided to the contrary.]

 

> If you open the membership bylaw, the first phrase states exactly what Phil is saying:
>
> The membership of the PHP Framework Interoperability Group (PHP-FIG) is comprised of Member Projects. This bylaw defines the rules and rights of membership.
>
> Can we get over our egos and move on?

This is not about Ego.  Again, I challenge you to read the *entire document* and find how it is incongruent with the (accurate, I remind you!) history of this group that I have presented.

Lets quote stuff from the bylaw.

The membership of the PHP Framework Interoperability Group (PHP-FIG) is comprised of Member Projects. This bylaw defines the rules and rights of membership.

https://github.com/php-fig/fig-standards/blob/master/bylaws/003-membership.md#membership

So, the FIG is comprised of projects, not people. Right? 

To remove any doubt, there are definitions:

Definitions

Member Project

Any PHP project with voting rights admitted to PHP-FIG after submitting an application to the PHP-FIG mailing list under the Member Application procedure described in this bylaw.

Voting Representative

Any individual granted the right to cast votes on behalf of a Member Project.

That sounds exactly what I said above.

Membership List

The current Member Projects in PHP-FIG will be listed at the following URL: http://www.php-fig.org/

This list must also indicate the names of the current Voting Representative for each Member Project. This list must be updated for any change in the composition of Member Projects or Voting Representatives.

Representatives are listed next to the project which was voted in. Because projects not people. 

To cast votes on PHP-FIG proposals, it is required that a PHP project apply to become a Member Project. This application may be submitted by any individual who is authorized by the PHP project in question to do so.

The project applies, and that can be done by anyone that the group itself says. Like when I was Project Lead of PyroCMS, I submitted my own application with the backing of other members of the PyroCMS team.

Do I need to keep going with this stuff? 

Nothing in here alines with your views that we're just voting in people and making sure they have some sort of project so we know they have "skin in the game."

I know that totally used to be the case, and we have Cal in here representing "the community at large." and as has been said - multiple times - the NEW bylaws were forward looking, and had no intention of booting anyone out.

So we have some artifacts, but the bylaws are extremely clear and in no way reflect your interpretation of them, or give any support to your argument. 

[Matthieu Napoli]

Am I the only one who thinks it's OK to have several projects with the same representative get several votes.

As we keep repeating: it's projects, not people.

Why would (for example) Assetic or Buzz not get a a vote because of Kris Wallsmith? Again: projects, not people.

I like to believe that the representative doesn't vote with his opinions, but rather with the opinion of the community behind the project.

The way I see it representative exist only so that we can keep track of the votes and not have somebody come in and say "Hey Symfony votes -1 on that" and we don't know if we can trust him. Representatives are just an implementation detail.

OMG some projects have people in common and thus share some opinions and practices? That's OK! We are talking about communities. Symfony is a community, Silex is one too. They should get a vote each, even if they vote the same because there is some overlap in the communities.

Or if you disagree with that, then maybe it shouldn't be about people, it shouldn't be about projects, but it should be about voting in "communities". Oh hell…

TL/DR: let's stop talking about representatives. Let's stop listing members by listing people. Let's just list projects. And then we'll see that it doesn't make sense to put Solar and Aura on the same line because they are separate projects.

But anyway, that's just like, my opinion dude

Le mardi 14 octobre 2014 04:36:15 UTC+13, Beau Simensen a écrit :

I would like to see the representatives of the following sets of projects nominate just one of their projects to remain on the list of member projects:

• Assetic or Buzz, Kris Wallsmith
  
• Aura Project or Solar Framework, Paul M. Jones
  

• Composer or Packagist, Jordi Boggiano
  

• Wikibase or Semantic MediaWiki, Jeroen De Dauw
  

The other project may be free to make an additional submission to join as a member project if it still meets the criteria. This makes more sense for some sets of projects than others and we should probably take them on a case-by-case basis as each project decides it wants to be request membership.

We have no bylaws for this process specifically, but given how things are setup I would imagine that the current representative should be able to send an email stating something along the lines of:

"Please remove [Project B] from the membership list as it is already being represented by [Project A]'s membership."

[Bret Mette]

Not to mention the entire notion that someone is going to go to great lengths to obtain multiple unmerited votes in PHP-FIG is laughable. Further, nothing is written in the by-laws, or mentioned in any discussion that would stop someone from puppeteering multiple voters as figure-heads behind the scenes. If someone really wanted to do that, they could and it would be extremely hard to stop them.

I think it's rather egotistical (and extremely immature) for this group to overly concern themselves with such a scenario. Professional groups of people do not waste this much time on things so meaningless, they are busy getting s**t done.

- Bret

--

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/e537c067-262b-439a-b9cb-dfaf562bf8fe%40googlegroups.com.

[John Flatness]

A couple notes on this discussion from a "random person":

1. Even though the literal phrase "projects not people" doesn't appear verbatim in the membership bylaw, it's pretty clear by its wording throughout and the substance of the policies that the projects are the members, not the representatives.

2. What I don't see in the bylaw is anything saying a single representative can't represent more than one project. Each project can only have one representative, but as far I as can tell there's nothing in there preventing multiple projects from choosing the same representative. In a situation where the projects are the members, that actually makes sense: two member projects could reasonably decide that a single person can represent both of their interests. If those interests diverge, or they don't like how the representative is acting, the bylaw lets the project switch its representative whenever it wants.

It may well be desirable to force projects to choose separate representatives for the purposes of ensuring a reasonably-sized community for robust debate and consultation, but I don't think the existing bylaw actually does force that.

Some people raised concerns here and also in other recent threads about two projects really being "controlled" by the same person or group but having nominally different representatives. The bylaw doesn't speak to that either, and it's really a completely separate issue that's more about which projects should be accepted (or expelled), and not about who represents them. It's probably impossible to create a general policy that deals with that possibility anyway, except maybe in the case of formal merger of two member projects.

As for these 4 (now 3) representatives who don't have a single project, this seems from where I'm standing to be a result of pre-bylaw sloppiness in accepting membership requests, or in maintaining the membership list. Jordi's membership voting thread seems to clearly indicate he was accepted as a representative of Composer, so Composer is the member and there's no decision to be made (though he already made that same decision again here).

For others, comments on membership requests like "You can represent as many projects you're able to, but you get only one vote regardless of how many projects you represent" make it clear that the "projects not people" principle wasn't being adhered to and the person, or at least their constellation of projects, really got accepted instead of any single project. If "projects not people" is the principle (as it seems to be), it seems someone needs to just make the decision about which of the projects is actually a member, and which isn't.

Apologies if this was mere noise, since there's been more than enough of that flying around this list of late, but I felt that maybe a viewpoint from a distance could provide some clarity.

-John Flatness

[Kayla Daniels]

This echoes pretty identically some thoughts I've had on the matter. Everyone here is essentially donating their time, for the betterment of the community and it's end users. There's nothing to gain personally. This isn't congress, no one is lobbying. The idea that someone would give their free time to something, and then use it for puppeteering votes seems really silly. 

That said, most of the representatives on this list are fairly well known community members, and most of them are friends. If someone really wanted to swing a vote one way or another, they could do it now. There's nothing currently, nor do I really think there ever could be, something that stops the possibility of that from happening. 

But then, you forget why we're here in the first place. To help make things better. Or, as Bret said: to get s**t done. 

On Wednesday, October 15, 2014 7:29:44 PM UTC-4, Bret Mette wrote:

[Stefano Torresi]

FWIW I personally find preposterous the assertion that if we swapped every representative with an entirely different person, then the outcome of each vote would have been the same, just because "it's the project that counts'.

BS.

As I stated in another thread, I firmly believe that people DO matter, and their opinion/contribution/vote is *always* more or less biased in some way. Pretending that this is not the case it's pretty much like any hypocrite and empty statement I hear daily from random politicians in the news.

I'm a strong advocate of FIG work, I follow the ML with interest and can see sense in most of what's being done here, but if I had to thank someone for having a better ecosystem to work with today, that would be the people who were actually involved in making it better, not "the projects" they come from.

Most of the end-users of most of the member projects are not involved in any decision whatsoever here, they're not represented in any way, and they probably don't even care. They're just influenced by someone else's decisions, as anybody using third party software is. And I'm fine with it, don't get me wrong... but pretending otherwise? That I can't understand.

I'm part of the community, I occasionally contribute to some of the "member projects", but how should that make me feel represented? I'm just a random guy, the most I can do is express my opinion which, no matter how good it is, is probably not going to be evaluated the same as if I were an influential and well recognized personalty. And again, I'm fine with that, but please don't pretend otherwise.

To my eyes the FIG is a group of *people*, who gathered to promote interoperation between the projects they are involved with. Of course people do come and go, and asserting that this doesn't make any difference wouldn't be true even if every project had a flat power structure.

But again, that's just how I see things from my perspective.

Stefano Torresi

[Philip Sturgeon]

That's one way to look at it, but  thats not what the bylaws say.

Regardless of that markdown file, there are people that have made a difference in this group regardless of their voting status. 

When Ryan takes over from me as Voting Representative, is he going to fight as hard for things like Errata, Amendments, Workflows and PSR-0 deprecation as me? No. 

Does he need to? No. I'll still be all up in this mailing list.

MWOP quit, and left somebody else in here to be a representative. Then he came back to be Editor of PSR-7 as a lowly outsider. He's still a person making a difference, but he is not a member project.

People assign drastically too much importance to the voting status, when really its literally just to +1 or -1 a vote. If something is a good idea, you can ask DM somebody asking to propose a vote and TADAAAAAA it's on its way. That's actually quicker and easier than running your own vote. 

So yes, it is projects, not people that are members., but regular old people can do a lot of useful stuff around here without needing to be a representative for a member project.

[Paul M. Jones]

On Oct 16, 2014, at 11:35 AM, Philip Sturgeon <pjstu...@gmail.com> wrote:

> That's one way to look at it, but thats not what the bylaws say.

I assert you are incorrect here. The bylaw can be read quite easily with the "persons vote, but to do so they need to have a project, so that they have skin in the game" history of this organization in mind.

Incidentally, in reading the thread on the writing of the bylaw, nothing is said about changing that approach. It reads as a codification of the existing practice. If the authors intent was to change the existing practice, I failed to find them saying so explicitly.

Further, I owe you a rebuttal on this, forthcoming.

[Mike van Riel]

On 16-10-14 18:47, Paul M. Jones wrote:
> On Oct 16, 2014, at 11:35 AM, Philip Sturgeon <pjstu...@gmail.com> wrote:
>
>> That's one way to look at it, but thats not what the bylaws say.
> I assert you are incorrect here. The bylaw can be read quite easily with the "persons vote, but to do so they need to have a project, so that they have skin in the game" history of this organization in mind.
>
> Incidentally, in reading the thread on the writing of the bylaw, nothing is said about changing that approach. It reads as a codification of the existing practice. If the authors intent was to change the existing practice, I failed to find them saying so explicitly.
>
> Further, I owe you a rebuttal on this, forthcoming.
>

Do me a favor and do it in private. Unless I am mistaken exploring this
topic in public is not going to be constructive for this group or its
activities. If other people disagree with this then please correct me

[Pádraic Brady]

On 16 October 2014 17:47, Paul M. Jones <pmjo...@gmail.com> wrote:

On Oct 16, 2014, at 11:35 AM, Philip Sturgeon <pjstu...@gmail.com> wrote:

> That's one way to look at it, but  thats not what the bylaws say.

I assert you are incorrect here. The bylaw can be read quite easily with the "persons vote, but to do so they need to have a project, so that they have skin in the game" history of this organization in mind.

Incidentally, in reading the thread on the writing of the bylaw, nothing is said about changing that approach. It reads as a codification of the existing practice. If the authors intent was to change the existing practice, I failed to find them saying so explicitly.

I think too many mutually exclusive things are being munged into one. To get a vote, you need to be a member. Unless you became a member before the bylaw, then only projects can be members now that it's in effect. To vote, the project needs to assign a voting representative. If you're a BDFL, congratulations, you can nominate yourself unopposed. If not, the representative will be selected through wizardry and the examination of entrails at moonlight for all we care - so long as it gets done and the representative is accountable to the project's members who may be benign and ignore their representative or hold internal votes themselves before instructing their representative on what to do.

Everything after the fourth sentence above is beyond the scope of the bylaw as written, though it regularly leaks into the voting process for new members.

The objection, Paul, is specifically "skin in the game". There's an implication I can read there (which may or may not be valid in context - if not, ignore my prattling) that such voters are not accountable to their projects. If I left Zend Framework as a rep, re-applied for Mockery, and then threw votes around while ignoring the vocal complaints of Dave Marshall, then I would fully expect this group to accede to any request he makes to have me evicted as representative. I made Marshall a full co-maintainer so I'm not actually a BDFL. I can't just use Mockery as an excuse to get a vote without a) Dave's cooperation and b) taking account of Dave's opinions. I'm accountable to the project. This is why projects, and not people, are defined as the basis of membership. If we ever wanted to include an individual, and use a project as the excuse, that's fine - but the bylaw ensures that the project ultimately holds all the cards. You'd have to admit that person under yet another project if they ever left the original project, or were kicked out by it.

Anyways, this point is probably at the extreme end of the public interest for now and the bylaw doesn't apply strictly to the likes of Cal, or any pre-bylaw members for that matter. The current topic is in-addition-to the bylaw. If we want the bylaw to apply universally to the past, it would need a number of exceptions/clarifications added on to cover those historical cases mentioned for this topic where volunteered action is not forthcoming IMO.

Paddy

[Philip Sturgeon]

I've asked Paul to email me about this. 

If anyone else wants a CC when he gets me that rebuttal then I'll include you in replies and whatnot.

[Philip Sturgeon]

On Thursday, October 16, 2014 1:59:18 PM UTC-5, Pádraic Brady wrote:

The objection, Paul, is specifically "skin in the game". There's an implication I can read there (which may or may not be valid in context - if not, ignore my prattling) that such voters are not accountable to their projects. If I left Zend Framework as a rep, re-applied for Mockery, and then threw votes around while ignoring the vocal complaints of Dave Marshall, then I would fully expect this group to accede to any request he makes to have me evicted as representative. I made Marshall a full co-maintainer so I'm not actually a BDFL. I can't just use Mockery as an excuse to get a vote without a) Dave's cooperation and b) taking account of Dave's opinions. I'm accountable to the project. This is why projects, and not people, are defined as the basis of membership. If we ever wanted to include an individual, and use a project as the excuse, that's fine - but the bylaw ensures that the project ultimately holds all the cards. You'd have to admit that person under yet another project if they ever left the original project, or were kicked out by it.

Also, 100% to that.

Most of this is common sense, but its also backed up by what our bylaws actually say. I pasted that all in above so I can't be told im wrong. It's in English, and im not bad at English! 

I'm not sure how anyone is going to try and argue that, other than "Well thats not what we said in 2009!" Thats hardly valid, when we have a piece of text written down that 100% contradicts one persons opinion of what they would like it to say.

Anyhow. More content for the email reply Paul!