Skip to content

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

Closed
drjwbaker opened this issue Dec 10, 2019 · 9 comments
Closed

Spending prioritisation #1593

drjwbaker opened this issue Dec 10, 2019 · 9 comments
Assignees

Comments

@drjwbaker
Copy link
Member

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:

  1. Board of Directors Meetings will (eg ProgHist Ltd Board of Directors Meeting 12 December 2019 #1579_ use meeting minutes to report back to the ProgHist Members (that is, the all of the Project Team ProgHist Ltd Board of Directors Meeting 12 December 2019 #1579 (comment)) on income, spend, and current value of monthly Patreon supporters.
  2. The Project Development Team will ask the Members for suggestions of things to spend money on (7 days deadline) via a ticket. There is no form for this, but suggestions should come with a justification and state whether it'll be an ongoing or one-off cost.
  3. PDT makes a recommendation for spending. This might include a recommendation of no spend. If no suggestions are made, no spend is the default. Members will have 7 days to comment on the ticket.
  4. PDT informs Finance Manager (@drjwbaker) who liaises with relevant Members to make the spend.
  5. Steps 1) - 4) will happen, roughly every 2-3 months. But if the spend is urgent, Members can ask the PDT Lead (@drjwbaker) to check what money we have and go through steps 3) and 4) for single items.

Does this sound reasonable @acrymble @amsichani?

@drjwbaker drjwbaker self-assigned this Dec 10, 2019
@spapastamkou
Copy link
Contributor

Thank you @drjwbaker for this. In step 3, adopting or not the recommendations is based on lazy consensus?

@drjwbaker
Copy link
Member Author

That sounds sensible to me (again, avoids adding an extra process).

@drjwbaker
Copy link
Member Author

Note, I missed a step:

  1. Board of Directors to review any ongoing spend at each Directors meeting.

@acrymble
Copy link

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.

@drjwbaker
Copy link
Member Author

From https://www.patreon.com/theprogramminghistorian:

Your contribution enables us to maintain and update published lessons, to devote extra time to work with our authors so they produce clear and accessible instructions, and to expand our multi-lingual and culturally sensitive approach to learning and teaching.

This includes infrastructure.

@drjwbaker
Copy link
Member Author

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.

I'm up for simple :)

@acrymble
Copy link

@drjwbaker I think this is actually now being used, no? Can we transfer to the wiki and close?

@drjwbaker
Copy link
Member Author

drjwbaker commented Jan 16, 2020

Yes, to recap:

  1. Board of Directors Meetings will (eg ProgHist Ltd Board of Directors Meeting 12 December 2019 #1579 use meeting minutes to review and report back to the ProgHist Members (that is, the all of the Project Team ProgHist Ltd Board of Directors Meeting 12 December 2019 #1579 (comment)) on income, spend, and current value of monthly Patreon supporters.
  2. Team Leaders put in spending requests to Finance Manager including: what budget request is for, why it is needed, and if the spend is one-off or intended as ongoing.
  3. Finance Manager discusses request from Team Leaders and makes decision, seeking advice from wider team as appropriate.

Right?

@drjwbaker
Copy link
Member Author

Added to wiki. Closes unless anyone objects!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants