1 |
On Mon, Oct 11, 2021 at 1:59 PM Robin H. Johnson <robbat2@g.o> wrote: |
2 |
> |
3 |
> On Mon, Oct 11, 2021 at 10:00:32AM -0700, Alec Warner wrote: |
4 |
> > Hello Nonprofit folks, |
5 |
> > |
6 |
> > In a recent Council meeting, the council agreed to take on the duties |
7 |
> > of vetting project-spending. The Foundation nominally has two types of |
8 |
> > spending: |
9 |
> > |
10 |
> > - Mandatory spending. These are things like phone, mail, taxes, |
11 |
> > accounting, etc. This spending will remain in direct control of the |
12 |
> > board. This spending is used to keep the *foundation* alive (note it |
13 |
> > has nothing to do with Gentoo the project in any way.) Eventually we |
14 |
> > would like to see the Foundation replaced by an umbrella, in which |
15 |
> > case this spending would be replaced by fees paid to the umbrella |
16 |
> > company. |
17 |
> > - Project spending. Pretty much anything not mandatory at this point. |
18 |
> > Note this includes infrastructure spending. So hardware, servers, |
19 |
> > reimbursements, posters, etc. |
20 |
> I think some clarity around "Project" is needed here. Where do some of |
21 |
> these fall? Into the "project" sense that evolved from ebuild herds, vs |
22 |
> as a "task" conducted by a group of people. |
23 |
|
24 |
Mandatory spending is spending that is required for the operation of |
25 |
the Foundation. |
26 |
Project spending is literally everything else. |
27 |
|
28 |
> |
29 |
> Various groupings of expenditure that stand out from Bugzilla [1] |
30 |
> - Infra CapEx (new/replacement server & parts we own somewhere) |
31 |
Project |
32 |
|
33 |
> - Infra OpEx (rented servers) |
34 |
|
35 |
Project |
36 |
|
37 |
> - Development servers, CapEx & OpEx [e.g. catbus.sparc, new $ARCH] |
38 |
Project |
39 |
|
40 |
> - PR OpEx: consumables, e.g. flyers, DVDs |
41 |
Project |
42 |
> - PR CapEx: re-usable banners |
43 |
Project |
44 |
> - PR OpEx: GSOC reimbursements |
45 |
Project |
46 |
> - ?? NitroKey "project" (OpEx per accountant) |
47 |
Project |
48 |
> - ?? Memorial donations (fmccor, avenj, ??) |
49 |
Project, but slightly more debatable. |
50 |
|
51 |
> |
52 |
> None of these are mandatory spending, but they all have various degrees |
53 |
> of paperwork and complexity. The PR consumables are frequently very |
54 |
> short deadlines, because they get left to the last minute. |
55 |
> |
56 |
> Historically, Infra has an unofficial annual budget of $1K for |
57 |
> replacement parts, that didn't include any of the OpEx (Hetzner, AWS). |
58 |
> - Past that budget point, funding approvals were needed. Is that likely |
59 |
> to stay the same? |
60 |
> - Would other projects have baseline budgets in the same way? |
61 |
|
62 |
I'm not the council; so I'd ask them. Generally speaking I think |
63 |
pre-approved spending limits are mostly a means to avoid doing |
64 |
additional approvals / paperwork. |
65 |
I assume the council does not want to: |
66 |
- approve random infra spending below a certain limit because we may |
67 |
have lots of txns. |
68 |
- approve monthly spend on leased hardware when the amount does not fluctuate. |
69 |
|
70 |
> |
71 |
> > I'm looking for feedback from the community and the board on this as |
72 |
> > we will change the board procedure if the board votes to make these |
73 |
> > changes (we have not yet voted.) |
74 |
> > |
75 |
> > The ultimate goal is to operate a more of an arms-length arrangement |
76 |
> > with the Foundation; the eventual outcome being that the Foundation |
77 |
> > will cease to exist at some point and be replaced by an arms-length |
78 |
> > umbrella holding company. |
79 |
> To what degree/spending level will the approval of BOTH bodies be |
80 |
> required? E.g. Sparc project wants to spend $50K on a top-of-the-line |
81 |
> Oracle server. |
82 |
|
83 |
Technically, the board dispenses funds (and reimburses, etc.) So we |
84 |
exercise some approval just by doing that. |
85 |
|
86 |
Structurally that approval should be pro forma (e.g. all judgement of |
87 |
whether we should spend money is made at the council level.) |
88 |
Some ideas of transactions the board may decline are things like: |
89 |
- Transactions that do not appear to be legal in our Jurisdiction. |
90 |
- Transactions that result in significant risk to the Foundation. |
91 |
|
92 |
I think the primary risk (besides legal risk) is fiscal risk. So we |
93 |
might say something like: |
94 |
- The board reserves 3x Mandatory spending as a fiscal reserve. |
95 |
- The board will approve purchases until the reserve is reached, then |
96 |
decline additional expenses (so we can: e.g. pay our accountant and |
97 |
taxes and so on.) |
98 |
|
99 |
I think the chances that the council will drop 50,000 on a sparc box |
100 |
(or other significant expense) is about the same (minute / small / |
101 |
low) probability as the board doing the same action. |
102 |
|
103 |
> |
104 |
> > Do you think this is a good idea? |
105 |
> Overall yes, because it prepares the council to take on ownership of |
106 |
> budgetary control in the larger organization. |
107 |
> |
108 |
> > Are there more than 2 buckets of spending? |
109 |
> Do the OpEx & CapEx spending need seperation? |
110 |
|
111 |
As I mentioned in the council meeting; you and I are Infra and also on |
112 |
the board (and you are board treasurer) so the amount of paperwork |
113 |
related to budgeting is low because we all hold similar positions and |
114 |
share an understanding of the fiscal nature of the Foundation. |
115 |
|
116 |
My intent in the current bucketing is to say "the council doesn't |
117 |
approve mandatory *foundation* spending; its approval lies with the |
118 |
board." I can submit an estimate of all mandatory spending if needed; |
119 |
and we can summarize it in the annual reports; the mandatory spending |
120 |
is purchased from the free market in arms length transactions, etc. |
121 |
|
122 |
Obviously the gentoo *project* itself has mandatory spending (e.g. we |
123 |
lease 3-4 boxes from hetzner and gentoo would cease to be if we |
124 |
stopping paying for those) and I would expect the project to vote to |
125 |
continue to pay for those expenses (and they are definitely opex.) But |
126 |
they are separate from *Foundation* expenses. |
127 |
|
128 |
> |
129 |
> > Looking forward to your feedback, |
130 |
> Further discussion: I think process improvements are needed regardless: |
131 |
> The funding requests/discussion should wind up in SEPARATE bugs than any |
132 |
> confidential details, so that the confidential parts [2] can be locked |
133 |
> rather than public. |
134 |
> |
135 |
> Does the entire Council need to know some of that PII, or just the |
136 |
> treasurer handling the reimbursements? |
137 |
|
138 |
I think structurally its fine for the council to know it; but not the |
139 |
public or developers-at large. |
140 |
|
141 |
Imagine a hypothetical where the Foundation is gone and Gentoo is, |
142 |
say, a member of the Linux Foundation. |
143 |
Now the Liaison (council) will see PII, and the Linux Foundation will |
144 |
see PII (to disperse funds, etc.) |
145 |
|
146 |
In the current implementation, the liaison (council) will see PII and |
147 |
the Gentoo Foundation will see PII (again solely to disperse funds, |
148 |
etc.) |
149 |
|
150 |
-A |
151 |
|
152 |
> |
153 |
> [1] |
154 |
> Search all bugs for "finance" in the bug whiteboard, which is part of a |
155 |
> set of tags I used as part of the financial auditing I did. This list |
156 |
> has 96 bugs in total, of which 22 are private, most frequently because |
157 |
> they contain PII. |
158 |
> https://bugs.gentoo.org/buglist.cgi?list_id=5857395&order=bug_id&query_format=advanced&status_whiteboard=finance&status_whiteboard_type=allwordssubstr |
159 |
> |
160 |
> [2] PII such as shipping addresses, payment addresses, names of |
161 |
> non-developers, as well as business details like things from some |
162 |
> sponsors. |
163 |
> |
164 |
> -- |
165 |
> Robin Hugh Johnson |
166 |
> Gentoo Linux: Dev, Infra Lead, Foundation Treasurer |
167 |
> E-Mail : robbat2@g.o |
168 |
> GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 |
169 |
> GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 |