Skip to content

Proposed Membership Bylaw #95

Merged
merged 13 commits into from May 3, 2013

9 participants

@padraic
padraic commented Mar 2, 2013

This is intended to codify existing rules and to clarify the differences between PHP projects and the individuals who represent those projects and cast votes on their behalf. This should remove any need to re-vote each time a project needs to change its representative. I also included language to allow multiple representatives in recognition of projects which are founded on equal partnerships in the absence of a benevolent dictator or prominent meritocracy.

@ghost Unknown commented on the diff Mar 2, 2013
bylaws/003-membership.md
@@ -0,0 +1,102 @@
+Membership
+==========
+
+The membership of the PHP Framework Interoperability Group (PHP-FIG) is
+comprised of both Voting Members and Non-Voting Community Members. This bylaw
+defines the rules and rights of all members.
+
+Definitions
+-----------
+
+<dl>
@ghost
ghost added a note Mar 2, 2013

We dont need any markup here. It defeats the purpose of markdown.

@philsturgeon
philsturgeon added a note Mar 2, 2013

The only way to make a <dl> tag in markdown is by using a <dl> tag. This is fine.

@padraic
padraic added a note Mar 2, 2013

Markdown is a superset of HTML, i.e. all HTML is Markdown ;)

@ghost
ghost added a note Mar 2, 2013

But in any case, the point is to have easily understandable documents. The point of markdown etc is that you have a specific way of formatting a document without markup that makes the document readable as plain text and something that can be parsed to render some kind of formatting. Look around at the thousands of markdown documents, it is not the habit to use html tags.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@ghost Unknown and 2 others commented on an outdated diff Mar 2, 2013
bylaws/003-membership.md
+
+The application must be emailed to the main [php-fig mailing list][list] and
+is restricted to one application per email.
+
+The subject of the email must follow the following format:
+
+ Membership Request: {$your_name} ({$project_name})
+
+The body of the email should provide details of the PHP project applying for
+membership including its name, URL and any other details the individual applying
+on behalf of the PHP project believes necessary.
+
+The membership application will be voted upon by the existing Voting Members
+in accordance with the [Voting Protocol bylaw][voting].
+
+There are no restrictions on the number of times a PHP project may apply to
@ghost
ghost added a note Mar 2, 2013

This probably doesnt need to be said.

@padraic
padraic added a note Mar 2, 2013

And leave something else to be debated and questioned? No harm being explicit.

@mvriel
mvriel added a note Mar 2, 2013

I agree with @padraic, bylaws and standards should be as clear and explicit as possible. This reduces ambiguity and reduces room for harmful interpretation and needless debate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@ghost
ghost commented Mar 2, 2013

This entire document is way too legal like for my liking. Needs more plain English.

@philsturgeon philsturgeon and 4 others commented on an outdated diff Mar 2, 2013
bylaws/003-membership.md
+Project Representatives
+-----------------------
+
+The votes of all Voting Members are cast by Project Representives who have been
+authorised to do so by the Voting Member. The Project Representative is chosen
+solely by the Voting Member and their selection is not subject to the approval
+of PHP-FIG.
+
+To prevent illegal or erroneous voting, the Project Representative must be
+confirmed by the Voting Member to be authorised to act in such a capacity
+in an email to the the main [php-fig mailing list][list] where
+practical and where this does not conflict with the Voting Member's policies.
+The other Voting Members may seek confirmation through other channels as
+necessary.
+
+A Voting Member may have more than one Project Representative with the
@philsturgeon
philsturgeon added a note Mar 2, 2013

I agree with everything but this. Should it not be kept to just one representative? Like in the quiz shows where the team captain has to give the answer.

@padraic
padraic added a note Mar 2, 2013

A project is free to organise itself as it sees fit. I put it in because someone mentioned in an email thread that Composer was on the partnership end of the scale vs something more rigid like ZF2 where there's some limited codifying of the meritocracy at the top.

@mvriel
mvriel added a note Mar 2, 2013

I would feel more comfortable to have one 'official spokesperson / representative' as that diminishes the risk of PHP-FIG being involved in internal politics of said Voting Member. (not saying this will happen but multiple captains on one ship is generally a risk)

@michaelcullum
PHP FIG member
michaelcullum added a note Mar 2, 2013

Sometimes one rep might be on holiday (or generally busy) and not have the chance to look into it [the subject of the vote] & respond or might not be watching a topic with much interest but another rep might be available/more interested and therefore send in the vote. As long as they understand each org only has 1 vote (as clarified on the following lines) and the project reps co-ordinate (so as not to have conflicting views and if they do to discuss it within the project) I'd say this would be fine. If they both voted separate ways then both would be discounted until they sort out what the org wants to vote internally.

If they org cannot reach an agreement internally then they should just be abstaining anyway as the vote is the org's, not the rep's.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@philsturgeon philsturgeon and 4 others commented on an outdated diff Mar 2, 2013
bylaws/003-membership.md
+in an email to the the main [php-fig mailing list][list] where
+practical and where this does not conflict with the Voting Member's policies.
+The other Voting Members may seek confirmation through other channels as
+necessary.
+
+A Voting Member may have more than one Project Representative with the
+understanding that this does not confer additional votes and that any conflicts
+in casted votes must be reconciled by the Voting Member prior to their vote
+being officially recognised.
+
+Resignation Of Voting Members
+-----------------------------
+
+A Voting Member may resign from PHP-FIG in writing to the main
+[php-fig mailing list][list] or by stating their intention to do so on another
+official public channel. Once such a statement is published, a PHP project
@philsturgeon
philsturgeon added a note Mar 2, 2013

I think this should be kept to the mailing list, just like registrations.

@padraic
padraic added a note Mar 2, 2013

And if the project refuses to send such an email?

@mvriel
mvriel added a note Mar 2, 2013

I agree with @philsturgeon; having multiple channels might cause confusion as to whether a resignation was correctly received

@dragoonis
dragoonis added a note Mar 2, 2013
@padraic
padraic added a note Mar 2, 2013

Theoretically, PHP-FIG cannot require a departing member to post an email except as a polite gesture. If they ignore you for a year, does this make them a continuing member indefinitely?

@michaelcullum
PHP FIG member
michaelcullum added a note Mar 2, 2013

I'd actually say that inactive voting members would be better to be 'purged' after a certain time as otherwise the number of votes needed for a majority goes up, but it is harder to achieve the majority due to inactive members.

@philsturgeon
philsturgeon added a note Mar 2, 2013

@unknownbliss: How would we handle the purges? Does somebody have to mark down every vote result in a spreadsheet somewhere so we can see who isnt voting? Or is there some automatic purge feature in Google's mailing list?

@padraic basically, if we're keeping that "security check" in place where they have to confirm they are leaving, then we can also expect them to use the mailing list to send out that email. Otherwise we skip security entirely and somebody can just wander in and say "yep, im speaking for PyroCMS now". It should be one or the other to keep things consistent.

@padraic
padraic added a note Mar 3, 2013

Could someone raise that on the mailing list and we'll see what others think there?

@michaelcullum
PHP FIG member
michaelcullum added a note Mar 3, 2013

@philsturgeon As I probably insinuated on the ML, it would need to be manual but it would only take 5 minutes. Just make a list of names, then with split screen scroll down on the ML topic and put in y for those who voted in each vote, repeat 3 times in 3 columns. Then see who has 3 blank cells.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@padraic
padraic commented Mar 2, 2013

@drak This is plain English. It looks legalese because I erred on being explicit and to the point which comes across in a similar style. Also, as a writer in part, I lost the ability to write purely in conversational English many many moons ago.

@ghost
ghost commented Mar 2, 2013

@padraic - "plain English" means not to use legal complexity, for example explicitly stating what is already obvious and explicit. This is written like a contract. There is a way to write this kind of thing in a way that is more like the language non-lawyers are used to reading. see http://en.wikipedia.org/wiki/Plain_English_Campaign, specifically http://www.plainenglish.co.uk/faqs.html#Anchor-Wha-35253 and the point is, it's not necessary to write like a lawyer to be completely crystal clear, even in a legal contract / agreement.

@padraic
padraic commented Mar 2, 2013

@drak I wrote this as myself. I'm not a lawyer nor pretending to be one. If you don't like the author, by all means go find another one to spend time with a thesaurus.

@philsturgeon
@ghost
ghost commented Mar 2, 2013

I think PHP-FIG should ratify a project's choice for representative. There could be rare cases where we do not agree with an appointee. The fact is, when we vote, we are voting more on the merits of the proposed member than the project itself. Many things can affect a vote, including how a person conducts themselves in conversation/debate, not just because they are part of X project. In your case, we all know of you so it's different. So I would prefer PHP-FIG to ratify a change in representative for any project.

@ghost
ghost commented Mar 2, 2013

@philsturgeon - I have no idea what you are talking about. Read about the Crystal mark, it's a worldwide campaign that works with many multinationals. What I am showing is there is a very popular way of making complex things easy to read by everyone.

@padraic - I really dont understand your response here. You seem offended, but please look at what I am saying, it's nothing unreasonable or offensive.

@philsturgeon
@padraic
padraic commented Mar 2, 2013

A reminder to myself and everyone else - keep points unrelated to technical issues on the text for the mailing list if possible. It's the better medium for the high level arguments.

@mvriel
mvriel commented Mar 2, 2013

As far as I can see there is no legalese here; the words used are plain English. Even the level of verbosity is not a hindrance for me (as a TOS of Apple is an issue to me!)

@michaelcullum
PHP FIG member

How do you intend to handle projects wanting to change their representatives forcibly without the current rep resigning (essentially firing vs resigning) if this should ever happen? This would also be needed in situations where the old rep cannot leave (i.e. they are too ill).

@padraic
padraic commented Mar 2, 2013

@unknownbliss By staying out of it. A Voting Member gets one vote and PHP-FIG keeps itself out of the political side of choosing a rep.

It's really none of our business how a member chooses, replaces, or fires representatives.

@philsturgeon
@padraic
padraic commented Mar 2, 2013

@drak At the risk of perpetuating this, I wasn't offended. I just disagreed and pointed out that the group is entirely free to rewrite the bylaw according to the majority's wishes ;). My apologies if the wee bit of sarcasm came across too heavy handed.

@michaelcullum
PHP FIG member

@padraic How does the org communicate to the project though that they want to remove their rep forcibly? The rep could just say that they have no say/deny that they are involved in the org? The only offical way to communicate is via the ML by the a project rep.

@padraic
padraic commented Mar 2, 2013

@unknownbliss We may have no choice but to cross that bridge should it ever crop up. The most could ever do, in a worst case scenario, is presumably suspend their vote citing a lack of authority from the Voting Member (which is explicitly required per the draft bylaw). I'd keep the specifics out of the bylaws for the time being. Let's not invite trouble ;).

@AmyStephen

I wanted to share the link for this discussion: https://groups.google.com/forum/#!topic/php-fig/kpsDvmqJx3U

Although there is discussion above, those of you who aren't certain whether or not your input is welcome, it is welcome, provided it is relevant and polite. Please remember that the FIG Membership prefers our discussions occur in the Google Email list rather than in the Issue.

@philsturgeon philsturgeon commented on the diff Mar 3, 2013
bylaws/003-membership.md
+checks to ensure that each application is valid and authorised by the PHP
+project that the applicant claims to act on behalf of.
+
+There are no restrictions on the number of times a PHP project may apply to
+become a Member Project.
+
+Voting Representatives
+-----------------------
+
+The votes of all Member Projects are cast by Voting Representives who have been
+authorised to do so by the Member Project. Each Voting Representative is chosen
+solely by a Member Project and their selection is not subject to the approval
+of PHP-FIG. A Voting Representative may be replaced by the Member Project which
+they represent at any time.
+
+To prevent illegal or erroneous voting, the Voting Representative must be
@philsturgeon
philsturgeon added a note Mar 3, 2013

I'm not sure of the exact wording here, but it should probably say "when replacing a voting representative". Otherwise it makes it sound like if Taylor Otwell decides apply for Laravel, then Taylor Otwell would have to send an email saying its ok for Taylor to represent Laravel. This is just if you're swapping out, right?

@padraic
padraic added a note Mar 3, 2013

It's correct - I did however add wording to allow the email be combined with the application (technically its an email too so simply to be explicit...). If a rep is the project authority - they just have to say so when introducing themselves.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@padraic
padraic commented Mar 3, 2013

All comments to the mailing list please. Comments on the PR get lost if the line they're attached to is deleted from the source code!

@philsturgeon

I'm going to discuss the actual text of things here, and the general group and politics and policies over on the mailing list. If im talking about a specific line im going to do that right next to the specific line. Once that line is changed the comment is gone, which is great as its no longer valid.

@bobthecow

@padraic @philsturgeon Yep. That's the perfect use case for comments on PRs :)

... and yeah, i know this is the wrong place to say that, but it's the right place to reply :)

@michaelcullum

Comma after six months?

@harikt harikt commented on the diff Mar 7, 2013
bylaws/003-membership.md
+
+The body of the email should provide details of the PHP project applying for
+membership including its name, URL, the name of the proposed Voting
+Representative, the name of the Voting Representative sponsor and any other
+details that the individual applying on behalf of the PHP project believes are
+necessary to include.
+
+The membership application will be voted upon by the existing Member Projects
+in accordance with the [Voting Protocol bylaw][voting]. PHP-FIG must perform
+checks to ensure that each application is valid and authorised by the PHP
+project that the applicant claims to act on behalf of. Once voting has completed
+and if the application has been deemed accepted, the PHP project will become a
+Member Project with immediate effect.
+
+There are no restrictions on the number of times a PHP project may apply to
+become a Member Project.
@harikt
harikt added a note Mar 7, 2013

May be we need a 6 months gap if they fail to get the vote?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@harikt harikt commented on the diff Mar 7, 2013
bylaws/003-membership.md
+Expulsion Of Member Projects
+----------------------------
+
+A Member Project may be expelled from PHP-FIG if, in the judgement of PHP-FIG,
+that Member Project has not casted votes in three consecutive voting calls or all voting
+calls over a period no less than six months whichever constitutes the greater
+period of time. It is the responsibility of Member Projects to ensure that they
+are actively represented by a Voting Representative.
+
+A Member Project may also be expelled if their Voting Representative is subject
+to a replacement request from PHP-FIG but a suitable replacement is not
+available.
+
+The expulsion of a Member Project requires a vote in accordance with the
+[Voting Protocol bylaw][voting].
+
@harikt
harikt added a note Mar 7, 2013

I feel the projects can also be expelled if they don't participate in discussions over a period of time ( say 6 moths ). It is not just to vote "no" they should come.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@dragoonis dragoonis merged commit 70f2964 into php-fig:master May 3, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.