You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: bylaws/010-funding.md
+77-18Lines changed: 77 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,11 +2,19 @@
2
2
3
3
## Scope and objectives
4
4
5
-
PHP-FIG is, as it often happens in Open Source communities, an organization composed by volunteers only; this doesn't exclude the fact that the organization itself may have some costs to sustain itself, for example maintaining tools such as a site and an email account. For such and similar reasons, we need a way to raise and govern money inside our organization. At the same time, we will avoid soliciting and collecting donations from private individuals, while instead trying to obtain funding from commercial companies and similar entities that, due to their profit which stems from the usage of Open Source Software, should contribute to the costs of the Open Source community at large.
5
+
The PHP-FIG isan organization composed entirely of unpaid volunteers and community members focused on improving the PHP ecosystem. As part of realizing its goals, the PHP-FIG has limited operating expenses like domain names, email accounts, and similar that require ongoing funding.
6
6
7
7
This document defines the roles, rules and processes that must be followed inside the PHP-FIG in all matters regarding money, to guarantee fairness, transparency and impartiality. This document intentionally describes the only allowed processes and ways to raise, administer and spend money, so that any change to such processes requires a bylaw change vote.
8
8
9
-
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119][].
9
+
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
@@ -22,36 +30,87 @@ PHP-FIG SHALL NOT solicit donations from any party, especially from private indi
22
30
23
31
### Through OpenCollective
24
32
25
-
Direct contributions MUST NOT be accepted through Open Collective, to avoid private/personal donations; the collective home page MUST be set up in a way that:
26
-
* all contribution sections and features are hidden and/or disabled, if possible;
27
-
* explicit wording will be visible reminding visitors of the PHP-FIG stance in the matter (see "Scope and objectives").
33
+
Contributions SHALL be accepted via [Open Collective](https://opencollective.com/) with the following requirements:
34
+
35
+
- The description MUST include the following:
36
+
1. A link back to this document on the PHP-FIG website.
37
+
2. A statement that we'd prefer contributions from companies that benefit
38
+
monetarily from the PHP-FIG recommendations, rather than from private individuals.
39
+
3. Links to other preferred options for individuals to contribute as listed in this document, if any such exist.
40
+
4. A list of overfunding recipients as listed in this document, if any such exist.
41
+
- The following information MUST be configured to show:
42
+
1. Contributors and the amounts they contributed;
43
+
2. The total amount of money raised;
44
+
3. The total amount of money spent;
45
+
4. The total amount of money remaining in the account;
46
+
5. The itemized transactions, including the date, amount, and description
47
+
48
+
### Via print-on-demand swag
49
+
50
+
Secretaries MAY, at their own discretion but with regard to the following rules, create and sell print-on-demand swag, such as shirts, mugs, stickers, and any other items that the secretaries deem appropriate. By providing this option, the PHP-FIG allows individuals to contribute financially and advertise the PHP-FIG at the same time, while also receiving a tangible item in return.
51
+
52
+
When selecting print-on-demand providers, the provider:
53
+
54
+
- MUST be able to pay out to the PHP-FIG Open Collective account. This might require coordination with the fiscal host.
55
+
- SHOULD ship to as many people around the world as possible.
56
+
- SHOULD be sustainably and ethically sourced and produced.
57
+
- SHOULD provide a level of quality that meets or exceeds the expectation for the price.
58
+
- SHOULD provide sizes and shapes that are inclusive of as many body types as possible.
59
+
60
+
When creating a new product design, the Secretaries MUST notify the mailing list with an attached image of the design. This notification serves as both an opportunity for the core committee to vote to remove the design, and as a way to inform the community about the new product. When reusing an existing design in a new form factor, such as a new shirt color underneath an existing design, or putting an existing shirt design on a mug, the Secretaries MAY skip this notification step at their own discretion.
61
+
62
+
Product designs:
63
+
64
+
- MUST only use intellectual property that is owned by the PHP-FIG, or for which the PHP-FIG has been granted a clear license to use.
65
+
- MUST not be offensive, discriminatory, inflamatory, or otherwise inappropriate.
66
+
- MUST not be used to promote any specific person, company, or product, except for the PHP-FIG itself, and as allowed by this document.
67
+
- MAY include member project logos so long as all available member project logos are included in similar scale and position, and the logos are used in a way that does not imply endorsement by the PHP-FIG, and a licence has been explicitly granted by the member project to use their logo in this way.
28
68
29
-
### Through TideLift
69
+
At any time, any member of the Core Committee MAY call an approval vote to remove a design or product whether actively sold or not, or to reinstate a previously removed design or product.
30
70
31
-
Contributions SHALL be accepted through [TideLift](https://tidelift.com/). All three Secretaries, but only the Secretaries, MUST have full administrative access to PHP-FIG's TideLift account, which MUST be configured to pay out to the Open Collective account.
71
+
- If an approval vote passes, another approval vote SHALL NOT be called for the same design or product for a period of 30 days.
72
+
- If an approval vote passes causing a design or product to be reinstated, the Secretaries SHALL have the final say in whether the design or product will be sold.
73
+
74
+
All three Secretaries, but only the Secretaries, MUST have full administrative access to PHP-FIG's print-on-demand providers.
32
75
33
76
## Spending money
34
77
35
-
Funds donated to the PHP-FIG MUST be used solely for non-personnel, operating expenses. PHP-FIG SHALL NOT pay individual contributors to PHP-FIG standards or other personnel, like Core Committee members, Secretaries, Project Representatives or working groups.
36
-
All expenses MUST be approved by an Approval Vote of the Core Committee. The expense MUST include whether it is one time or recurring and at which frequency. All expenses MUST be justified by their contribution to the mission of PHP-FIG. In response to supplier price changes for previously accepted recurring expenses, Secretaries MAY request Implicit Approval from the Core Committee to raise the approved amount, only if that does not exceed a 10% increase.
78
+
Funds donated to the PHP-FIG MUST be used solely for non-personnel operating expenses. The PHP-FIG MUST NOT pay individual contributors or other personnel, like Core Committee members, Secretaries, Project Representatives or working groups unless the payment is associated with an approved expense, such as reimbursing a Secretay that has paid for an approved expense out of pocket.
79
+
All expenses MUST be approved by an Approval Vote of the Core Committee. The expense MUST include whether it is one time or recurring and the frequency at which the expense is incurred. All expenses MUST be justified by their contribution to the mission of PHP-FIG. In response to supplier price changes for previously accepted recurring expenses, Secretaries MAY request Implicit Approval from the Core Committee to raise the approved amount, only if that does not exceed a 10% increase.
37
80
38
81
Expenses approved by the Core Committee MUST be listed below, and reported in the Open Collective budget.
39
82
40
-
### Overfunding, and giving back to the community
83
+
### Overfunding and disbursement
84
+
85
+
Overfunding SHALL be defined as any amount raised that exceeds the amount needed to cover the existing PHP-FIG's yearly expenses, as defined in the "Approved expenses" section below, for a period of three years.
86
+
87
+
Every year in January, the Secretaries SHALL review the Open Collective account and disburse any overfunding to the list of recipients defined in the Approved disbursement recipients section below, in the amounts defined in aforementions section. Disbursements MUST be made in such a way to prevent any additional tax or fees from being incurred by the PHP-FIG or the recipient, such as via [Collective to Collective Donations][c2c].
88
+
89
+
If for any reason disbursement to a recipient is not possible, the recipient MUST be skipped and the Core Committee MUST be notified so this bylaw can be updated accordingly.
90
+
91
+
### Approved disbursement recipients
92
+
93
+
This section contains a list of recipients that are eligible to receive disbursements from the PHP-FIG.
94
+
95
+
As an exception to Votes Bylaw, changes to this section only SHOULD NOT trigger a Bylaw Change Vote, but only an Approval Vote by the Core Committee.
96
+
97
+
98
+
| Recipient name | Disbursement Method | Disbursement percentage |
| PHP Foundation |[PHP Foundation Open Collective][phpfoundation]|`100%`|
41
101
42
-
PHP-FIG SHOULD maintain financial reserves to account for three years of the currently approved budget.
43
-
At least once a year, any surplus funds MUST be forwarded to the [PHP Foundation](https://opencollective.com/phpfoundation), as a way to further support the PHP ecosystem.
This section will contain a chronological list of approved budgeting decisions, either recurring or not.
107
+
This section contains a chronological list of approved budgeting decisions, either recurring or not.
48
108
49
-
As an exception to [Votes Bylaw][], changes to this section only SHOULD NOT trigger a Bylaw Change Vote, but only an Approval Vote by the Core Committee, as explained in the "Spending Money" section.
109
+
As an exception to Votes Bylaw, changes to this section only SHOULD NOT trigger a Bylaw Change Vote, but only an Approval Vote by the Core Committee.
50
110
51
111
| Approved since | Expense | Provider | Approved amount and frequency |
0 commit comments