Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposed Membership Bylaw #95

Merged
merged 13 commits into from
May 3, 2013
129 changes: 129 additions & 0 deletions bylaws/003-membership.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,129 @@
Membership
==========

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

Definitions
-----------

<dl>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

<dt><strong>Member Project</strong></dt>
<dd>
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.
</dd>
<dt><strong>Voting Representative</strong></dt>
<dd>
Any individual granted the right to cast votes on behalf of a Member
Project.
</dd>
</dl>

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.

Membership Application
----------------------

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 authorised by the PHP project in question to do so.

The application must be emailed to the main [php-fig mailing list][list] and
is restricted to one application per email. In order to be considered, all
applications must be sponsored in advance by at least one existing Voting
Representative.

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, 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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This probably doesnt need to be said.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

become a Member Project.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

confirmed by the Member Project to be authorised to act in such a capacity
by sending an email to the the main [php-fig mailing list][list]. This email
may be combined with a Member Application if the applicant has sufficient
authority. The other Member Projects may seek such confirmation at any time
during the Voting Representative's term.

A Member Project may not have more than one Voting Representative at a time.

A Voting Representative may temporarily confer their voting rights onto another
individual who is authorised by the Member Project which they represent. This
conferral must be notified to PHP-FIG by the current Voting Representative
by sending an email to the main [php-fig mailing list][list]. This email
must state the name of the temporary Voting Representative and the period of
time for which their temporary voting rights will remain valid. All voting
rights will automatically return to the original Voting Representative at the
end of the period of time stated in this email. All dates noted should reference
a timezone. Where a timezone is not referenced, Coordinated Universal Time (UTC)
will be assumed.

If, in the judgement of PHP-FIG, a Voting Representative is acting
inappropriately and to the detriment of PHP-FIG's ability to meet its
objectives, a vote may be taken to request a replacement Voting Representative in
accordance with the [Voting Protocol bylaw][voting] or to expel the Member
Project where replacing a Voting Representative is not possible.

Resignation Of Member Projects
------------------------------

A Member Project 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
immediately ceases to be a Member Project.

A former Member Project may reapply for membership at any future date.

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].

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

[list]: https://groups.google.com/forum/?fromgroups#!forum/php-fig
[voting]: https://github.com/php-fig/fig-standards/blob/master/bylaws/001-voting-protocol.md