Skip to content

Latest commit

 

History

History
100 lines (71 loc) · 5.22 KB

grants.md

File metadata and controls

100 lines (71 loc) · 5.22 KB

Open Cooperative Ecosystem budget distribution

Background

Since OCE starts, we adopted the Faircoop (Open Coop Work) budget distribution protocol to sustain ourselves. Basically it considers all people contributions in hours, as hour is the unit of measure adopted by the ecosystem to distribute income among partecipants, both for fixed income and for occasional task based works. Hourly rate is agreed on the general assembly. Meanwhile this protocol can work well for basic coordination, it starts to become harder to organize looser, etherogenous and interconnected works based solely on the amount of hours a person logs. People feel easily discouraged to log their activities based on a hourly rate, a protocol more keen to an exploitation system, than a cooperative one. On the project management side, the whole workflow suffer from not being able to define activities in other ways rather than hours. The following proposal is a slighlty different way to organize our ecosystem activities flows, from budget approval to budget distribution.

What we want:

  • growth of the ecosystem
  • accountability
  • coordination
  • transparency
  • happy healthy community
  • learning
  • simplicity (in the process)
  • excitment + celebration

What we don't want:

  • people burning out
  • too much paperwork
  • competition
  • centralization of power

The most valuable thing we have is the community. Half the reason for oce budget distribution is to give everyone a fair opportunity to get paid to work on OCE.

The OCE protocol

The budget distribution lifespan goes from 1 month up to 3 months. Indipendently from the duration of the grant assigned, the budget distribution lifecycle shall include the following steps:

  • Prepare a proposal
  • Approving a proposal
  • Build it
  • Assembly retrospective

The agents involved are:

  • Working groups
  • User base / backers /funders

Working groups

They are loosely group of people (inside OCE group) that converges together to work on specific proposals. A working group can have the lifespan of a grant, or it can continue working together endlessy. We encourage to make little working group, up to 4 people, to foster the development of coincise and focused works and at the same time to increase the chance to receive a sufficient income for each partecipant. It is up to each working group to present together with the proposal, the needed budget and the formula to split the income among members. Based on the proposal, a working group can be also made by a single person.

Protocol Diagram

FAQ

Why max trimestrial? : To give enough mental and economic stability to work on OCE while receiving a monthly income and to maximize the possibility > to end up with a valuable but small production-ready work.

who can apply?: Everyone! Assemblies are open and grants are assigned by consensus.

Grants process

1. Prepare a proposal

It's a good idea to explore the OCE roadmap made by userbase and devs and get feedbacks before posting a proposal.

Proposal requirments:

  • What are you going to do? (does it relate to what we want more of?)
  • How are you going to spread your months of work?
  • Why are you motivated to do this?

2. Approving a proposal

We'll make the first week of each month when we approve the next grants. We will discuss the proposals for the given months in our assembly and decide which we're going to fund. The community may suggest changes to a proposal. A grant that is not included in a the current round might be in the next. If a grant is turned down, you can still make another grant.

We'll only make a few grants at a time, so that we can learn how it goes and improve the process later.

3. Go for it!

When the proposal is accepted, the grant will be paid up-front or on a monthly rate (based on funders/backers liquidity).

Grant requirement:

  • keep a Dev Diary about what you're doing on OCE Dashboard
  • Partecipate on monthly assembly

Why a Dev Diary: this is the simple way to share learning, and for everyone to get excited about what you're doing. We can also reference it later for others interested in funding, to showcase what awesome things we've done. Also it encourages transparency among working groups and funders.

4. Declare it done (enough)

We work closely with our userbase and in the most case we our also userbase and activists, other than devs. We need to get thing done and use it short after their release.

An important step at the end of the grant is the assembly retrospective, where working groups share their story about the whole development process, to enhance knoledge, activate learning process and allineate roadmap to actual results.

Open Assemblies

We can discuss always the proposals. You are welcome to make suggestions or express support for a proposal. At some point, During the monthly assembly we will make a call on which proposals we've agreed on. If there is a disagreement, we'll just keep talking about it.

grant ideas!

  • ecosystem support
    • overhaul the documentation
    • storytelling in accessible formats
    • technical overview (whitepaper)
    • development screen casts
  • a specific feature
    • ...
  • a project that enhances the ecosystem
    • ... other personal roadmaps / proposals:
    • ...