-
Notifications
You must be signed in to change notification settings - Fork 227
Spending prioritisation #1593
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
Comments
Thank you @drjwbaker for this. In step 3, adopting or not the recommendations is based on lazy consensus? |
That sounds sensible to me (again, avoids adding an extra process). |
Note, I missed a step:
|
I think we need to be careful about Patreon. Those people are signed up to support specific activities around copyediting and revising old lessons. We don't want to take their contributions for granted. I think we need to open a separate conversation about diversifying our small-cost income streams. My view is that we currently have £0 for covering Netlify, but possibly have a need to change that. Can we use this opportunity to suggest the team leaders add in their next report possible costs for the coming 6 months related to their remit? Then we know what we need to find (with some extra just in case)? -- In terms of the proposal, I'd suggest massively simplifying it. Board reports on money in reserve as per step 1. Team leaders put in spending requests to finance manager who discusses and makes decision (seeking advice when he/she wants or thinks needed), and quarterly Finance Manager provides a breakdown of spending to group who can scrutinize his / her choices to improve in future if necessary. Finance manager doesn't put us into debt. |
From https://www.patreon.com/theprogramminghistorian:
This includes infrastructure. |
I'm up for simple :) |
@drjwbaker I think this is actually now being used, no? Can we transfer to the wiki and close? |
Yes, to recap:
Right? |
Added to wiki. Closes unless anyone objects! |
All - we have an issue with a free service (Netlify) changing terms of service in such a way that means we might need to start paying. The feeling that this scenario might arise at some point is one the reasons why we set up ProgHist Ltd: to "Protect The Programming Historian from changes to service agreements of those ‘free’ services upon which we rely." https://github.com/programminghistorian/jekyll/wiki/Project-Development-Team
Before we get into the specific Netlify issue (@mdlincoln @programminghistorian/technical-team: do we need a ticket to discuss if spending money on this is a good idea?), we need a mechanism to ensure spending priorities are accountable. I want this to be light and reactive (so we can spend money quick if we need to). We have enough policy. But I want agreement on what we should do (and if you all want a heavy process, then I'm not going to fight it).
My proposal is:
Does this sound reasonable @acrymble @amsichani?
The text was updated successfully, but these errors were encountered: