Rijul Magu Reputation System Idea (Modified)
In my previous idea above, I've pointed out the reasons why in my opinion, using a private rating system wherein workers and requesters rate each other secretly, not revealing their ratings to each other (furthermore, reputation scores are internal- not viewable by the community members) mitigates some of the side effects of traditional star systems (also discussed by Randy Farmer: ).
In addition, I've suggested the use of 'reputation scores' and how they can be calculated.
I now attempt to modify the basic model incorporating the ideas discussed during the second reputation system brainstorming session of week 11, summer (most important of which is the 'Cascading Task Release' proposed by Professor Michael Bernstein- Reputation and ranking).
Modifications and Other Notes
1. All workers and requesters begin with an initial rating of 2.5 stars.
2. For a given worker/requester a list of available tasks/available workers is shown in a specific order:
A) Reputation scores decrease as one moves down the list. Note that the highest possible reputation score matchable to a given worker/requester would be equal (at maximum) to the score of the latter (see diagram below). This is done to prevent bad workers/requesters from getting access to good workers/requesters. The reputation score is not fixed and changes not only from task to task but also with time- depending upon skill and feedback.
B) For a particular reputation score, tasks/available workers would be ordered by average number of stars given from previous assignments. For example, if worker 'A' has previously worked with requester 'X1' (having given him an average of 5 stars out of 5) and requester 'X2' (4.5 stars), then X1 would be positioned above X2 (assuming both want new tasks to be completed). Those requesters who have not worked with worker A before, would be placed right below requesters with 2.5 stars.
3. Tasks would be visible to workers belonging to a lower range of reputation scores at a later time than ones belonging to a higher range of scores (Cascading Task Release). Similarly, from a requester perspective, available workers would be shown at different times. This would give community members an incentive to improve (so that they can get quicker access to tasks/workers).