Compensation framework

I’m ‘just’ a user member, but I’d say that assuming they’ve both done 40+ hours that the first people who should be (back) paid are @chris and @decentral1se, no? As I understand it there wouldn’t be a product to sell if not for all their heroic hard work.

Does anyone have the notes from our July 24 WG meetings? Those aren’t posted on the wiki.

@wouter there is some pieces in here that seem to deviate from what I thought we agreed on. Most specific is:

I thought what we agreed on is:

  1. Each Circle will be allocated a budget (decided at All Hands)
  2. Each Circle will be responsible for drafting tasks in NextCloud Deck, and allocate budget to high priority tasks, as budget allows (e.g. write and publish data privacy agreement)
  3. Members will take on these tasks, and if there is a monetary amount tied to it, they can claim this by invoicing OC when the task is completed and accepted by the Circle

Specifically, this is not tied to the amount of time they track on the time tracker, for the particular task, or in general, and there is no “25 euro per hour” mentioned.

I recall we came up with this scheme so we can start paying for highest priority work with our very limited budget at the moment, with the goal of expanding as sales ramp up, such that all tasks drafted by Circles can be compensated, and at the same time limit people from logging hours where the value to Meet.coop is not shared.

@Graham @mikemh @osb you guys were at the meeting as well. Please correct me if my understanding is incorrect. The difference between “first doing the work, then later all decide how much each person gets paid” vs. “budgeting for specific tasks and assigning a monetary amount that one is guaranteed upon completion” I think is a big distinction that I’d like to clarify before moving this forward.

1 Like

Hiya @benhylau Good to have you back online :wink:
I think you are correct about what was discussed and proposed …
but not sure it was ‘agreed’ … I think we should work with the proposal above (bcoz that’s what @wouter has put fwd) and make recommendations / suggestions for a new version we can all vote on… that was what we decided to do in the last All Hands (when u were away)

1 Like

So during our WG meeting, it was raised that allowing people to self-report hours and tag those contributions as “compensation required” run into the issue where someone may be doing tasks that are not recognized as high priority by the collective, or spending many hours on a trivial task, etc.

I also brought up that allowing individuals to tag their time as “no compensation is expected”, over time, could make the cooperative favour participation by those who are more privileged and thus do not need compensation for their work, creating a bias to who can and cannot participate. What we want to create is livelihood through work.

This is the basis on which I suggested to collectively as a Circle to decide on relative task priority, and budget for important tasks, then let people work on the tasks with certainty of how much they will be compensated. This also forces us to practice scoping tasks and clear success criteria, so we do not go down rabbit holes and burn hours and hours without concrete accomplishments that further the goal of the project.

This is the part where I feel is most problematic in @wouter’s proposal:

One must first put in hours of labour, without knowing how much compensation there will be until months afterward. Whether the work will be fairly compensated also depends on how other members decide to spend time on tasks that they self-assign priorities and value.

For example, I may think that researching X is worthwhile of 60 hours of labour, but others actually think it is a low priority item and does not further our goal too much. Now because I spent 60 hours on some rabbit hole, @osb who spent 20 hours updating the website and OC so we can receive contributions now has only 1/4 of the budget to get paid.

I honestly believe the current proposal implements the wrong incentive system. I’d like more collective prioritizing and budget allocation ahead of work, that carries more certainty than compensation that is as fair as can be upfront.

1 Like

:+1: But the possibility of disagreement over what counts as a rabbit hole is part of the evolution of a complex project. There’s foresight and there’s hindsight. No magic wand there?

What we want to create is livelihood through work

What we want to create is bigger than that? That is a core principle and a site of major constraint, as distinct from an eventual purpose. The purpose of meet.coop is layered and systemic, being achieved through contributions of work of more than one kind, not just livelihood work and not just immediate tech and financial operations. This is how radical social and economic change works; organisation development too.

As a movement of change, meet.coop operates in the mutual sector too, where contributions always have been made mostly with sweat equity rather than paid work. This is a truly hard balance to make - this is plain right now, in the bootstrapping phase, where some meet.coop contributors are way over-committed in sweat equity within a precarious economic existence. Regarding this balance, the contribution accounting practice and governance practice of meet.coop needs to go somewhere new, not falling back into one pole of the old tension between worker and consumer coops, and the old ‘solution’ of workers becoming their own bosses in an unchanged economy, still stuck in wage labour and commodity exchange. The early coop movement was organised that way, as mutualist production over and above and beyond livelihood work. The sweat equity is essential for the bootstrapping of a changed economy and society, and has to be carefully accounted for. Different folks make different contributions in this regard, over time.

A working draft under The purpose of each circle proposes a systemic description of the purposes of meet.coop in terms of production of and in commons. To summarise . .

  • The Organisational circle has the work of creating and stewarding a commons of organisational capability (the combined capability of the coop’s operational and user members) to make better-organised social and economic contributions to a transformed, commons-cooperative economy. This commons is constituted through work under careful accounting of members’ contributions, designed to enable fair and transparent payment for services and for work, as well as other kinds of recognition of contribution such as ‘good standing’, a voice in the coop’s assemblies, social justice and reparation, weighted votes, etc etc.
  • The Product circle has the work of creating and stewarding a commons of digital roomspace, mobilised sector-by-sector across coops and movement organisations in an evolving commons-cooperative economy, and collaboratively steered by users. This is an open and collaborative, evolving, use-oriented working relationship between the real-world users of a distributed technology/tools infrastructure (who make financial contributions to the infrastructure) and the teams who maintain operational access to the infrastructure and oversee its development - typically thro paid work as a contribution to their own livelihood.
  • The Technology operations circle has the work of creating and stewarding a commons of running code, across the coop’s devices and the users’ devices, according to principles of high quality, highly non-geek-useable, secure, privacy-oriented digital means including free-libre code, configured to enable enhanced cultural and economic capability at the distributed roots.

Fair and transparent payment for work - and other kinds of recognition - in all three intersecting areas of purpose, is a principle, to be overseen through the practice of task management in circles, and contribution accounting across all kinds of membership.

those who are more privileged and thus do not need compensation for their work

I think it’s unhelpful to apply the privilege tag to work that isn’t done for livelihood. Activists in the mutual sector always have contributed sweat equity - out of generosity, out of commitment to and belief in the movement, and always at the cost of personal hardship. We can see this happening right now in meet.coop.

Livelihood and ‘movement work’ sit together in varying ways. Personally for example, my own livelihood at this point in my life rests on a number of small scraps of pension derived from a lifetime of fairly precarious wage-labour and some gigging (thank you, capitalism). Throughout my ‘working life’ (stupid term!) I have done ‘movement work’ as my primary work, generally without payment, on rare occasions paid, while also getting my livelihood in some tangentially-related way - a version of the double shift. It’s a ceaseless juggling act, and a path of persistent hardship rather than privilege.

I would say that accounting with deep regard and care for the plurality of contribution and opportunity and hardship and necessity is more consistent with mutualist traditions, than applying privilege tags (which seem easily to become a weird inverted echo of the supremacy and Othering of the social order we oppose, rather than a brotherly and sisterly move to end it).

The idea that someone who goes beyond what is necessary for their personal livelihood, contributing over the odds and with generosity, is privileged, serves imho to obscure the hardship that always is part of the mix for a wage worker of whatever class-fraction, role under patriarchy or colour. I think it fails to acknowledge the bases of mutualism, which include contribution across differences, plurality of commitments and visions, recognition from the heart - and voluntary hardship for mutual ends, for the grandchildren.

I get what the privilege tag is about. And I don’t feel it’s helping here. Bootstrapping meet.coop and creating the commons is hard work all round.

There is nothing stopping people from rabbit holing into what they believe is important, I am proposing that financial resource allocation are derived from collective decisions and that this be deciding be done before people start on the work.

1 Like

Good to have you back @benhylau !

Quick remarks:

  • indeed the tracking of tasks should be incorporated. We talked about it and I didn’t manage yet to include it, please can you work it into the emerging proposal?
  • fortunately I had stored a copy of the meeting notes, and just put them in the wiki (this should be part of meeting routines): meet.coop - The Online Meeting Cooperative
  • I personally think it is important that we do use an agreed hourly cost tariff that is the same for all, otherwise we get into endless discussions and doubtful inequalities.
  • Also often there are tasks that cannot be time / money budgeted accurately in advance, especially not with an emerging operation as this one. So I am afraid that we cannot (in all cases) put a price to things in advance and have to rely on hours worked.
  • That said, let’s see how we can prioritise and indicate estimates of effort to certain tasks and evolve collectively over time. Maybe we need categories of tasks that are more routine (like “keep membership register” or “keep finances up to date” ; “run compensations routine at the end of trimester”) while other tasks are more one-off, (e.g. “set up form in website; estimate: 5hours work” or "researching X; 20h)
  • I think you get this wrong:

What I wanted to convey, but please review, is that the time worked is compensated with the agreed hourly cost tariff, and maybe in one period there’s not yet enough revenue to compensate it fully, so we keep that work open to be compensated later.
As said, please work into that the task relevance.
The end result should be that the working operational members, after having contributed their annual contribution, get compensated the hourly cost tariff for the relevant tasks. The circles work out their understanding of what is “relevant”.

that’s an important one, as in some cases at least more than one person/cooperative is involved in getting on board a new member. Which work do we track as part of the Sales process?

I also think we need to pay back the initial hours invested, and Chris did indeed the most hours. We should devise a plan that is reasonable in paying back the initial investment while also compensating the other team members. Maybe we could include a X% in the compensation framework that goes to pay back those initial hours? Study the registered hours until end august, withdraw annual operational contribution and payback each period with whatever revenue we generate (X% of that).

I leave it up to you and be back to review in 10 days approx, for a quick connect. Cheers!

2 Likes

I think that’s fine. The basis of estimates is probably always “time” anyways, and then we are here agreeing on a rate multiplier.

I think this happens often with software development tasks. I think it’s okay we are off by a factor of 2 in the beginning, then get better at it. However, if I am working on task X, and it turns out to be 10x the size, the responsible thing for me to do is to bring this new finding to my Circle, and say “well turns out it will cost 10x more” and we propose to revise the budget (if this task is still absolutely critical) or we say “well then we rather abandon it” collectively. This is actually exactly what I mean by preventing rabbit holes that somehow I am personally attached to but in reality, it accomplishes little for the project.

Okay this part we are in agreement. The way I imagine to do this is for the Circle to put a paid tag on a task, as in Sample task 1. This is a task that people can invoice Open Collective for.

The part I want to also raise is, it’s easy to put a $ value on this task from the start. For example, if the Circle thinks this is 4 hours of work, we put EUR 100. If I spend 3h or 5h to complete it, I’d still log actual hours and claim the EUR 100. I think operationally this is simple, and accounting-wise we can budget easily.

If it turns out this is going to be 40 hours of work, I better go back to my Circle and justify this, and decide together if we want to put EUR 1000 towards this task, before diving right in.

I also acknowledge the conversations around sales and back-compensation for already invested labour, and hope to find “operationally cheap” (i.e. does not require detailed spreadsheets multiplying tiny numbers over time and awkward invoice cycles) ways to handle them, but will keep those separate from this post.

Thanks for checking in during vacation @wouter :slight_smile:

1 Like

I am proposing that we still track all of member time spent to account for sweat equity, but have that detached from budget allocation at our current phase, so we can stay focused on tasks we collectively deem important.

Once we become wildly profitable, we can find schemes to compensate for all sweat equity financially. Before then, I fail to see other forms of compensation. We are not an integral cooperative with a mutual credit system. We can recognize people for their contribution, but as multiple members have already expressed financial precarity, I see the current subject to be ensuring members can participate in livelihood work.

I think if someone chooses to complete a task with a financial compensation attached to it, they can always decline the compensation by not invoicing the OC and have the $ contributed back to the pool of resources. I think it’s still important that Circles designate compensation amounts for tasks, as an acknowledgement of that pending labour. Upon completion of the task, the member is entitled to the payment. We can have a policy on whether this declined amount goes back to the Circle or the global pool, etc?

This emerging principle of “a conversation of a contributor, with/within the circle, about the contribution” is a good one :slight_smile: Does it have a sociocracy name @aaronhirtenstein ? I see it as an example of the live practice of valuING, that underlies a workable system of openvalue accounting. Templates and boilerplate goes only so far.

I’m in the middle of vacation still, but have tried to read up observations and comments so far. Here comes a new iteration of the Compensation Framework, aiming to take into account the feedback expressed so far. I feel that there’s bits and pieces that need to be refined, e.g. the details on how we track the Sales work and its compensation but also other aspects - and maybe the heat wave affects me at least :wink: I’m aware that we (as expressed in All Hands end July) hoped to put to vote a proposal by today, but I request your comments once more before putting a proposal to vote. If you have no further comments we can launch this in the Decision space in the coming days and leave a 7 days voting period.

Compensation Framework
We aim to iterate a practical version of contributory accounting that works now for meet.coop and may evolve into something more flexible and complex in the future. We focus on the present. NOW we need urgently to put in place a Compensation Framework that deals with contributions and compensations and guarantees the necessary compensations for the team to continue to build up Meet.coop.

So far we have started on the basis of people and organisations becoming members and making a contribution in time, money and/or other resources (like servers). Details of contribution levels are defined in the wiki:Membership and wiki:Service Levels .

Since May 2020 we set up a timetracker at time.meet.coop and (most) active operational members have started recording their time contributions to the tracker. Operational members are expected to contribute at least 40 hours of work (or through monetary or other contributions valued as such). We seek to compensate additional work, in particular if it is considered essential to achieving our mission by the Circle of Work to which it belongs. We are now moving to a “bounty model”, where each Circle of Work decides which work has priority and attaches a bounty value to it. E.g. when some task is expected to take 4 hours, a bounty of 100€ is attached to it. Situations will occur that in reality it is more, or less work (say 3-5 hours). In case the work is more or less the same as expected, no bounty changes are needed. But when there’s much more work required, the responsible/assignee of the task will need to go back to the Circle to discuss whether more budget could be assigned or whether the tasks need to be reformed or isn’t priority any longer.

Also we should take notice that some people have their income secured elsewhere or in other ways and don’t expect financial compensations from Meet.coop. A person having realised a task with a bounty can decide to waive the bounty. This initially leaves the Circle with more budget available, which it may decide to give back to the overall collective.

In summary, this leaves us with the following types of work, (as worked time registered at time.meet.coop):

  • contributed as part of the annual membership contribution of an operational member: tagged as “operational membership contribution by MEMBER-NAME” (with MEMBER-NAME the name of the operational member organisation or person)
  • compensation is attached: tagged as “compensation required”
  • no compensation is expected: tagged “no compensation expected”

In second case, of time worked for a compensated task, the worker should be a member of the Circle of Work where the work relates to. We expect the work to be related to a (linked) task in the task tracker (Deck application in cloud.meet.coop). Each of the Circles has relative autonomy to work within the scope and aims with the funded budget assigned and may prioritise certain work according to agile methodologies.

Revenue distribution
The incoming funds are then distributed as follows:
first basic fixed costs are paid: the costs for payment processing and fiscal hosting, the server and datacentre costs and the sales compensations. The sales compensation is the compensation for sales work, to attract new members and onboard them to the services they sign up for. This is initially compensated with 30% of the membership contributions of the new user members (in the first year). It will be reviewed and adjusted during the first year to agree compensation levels for ongoing members.

The remaining income is then distributed over the Circles of Work:

Organisation Circle: 23%
Product Circle: 22%
Tech Circle: 50%
Remains 5% that we dedicate to Legal, Insurance and Other costs. This is kind of an unforeseen budget.

In case grant proposals are funded, this isn’t necessarily through the same channel as OpenCollective / Platform 6 and therefore budget adjustments will need to be made to comply with the funding body and The Online Meeting Cooperative’s Compensation Framework.

Calculation of Compensations
Compensation will be calculated at the end of each trimester.

At the end of each period each Circle reviews the registered time of its members and the budget that has arrived to the Circle and selects all tasks with compensations assigned and time registered in the time tracker. Each Circle will compile a spreadsheet with the compensated tasks and compensations awarded to each worker.
These proposed compensations need to be presented in a designated folder in cloud.meet.coop and a validation period is respected of at least 3 days until the validated proposals are ready for payment. Payment of each sum requires a valid invoice by the operational member, either as organisation or as individual to be presented through the OpenCollective platform (or to the Beneficiary organisation in case of a grant proposal being funded).

Notes:
(1)The agreed tariff doesn’t include VAT or retentions for social security or any other deductions. The persons or organisations invoicing these compensations will be fully responsible for taking care of such fiscal or social responsibilities.
(2) Contribution accounting. There are several very interesting projects in the Open Value Accounting space and it’ll be interesting to learn from them and consider possible schemes for complementary currencies and mutual credits. Given our current tools to register financial and time contributions we are already on track to have the basics covered.
(3) these % per circle or for sales can be different; we are likely to iterate this over time.
(4) how do we deal with the time worked so far? We’ll need to analyse the time in detail, see what’s missing (Hypha?), deduct operational member contributions and see how we can pay off this initial investment.

1 Like

Thanks @wouter this looks much closer to what I have in mind. At the last call, I think @Graham was tasked to do some synthesis work in this thread, but I see that you have already done a large part of it :slight_smile: I think having @Graham do a close review of this will be helpful, and those who voiced concerned over the initial proposal at our All Hands can comment on this version if this addresses your concerns.

To quickly answer this, Hypha time is tracked in our internal tracker and I will move those to the Meet.coop one once this is approved, then it’ll be clear how I should tag things. I’d like to move things as aggregated hours if possible, instead of manually entering each one!

1 Like

I think in practice the suggested tags are too long and you’ll need shorthand version for each (a bit like the mock-ups @benhylau shared previously) or e.g. on mobile/ small screens it wont be obvious/ easy to read what each tag is.

I’d say this is fine for now, but assuming more sustainable levels of revenue in the future that 5% figure ought to be a lot higher (and could possibly make up part of future “indivisible reserves” as per this part of co-op principle #3 “Members allocate surpluses for any or all of the following purposes: developing their cooperative, possibly by setting up reserves, part of which at least would be indivisible”).

1 Like

I also think this is better, thanks for the work @wouter

But I still do not feel not totally comfortable with it. My main concerns after reading it are:

  1. Why is the 30 % for sales percent independently from the product circles budget?
  2. I also think there should be an incentive for providing BBB servers, so fixed costs deducted first should not only contain server costs but also service costs, e.g. if it is provided by another coop.
  3. For me it looks complicated to distribute income to every circle, wouldn’t that also mean that every circle needs to do budgeting and bookkeeping? That is quite some work and opens multiple points of failure if circle members are not on point with their finances…

I hope this doesn’t come around to negative. I like that a fixed rate seems to be now changed for “bounties”/estimates and the calculation after the end of each trimester.

2 Likes

I also feel this needs discussion, as I have two concerns:

  1. Logistically, “30% ongoing commission” seems like a lot of accounting work to maintain. I need to know this member subscribed for 6 months then terminated their membership, that one was in since March, etc. and in the end, these amount to 30% of EUR 10 per month scale of money each, but have to be evaluated and reviewed individually. I just don’t think the labour is worth it.

  2. I log my hours when I meet with potential clients like Dat and Our Networks. If I take a commission then I am double counting the labour.

I am supportive of having a way to compensate for sales work, but in a low overhead way (e.g. something that ends such as first X months of revenue) and having clear indication of how to log sales work. I feel that there may be a distinction between “internal sales” vs. “resale”. When I talk with potential clients, I see myself as “an employee of Meet.coop” but if someone who is less involved in Meet.coop operations (e.g. not in our Circles or time tracker) sources a client to Meet.coop, that’s more like a reseller relationship.

In a way we are already doing that. If we get a bill from Webarchitects for the collaboration tools we use (@Graham is sorting that) it won’t be raw server costs, I assume it includes service fees. That’s similar to if Collocall bills us for server monitoring service, or Koumbit bills us for setup.

It’s hard to draw that line between what is service and what is not. For example, does Hypha send a bill for service to set up virtual office practices, or @osb sends a bill for marketing services, and @melissamcnab for design services?

My proposal is, every budget must be approved by a Circle according to its budget, whether it’s hardware, collaboration tools, marketing, design, etc. and the only bills that we can pay are the ones that have a budget allocation from a Circle. Most like, we will prioritize hardware costs, but that is a decision of the associated Circle.

I think we can devise a low overhead way of doing this, but it’s probably necessary to prevent everyone getting blocked on a central “budget committee” that doesn’t have enough visibility into specific Circle needs. For example, if I tell Technology Circle now that you have a $3000 Q4 budget and you are responsible for server payments of ca.meet.coop, your Circle can pretty quickly decide on server provider, how much to allocate to Collocall for its sysadmin service, the roadmap and which work is compensated which is out of scope for Q4, etc. but if you try to take this up at an All Hands meeting, we’ll probably burn through 2 All Hands (about 20 person hour).

Logistically, you can just have a spreadsheet that sums up to $3000 and make sure to allocate no more than that to the tickets in Deck.

1 Like

let’s see how we can resolve the observations made

right now we need a first version of a working compensation framework, and I agree that in the future we’ll want mechanisms that consolidate cooperative reserves and possibly dedicated funds.

the mechanics described take all revenues of the selected period and allocate direct costs for servers and payments, and for the sales compensations. The remaining revenue is then spread over the Circles primarily. This could also be different of course, please make a proposal as you consider more appropriate.

In previous discussions people agreed that a sales compensation as a percentage over revenue would be most sensible, as in many cases it can be tricky to track time and/or decide bounties on a case by case basis. Administration will need certain detail, as to know who worked what new members and to what periodic compensation does that lead.

Maybe we should go into more detail and discuss the use cases for how we attract and onboard new members.

One case is where people / orgs have heard about meet.coop and contact the contact@ mail and/or register and engage through any of the other open platforms (mainly the forum for now). We can consider this expression of interest a “lead” and according to certain logic assign this among the Product Circle for follow up. Maybe here we can define a few standard steps and budget (time) for helping the potential member to join. In that case the % sales compensation can be left unclaimed and channelled into the Product Circle budget.

A second case is where Operational members (and their staff) proactively approach people and orgs in their network and achieve new memberships. The sales compensation was thought for this case in particular. It is designed to generate sales and limit the need for coordination between us. Consider that not all staff from operational members is part of the Product Circle - we’d expect maybe a minimum of one per ops member engaged in sales to be member of the circle to convey experience & agreements more easily from ops member ↔ product circle?

A third case is like the previous one but more than one ops member has been involved in the sales process. In this case both claim part of the compensation and will need to agree how they divide it. It’d be helpful if sales work is still time registered but maybe with a different tag?

Indeed, there should never be double counting! But in the model we’re envisioning here together, your meeting with potential members would be either entitled a bounty in the task tracker (from the Product Circle) (in the first case) or a sales compensation (in the second case).

Back to the admin work to keep track of ongoing membership revenues: somehow we’ll want to have an updated overview of all members and of what type and level. I’m afraid that that’s not 100% to be inferred from OpenCollective, but mostly it should. Is there then a way to automate i.e. connect to the OC API to track this in a spreadsheet or so? We’ll need to work on that spreadsheet in any case…

+1

I’m keen to hear your proposals to how we can improve the mentioned critique in a workable first version compensation framework.

1 Like

Feedback Compensation Framework

Thanks a lot for the contributions to the compensation framework. Things start to get shape and many good points are being made. Nevertheless, we still see some points worth discussing. We want to mention some critical points and propose a slightly different approach:

Criticism on proposal:

  1. Sales is treated differently than other circles.

Treating sales work differently then other work circles inherits a problematic concept from regular capitalist business. It leads to sales being disconnected from the common vision. An incentive based on new user members can lead to sales circle thinking mainly in new sales rather than sustainable customer relationships. And, as mentioned above by benhylau, is difficult to calculate.

  1. A money-based bounty in combination with expected working hours leads again to a fixed hour loan

For a single worker the benefits of the collective project is disconnected from their own benefits. No matter how well meet.coop performs they get their (low) hourly rate. The success is not distributed to the workers, while in case of failure the member collectives need to rebudget meet.coop to pay the bounties. It brings a lot of calculation, which in the end is just transferring money from one side to the other and back.

  1. A money-based bounty system is hard to handle in terms of budgeting, speculation and accounting.

As already discussed above every circle needs to do accounting. The budget needs to be there and agreed in advance. There is even the problem of dynamic exchange rates as we all work in different national economies.

Collocall proposal:

  1. Take sales provision out of compensation framework discussion. Sales provision for member organizations etc. should be discussed independently and the Product circle is already responsible for sales.

  2. Tasks should be estimated in hours and not have a money bounty, as we see multiple problems here:

  • Changing exchange rates

  • Disconnection from actual success and available money

  • Value of a money bounty can be very differently depending on location

  • very similar to “cloud work” concepts

  1. We would like to add to the " Calculation of Compensations" part: " Members can decide if they want to get their benefit paid out or if they want to do solidarity transfers to other members/circles. Members can also apply for higher compensation."

  2. The fixed costs include services that are connected to server hosting. If (paid) services are provided by members the hours worked on them are not tracked within the meet.coop system. If inequalities appear at this point, they can be addressed as mentioned in point 3).

We’ve also thought about proposing the use of story points instead of time estimates/tracking, but didn’t want to make this discussion even more complex so we stayed with time estimates/tracking. (https://www.scrum.org/resources/blog/why-do-we-use-story-points-estimating) We’ve also discussed combined with this step to drop time tracking and do calculations on achieved story points alone.

Main Advantages of story points:

  • easier estimating of work, because everybody works on different speeds

  • w/o the use of time tracking there would be more incentive to improve processes

In further discussion we have to find a solution to different currencies and dynamic exchange rates. We need to have a compensation system with as little money exchange as possible and risk distribution of dynamic exchange rates.

1 Like