[WARNING: we start this conversation on the dev type of contributors as for now we only have money to pay for the dev roles on the global product team, but the conversation will need to be held for all contributors of the global product team.]
During the Melbourne 2017 gathering, we have deeply reviewed the way we work as a global team around our common platform. One of the outcome of this gathering is our common will to switch from local dev teams/pipeline to a single roadmap/pipeline and as a consequence, a single dev team.
Here is a first proposal from my understanding of what we came up with, as a start to reach an agreed upon process.
1- The integration process
a- New contributors
When a new dev is interested by the project, the first step, before they can be paid for his contribution, is to start contributing on a volunteer basis. The purpose of this is:
- to enable the dev to understand from inside what it is to work on OFN and see if that’s what they wants
- to enable them to get to a point where they can start to create real value for the project (which would justify being paid)
- to enable the rest of the dev team to gauge if skills fit to what the project need, in term both of technical (coding abilities) and social (communication abilities) skills.
So any new dev need to start picking some issues and committing some first PRs.
b- Certified regular contributors
After that, a developer who wants to be paid in order to be able to really invest time on the project can request to be certified. When they are, they will be able to invoice contributions.
To be certified, the dev must meet three conditions:
- Have the tech skills required in order to make sure that they deliver real value for the time paid for. The other devs can gauge that based on the first contributions of the dev. If they think some important tech skills are missing, they can orient the dev to some issues where they will be able to learn the missing crucial skills.
- Have the communication skills required in order to make sure no paid time in inefficiencies due to lack of communication, and ensure a global consistency of the team and processes. That means he has to be part of the Slack conversations in the #dev channel, reply to questions on GH, give feedbacks and review to contributors, ask questions as soon as something is not clear to get a consent with other devs on how to solve an issue, participate to speccing sessions, etc.
- Dedicate at least one full day per week on the project, in order to make sure that the certified devs are commited and engaged, and that if they take an issue they are going to deliver quickly and don’t block the processes. It doesn’t have to be every week the same day, and can be like 2 half days.
c- Certified occasional contributors
For now, the project really needs committed and engaged developers, but on some issues occasional contributions can also help to make things move faster. So in case this is needed, devs who have both the tech and communication skills but can’t commit to a regular contribution basis can request to be certified as occasinal contributors and be paid for their contributions. In that case, they will be offered by the global product team to take some specific issues and will be paid for those contributions. Any other contribution they make on their own initiative will be considered as volunteer contributions.
2- The rates for certified contributors
The philosophy behind the redistribution process is that the value generated by the project should be distributed fairly to those who contributed to create the value. Inspired by the contributive/value accounting, our aim is to set up a retribution system that is not “equal” but “fair” and take into account:
- the difference of value created by an OFN junior or senior dev in one hour. For that we are inspired by the Japanese “ShuHaRi” experience level system. “Shu” is a beginner, “Ha” intermediate and “Ri” master. Those are level in mastering an art. It seems fair that a “Shu” is not paid as much as a “Ri” as with the same time spent, the “Ri” will create more value for the project than a “Shu”.
the cost of living of contributors. It is not fair that a dev who live in a very expensive city is paid the same as a dev working in a small countryside where rents are much cheaper for instance. Or devs in India and Australia.
I suggest on that point to use the cost of living index. This is given by country, but it is also possible to compare between cities.
I suggest we stick to three cost of living categories to start with and iterate on the first cases.
A first discussion were held on the topic here
I updates the rates table with a Shuhari tab and a first propoal as a base for discussion. We will need people from those different catergories to see if that seems fair. Here is what it could look like:
Questions to be discussed:
- as there is no local dev team anymore, the dev should invoice directly whoever has the money and is paying. Or can a local instance invoice for some dev work by a local team? I would find that contradictory, no? For instance until now when Matt has worked for OFFrance issues OFN UK were invoicing OFFrance so adding up some instance fee on top of Matt’s rate. But now there is not anymore OFFrance paying for some specific work, but a global pipeline, I think there should be no fee added by any instance on those rates.
- Should we talk of a day or hour rate? Hour seems fairer to me and avoid to play with legal day work in each country, like if it’s 6h in Scandinavia and 9 hour in India, it doesn’t seem fair that they are paid the same for a day of work.
- How do we deal with conversation rates fluctuations? Do we have one reference money that we base our rate on? Or do we “lock” the rates in the different currencies used and try as much as possible to pay in the same currency zone? I woud vote for that actually.
Ping @Kirsten @serenity @lin_d_hop @nick @tschumilas @enricostn @sauloperez @Rachel @oeoeaio @maikel @danielle
@sreeharsha it would be great to have your feedback on fair rates in a country like India, I googled it but have no insights on it.