-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Changes from all commits
177203b
b31e45c
7722922
90f5f17
4808f57
50917b2
a1e9061
f9d369a
c43167a
b50c382
9694b8f
5c32d50
de97313
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
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> | ||
<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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This probably doesnt need to be said. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe 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]. | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.There was a problem hiding this comment.
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 ;)
There was a problem hiding this comment.
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.