WinterMilestone 3 Team1 EU ReputationIdea: Gamified Narrative
DARKHORSE: Gamified Narrative:
Base Narrative: think about the requesters and the workers as two big brothers, or two sides of an island, or two parts needing one each other and setup group dynamics that may trigger internal group monitoring (workers control other workers and requesters control other requesters) If jobs have no intrinsic motivation (they are made only for money), a narrative to link the job quality to a story (WoW) will improve job quality, W/R relation and overall power distribution. It is like a "story" or a game.
Any Category or "Guild" (coders, lawyers, etc..) can choose its variations to the reputation system like in sets (like in Venn diagram sets where the bigger has some properties in common and the internal ones have vatiations).
Bringing a bit of game design you could design a reputation system where you have both levels and perhaps classes. In terms of levelling, this can be determined after your first couple of tries (perhaps 10-20 range) to rule out for your inexperienced ways around the platform and tasks and whatnot. Based on that generated level (let’s say 52), you could go either up or down, based on an algorithm that takes into account automatised rating (probably time) and the one you get from requesters/workers. This rating could be used to place you within categories from which workers/requesters can choose from while filtering for jobs or adding tasks and could work towards offering different rates based on the skill required, matching workers with requesters’ needs (saving them either time or budget). In terms of classes, when working on your profile (again, either w/r), you could opt in (in exchange for some benefits) into a class that’s either going to help mediate the resolution process between workers and requesters, or help requesters design their tasks better, or the flip coin to help workers (that have been previously reported as failing on certain tasks) with whatever they may need (considering it’s not IQ and within their similar range of interests).
Workers' and requesters' reputation linked directly to each class or area rather than an aggregate for all the tasks incorporating various skills all bundled into one. A worker may produce fantastic results on logo work but so so results on python coding, for example. In order to ensure an appropriate identification of skill type and level when onboarding new workers, they will self-certify their level for each class for which they want to accept work. A microtask for testing will be given to the users to complete for free if they choose self-certification.
Feedback and The Mighty Purgatory
To make freeriders not to freeride and at the same time to allow people not to being “killed”, we should lower the consequences of being rejected with a negative debt in trust. The rejected workers have a trust restoration process. They have to complete n (let’s say 5) tasks in order to be back in the system. For free. It is like a small penalty and at the same time a way to re-build trust and quality. They do the job in parallel to other workers, so they do not “block” the HIT, they just make it even if it has been done already.
Reputation will be assessed with both automatic algorithms and with peer reviews (see Character's stats).
If there’s some issue, both of them can communicate with each other through the platform (if there’s a problem, “trade union” is reached out)
The respect/disrespect of one of the aspect of rating (both for requesters and workers) will automatically influence the reputation, it will either increase or decrease (if there’s no force-majeure or another human factor. in this case, trade union is also reached)
Every newcomer has initial rating that will vary, depending on the conditions listed above.
If the reputation of worker/requester will be below zero, he will be in a sort of “black list”, in order to get out of this list, he would need follow the instruction metioned in the contract. (do some work for free? or smth else)
As reputation plays a very important role in the system, it will influence directly the following aspects:
pricemaking: workers with better reputation will earn more money as they are, by default, more experienced/skilled/etc. Consequence-> better quality for requesters
the supply/demand: A requester with a better reputation will be more likely to work with workers with better reputation.
The Mighty Purgatory
If you were to bring transaction audits at every task-completion screen, both requesters and workers could easily rate as well as help by suggesting improvements. This can be done through a Likert scale from -2 to +2 (e.g gruesomely dissatisfied -2 whereas for +2 extremely pleased). This way the system is easily notified and you will have a fast acting agent of “bad behaviours” (e.g 5 users gruesomely dissatisfied would make an accumulated user rating of -10 and that will also trigger the system). Once your reach a limit of reports, you congratulate the user if he got 10 points or place them in The Purgatory. For requesters, if they are put on probation because of their poor quality tasks or badly defined terms in which the work should be carried out or delivered, their probation would need to take them to the sandbox where they need to document themselves on “posting guidelines”. Next, they post 10 types of HITs, twice (or something that takes 10 minutes of their time as they are there to work and more importantly, give work), which will be verified by the LB (or see reputation idea for classes-mediators) and if the tasks were good, automatically post them. Afterwards, they get assessed in a similar fashion to workers to make sure the desired behaviour has been consolidated (see below). For workers on probation, the user in question will be assessed (for 10-20 tasks) on a different rating system alongside the original one at the end of every task. This needs to be designed to focus on the bad behaviour, having asking requesters to rate wether or not he has made improvements on whatever it was he got wrong in the past.
Variation: the workers in The Purgatory should make free jobs and requesters should pay a random % more in their job posting.
Character Stats in the Game: Semi-automatic reputation system with KPIs
In order to have Character stats, in other words your performance skills, the reputation is based on key performance indicators (KPIs) which determine e.g. rejection rates, duration per task etc. Every Class Experts (people with 10 points, see the Purgatory). Daemo (-or the game) should autoevaluate also other KPI out of standard data, for example:
Give all Ws 10 points (grading 0-10 where 10 is highest positive rating) who have: Rejection Rate < 10% Task Duration < 10 Minute Error Rate < 5% etc. Give all Ws 9 points who have Rejection Rate >10% < 15% Task Duration > 1 Minute > 3 Minute Error Rate > 5% < 10% etc. Give all Ws XYZ points who have Rejection Rate >x < y Task Duration > x Minute > y Minute Error Rate > x < y etc.
High-reputed workers could evaluate other workers contested work and receive reputation and money from the system. The evaluation should be anonymous.
Variation: workers can self-evaluate their work and their self-evaluation could be confirmed by requesters or by peers.
The Cult and the Magic Attraction
Darkhorse: Each user will express his needs as invocations, and the needs will be recorded for match-making (see "The Magic Attraction")
According to KPIs and other Character Stats the system will automatically match the best user for each other needs (worker-requester).
Before the task is posted on the platform, requester chooses the set of skills he needs, but an algorithm will also magically figure it out by itself while analyzing tasks, and the task will be sent firstly to the people who match the skills’ set needed and according to the "invocations". Examples:
The best reputed requester will see the best reputed workers firstly
If requester and worker already have an experience of working together and both parties are satisfied, they will see each other listed first.
- If R and W have a dispute e.g. R rejects work of W because of quality THEN
R can choose a lower payment, if the R doesn't or if R's proposal is rejected THEN
4 Experts (Experts = the best 10% of a "Guild" or "Category" = "A type of job, expertise") from both Rs and Ws will look into the results of the work and decide about rejection:
The R is evaluated and gets Worker's index and Requester's index. The W is evaluated and gets Worker's index and Requester's index.
Then, if the worker gets 1 - 1 he gets paid, 0 - 1 gets a 15% cancellation fee, 0 - 0 his work is rejected. For the requester, he gets 2, 0 or -1 reputation points according to the case.
Question: WHY SHOULD THEY EVALUATE? Workers get paid by reputation or by daemo itself. Requesters gain more reputation.
Users Involved: @kamilamananova, @arichmondfuller, @purynova, @seko, @vlado, @ahmednasser, @amdp