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.
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.
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.
--
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.
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.
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
The membership of the PHP Framework Interoperability Group (PHP-FIG) is comprised of Member Projects. This bylaw defines the rules and rights of membership.
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.
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.
The membership of the PHP Framework Interoperability Group (PHP-FIG) is comprised of Member Projects. This bylaw defines the rules and rights of membership.
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.
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."
--
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.
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.
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.