Community Governance

Community
1

I wanted to pick up a few threads here that I let drop back in October, concerning the redesign of farmOS.org, how Open Collective funding should be allocated for projects like this, and the general topic of community governance that we touched upon in the 10/14 Monthly Call.

The problem

Specifically, the issue came up on that call of how to vote or otherwise garner consensus for the disbursement of Open Collective funds for two tasks to improve farmOS.org: 1) migrating from mkdocs to Gatsby, and 2) authoring guides, tutorial videos and other official content to aid users.

Full disclosure: I’m proposing to pay myself for the site migration. cc’ing @kirsten_mc, too, b/c I’d love for her to take the lead on content authorship.

I’ll open a separate thread to discuss particulars of that proposal, but I think it presents a good example of the governance challenges posed by such a significant disbursement of community funds (the migration alone will likely consume half the current OC budget). It raises questions like:

  • Who gets paid?
  • How much do they get paid?
  • How does the community benefit from this?
  • Are these decisions aligned with the community’s shared values?

Etc.

One possible solution

I think the two best platforms for deciding these types of questions collectively are this forum and the monthly calls. Both enjoy a fair amount of participation from a broad base of users and developers and seem well-suited to facilitate free discussion as well as voting. The Riot/Element room is another potential option, but I believe it would be hard to conduct a vote there. Discourse (the forum host), on the other hand, has a nice polling option built in; it’s not the most rigorous or sophisticated, but I think it will make do for a first attempt at this.

I think if proposals are initiated with a forum post and poll, then we can use the next monthly call to allow final comments and cast any last votes. As a safety measure, I think it’s also wise to make sure that @mstenta, @paul121 and myself, as project maintainers, sign off on the proposal as well. This sort of veto power felt a little dictatorial to me at first, but truth-be-told, Mike has to approve all expenses on OC anyways, so this just seems like a good way to be transparent about that process, while also guarding against abuse.

Procedure for proposing funded work

First of all, I’m just restricting this to “funded work”, to distinguish it from other expenses (eg, server costs, app store fees, etc). Those should probably have some guidelines established, too, but I just want to reign in the scope here.

So to summarize:

  1. Create a proposal on the forum, as described below in “Proposal requirements”.
  2. The voting period will last a minimum of 30 days from when the proposal is created.
  3. After the voting period concludes, if the proposal is approved, it will undergo a final review process at the next monthly call, as described below in “Review process”.
  4. If the review process accedes to fund the project, those funds will be earmarked* and disbursed upon completion.

* @mstenta, does OC have a means for earmarking funds before disbursing them?

Proposal requirements

As for the proposals themselves, there should probably be some guidelines. I’m really inspired by the Inkscape community’s process, though we probably don’t need anything quite so rigorous.

  • Name of the recipient(s).
  • A “Scope of Work” including project requirements and deliverables
  • Acceptance criteria, and a designated reviewer.
  • A fixed or maximum cost for the work to be done.
  • A date for completion.
  • A poll, complying with the “Poll requirements” below.

I suppose proposals could also comprise multiple projects, in which case each project should separately list all of the requirements.

Poll requirements

  • MUST be Single Choice
  • MUST be set to Always Visible
  • MUST permit votes from all forum members (ie, the “Group” should be left empty or set to trust_level_0)
  • MUST provide a simple yes or no question as the Title, (eg, “Do you support funding <proposal name or brief description>?”
  • MUST provide two options, “Yes” and “No”.
  • MUST check the “Show who voted” box

Review process

  1. Final call for comment.
  2. Close voting on the forum, collect votes from any non-forum members in attendance, and tabulate the results.
  3. If the proposal has a simple majority of votes for approval from community members, it will be submitted to the farmOS project maintainers for final approval.

An evolving process

I want to emphasize that, not only are these procedures totally open for discussion, but even if we go forward with a solution for now, as a relatively young community, we should be flexible and open to change. I hope that at some point these governance policies could evolve into something more rigorous and perhaps even legally enforceable, but I think the best way to get there is through an Agile-like process, so we can learn early what works and what doesn’t and improve on the process each step of the way.

As I’m wrapping this up, it also seems pretty meticulous, so please feel free to comment on ways this could be streamlined. Also, let me know anything I left out. Open to all suggestions!

6 Likes
2

I love all these ideas @jgaehring, and I’m excited to see what we can start putting the OpenCollective funds toward! And I’m especially excited about the farmOS.org next steps. :slight_smile:

One thing we’ll also have to figure out is how to deal with multiple proposals, available budget, and prioritization/scheduling. If we use a big chunk of the pot on a proposal, next proposals will need to wait for that to recharge. And if there are multiple proposals in parallel, there will need to be a process to decide which ones are prioritized first. But I think we can start to develop that process as we move forward.

@mstenta, does OC have a means for earmarking funds before disbursing them?

I don’t think OC has any way of “earmarking” or “setting aside” funds for a specific purpose - but they are frequently adding new features, so it’s worth checking again.

This raises another consideration in my mind: we’ll need to keep track of “ongoing” expenses alongside these “proposal” expenses, to ensure we don’t accidentally use funds that are needed for ongoing expenses. The only ongoing expenses we have right now are hosting https://irc.farmos.org ($7/mo) and the yearly Apple developer license (~$100/yr). That isn’t much - but we may need to add additional things in the future.

So, it’s probably time to consider setting up a public budget spreadsheet to track these things. :slight_smile:

This spreadsheet could track both ongoing expenses as well as serve as a place to organize (and maybe schedule) approved proposals. We can also include some rough estimates of monthly income.

Monthly income can fluctuate… as new backers join, or old backers leave (no judgement! we appreciate all support!)… and there’s the possibility of one-time donations. So estimating available budget is a little more complicated than ongoing expenses.

Maybe updating the income estimates could be a regular part of the monthly calls.

Excited to see where this takes us!!! :smiley:

1 Like
3

Maybe it makes sense to hold periodic, general budgetary calls, like say once a quarter during the monthly call. Or maybe we just have an annual budget review then as needs arise. Could be perfect timing, with January just around the corner.

This is a great idea! Yea, it definitely gets a little complicated, but I think we can break it down into categories like accrued donations, projected donations, recurring expenses, discretionary budget, etc.

I’m excited too! This could definitely open up new possibilities for what’s possible in the community!

2 Likes
4

One thought I want to add regarding funding of proposals: It would be great if there was a way for community members to send one-time donations for a specific proposal. Note that this might be more relevant to feature-oriented proposals than the farmOS.org migration mentioned above! I’m also making the assumption that community funds are indeed viable to (partially) fund more general feature development in farmOS, ideally features that would benefit the majority of users and/or provide a foundation for further feature development.

In general, it’s reasonable to assume someone in the community might be extra excited about a particular proposal & want to help see it to fruition! Similarly, if a community member is worried the general funding pool won’t provide as much benefit to them, this provides them a way to contribute where they want.

You both touched on challenges related to this:

Looking into this a bit further, it looks like OC tiers could work for this (see the tiers documentation). Notably, there is a “Goal” option that displays a progress bar on the tier. With the amount type set to “fixed” & interval set to “one time”, this could enable a way to track donations dedicated to specific proposals. Each tier can also have its own “page” that could have more info about the proposal & link back to the original proposal. (This is all based off of reading the docs, hard to know without being able to test it out. I’m assuming contributions to these tiers must be connected to them in some way? Not 100% sure on this.)

It’s hard to find many examples of Tier Goals in use, but I did find one (this is a $/month goal, but it looks like they can be fixed as well): https://opencollective.com/parcel#section-contribute

A significant limitation with this OC tiers idea is that funds cannot be returned if the goal is not “reached” (I believe this is true). Another platform like Kickstarter is arguably better suited for proposals that are purely “funding campaigns”, but perhaps there could be a hybrid approach here as well. If a proposal “passes” the voting phase, an additional funding tier could be created for the proposal. These additional funds could be used for “extra features” or “stretch goals” that the proposal could define.

Considering that a proposal could have multiple projects, perhaps a base MVP project could draw from the general farmOS community pool, and the proposal could outline additional projects as “stretch goals” to be completed pending enough funding. If funding is allowed to continue throughout the project development, a completed MVP might help draw in additional funding for the “extra” features, without needing to go through another proposal process (although there are benefits to re-assessing feature dev through a new proposal)

Extra emphasis on this! :+1: My ideas above might not be super relevant right now, but the ability to fund specific proposals could greatly improve what work comes from proposals. In the end it might not be possible due to limitations of OC, but seeing Tier Goals makes me optimistic that it would be worth considering.

3 Likes
5

Agreed on all points @paul121!

Another big consideration with OpenCollective is that they take 10% (not including credit card processing fees). So any bigger development project would need to raise a good chunk more to cover those costs as well.

That is… IF we want to do it all through OpenCollective. But that’s not a requirement.

Many of the “big” sponsored developments thusfar have been done outside of OpenCollective, as a simple contract between myself and the group/organization that wants to sponsor it.

So I think we’ll still make that kind of decision on a case-by-case basis, and weigh the costs and benefits of using OC. The main benefits that OpenCollective provides us are:

  1. transparency - everyone can see the donations and what they are spent on
  2. ability to collect lots of small donations

Transparency can be achieved outside of OC too.

It would be neat if there were a way to use OpenCollective to document things that are outside of their platform as well, just to be able to show it (assuming the group/organization sponsoring wants that). We also have the “Supporters” page on farmOS.org for that purpose (which predates our use of OC): https://farmos.org/community/supporters/

2 Likes
6

I think this is the key. In my own thinking about these issues, I’ve come to the conclusion that something like Kickstarter is probably the best solution, especially given the points @mstenta raises above. Kickstarter has their own fees as well, but you get so much more for it in terms of exposure and the feature set they provide, which is 100% towards funding specific projects, w/ perks etc.

I’m still really inspired by https://webpack.js.org/vote/, which I mentioned in “Feature Bounties”. And with the “Redesign of farmos.org”, I think it might be totally possible to do something similar that potentially leverages the Kickstarter API, instead of OC. Perhaps in the long run this could lead to some kind of more bespoke solution that we develop ourselves, to cut out the middle-man and reduce fees.

Anyways, lots of possibilities, more that I can go into now, but exciting to think about and keep discussing!

3 Likes
7

Also want to add, I think we’re really discussing 3 separate modes of funding, which can easily co-exist:

  • Contract Sponsorship, where one sponsor or a small number of sponsors contract someone to develop an feature which will be added to the FOSS codebase.
  • Crowdfunding, where a large group of people can sponsor similar development at voluntary funding tiers, perhaps with perks.
  • Community Funding, where portions of the community pot (OpenCollective, mainly) are allocated to fund broader community goals that don’t fit within the scope of a single development project, like server fees, etc.

I guess for the sake of this topic, I’d like to zero in on the last mode. Eventually, I’d love to see similar principles of governance applied to all 3 areas, perhaps if/when we fully incorporate farmOS as a non-profit, or cooperative, or whatever. The real opportunity right now, I believe, is that we can afford to experiment with our limited OC budget for now, and learn from the experience to ensure that, once we do have more demanding governance concerns, we’ll be better equipped to deal with them.

3 Likes
8

Good distinctions @jgaehring! :+1:

9

Holy crap, I took a deep dive into the “Governance and organizational process” section of the OFN Handbook tonight and… :exploding_head:

Some key sections that I want to bookmark here are “Economic model” and “Software improvement process”, but the whole guide seems like a great framework for any questions we may have about governance in the future. I’m especially taken with the concept of “lazy consent”, as a way to make decisions collectively but with minimum overhead.

Wow wow wow!

1 Like
10

Great links! I’ll have to spend some time reading more!

The “lazy consent” concept strikes me as similar to the “do-ocracy” concept that has been used to describe Drupal development.

https://communitywiki.org/wiki/DoOcracy

There are arguments for and against the concept (as with anything). One aspect that I like about it, which is also related to Drupal and farmOS’s code structure is: if you want something, you can do it… and if you can’t do it in core, you can do it in contrib (in a module). So the barrier to allowing contributors to “do” anything is extremely low. Most things don’t require agreement in the core project - they can be built (and supported) in “contrib land”. Then, over time, if they garner a lot of users (a form of consensus that the code/solutions are valuable), there is always the possibility to pull it into the core project itself. It’s a very flexible “do-ocratic” model I think! :slight_smile:

1 Like
11

Awesome! I’ll have to read more on do-ocracy.

One distinction I’ll highlight, however, is that “lazy consent” applies to “core” decisions as well. In other words, it handles decisions about shared resources, where you don’t want just one person to unilaterally do whatever they want. If I understand correctly, “lazy consent” means decisions default to consensus. So if no one cares enough to mount an explicit objection to a proposed use of community resources, then it can proceed. That relieves the proposer from the burden of actively pursuing consensus, and instead puts the onus on the objector. Like presumption of innocence vs presumption of guilt.

I have to imagine there still need to be safeguards built into that model, like determining who can submit a proposal and who can object. Otherwise there seems to be too much potential for abuse. But it certainly seems plausible, since ultimately there will still be a central authority that has to release any funds or merge any changes.

1 Like
12

objection to a proposed use of community resources

Ah yes! I realize I wasn’t really thinking in terms of funded work, too, which is a large part of what this thread is about. :wink:

1 Like
13

On the same topic, you might also find Holocracy interesting…

It effectively defines an algorithm for self-evolving organizational structures that minimize contention and blocking depenencies.

2 Likes