Guilds an analysis

From crowdresearch
Revision as of 18:35, 19 February 2016 by Tegenesantnioluzcarvalhodemoura (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Guilds: An analysis

Much has been discussed on the last couple of weeks around the several ways a crowdsourcing platform could govern itself. Despite our deep thoughts and fruitful discussions, there are still uncertainties on certain characteristics inherent to Guilds and how they fit our current purpose. This wiki submission tries to analyse from a black-box point of view: the one from someone who tries to maximize the quality of the experience for both workers and requesters while participating in our platform.

Features to keep in mind

First of all, it is necessary for us to quickly recap what are the features that we should optimize for both parts:


- The need to get well-specified tasks;
- The need to be fairly paid for those tasks;
- The need to not have work refused without a fair motivation by the requester;
- The need to make the most money out of an hour of work;


- The need to have tasks done in time and appropriately;
- The need to be able to trust workers handling their tasks;
- The need to easily set up tasks and get their results, regardless of their complexity;

For all those reasons we're going to delimitate how crowdsourcing systems could try to achieve the aforementioned objectives by structuring their communities around several mindsets, all of which varying in the parameters of 1 - rate of control on how the community develops itself by the sys admins and 2 - how likely are workers and/or requesters to form sub-communities within our main community. With that in mind, we have several possibilities:

- R1: The sysadmins do not provide any kind of community structure AND the workers are solely by themselves on the platform;
- R2: The sysadmins do not provide any kind of community structure AND the workers interact with each other by themselves outside our platform, since no official feature that allows that to happen is supported;

- D1: The system admins do provide some sort of community structure AND the workers do not interact with other workers while participating in those communities; - D2: The system admins do provide some sort of community structure AND the workers do interact with other workers while participating in those communities; From those possibilities, it is clear that R1 and R2 are not desirable. R1 represents what is already out there, such as MTurk, and is the very thing we're trying to innovate from. R2 involves communication and interactions that happen outside our platform that is out of our control notwithstanding all the problems inherited from R1. It is easy to deduce, therefore, that we're left with R1 and R2, and thats what we'll approach in the rest of this submission. Let's begin with R1. In R1, the admins do implement some sort of community structure (not yet specified) to the crowdsourcing platform , hoping that this new feature will increase their chances of enhancing people's experience with respect to the features in the "Features to keep in mind" section. However, they do not want or can't provide tools so that workers communicate with each other on the platform. What happens, of course, is that either the workers are not aware of the community structure working behind the scenes or that even though they're aware of how it works, they have no voice as a group, which means that even though belonging to a community they're most likely still vulnerable to abusive requesters and possibly sysadmins (they can't contact other workers, so the laws of probability state that there is a chance, even if slightly small, that they could be thrown out of the community arbitrarily). The conclusion is that even if this community structure could enhance the features needed, it would either be by a small amount or it wouldn't be solid enough so as to avoid harmful scenarios to happen. Our last hope is therefore, D2. In D2, as in D1, the software makers do embed a community structure into the software. However, this time they are able to ship a feature allowing workers to contact each other and form communities relying solely on their own wants and needs (be it joining automatically generated communities or starting their own/joining someone else's community). Because they are able to talk to each other and organize themselves as things happen, they will act like a complex system, in the sense that the workers will self-adjust to whatever demands are being thrown into the community by requesters. It is easy to see, then, that this approach is the one looking more promising!

However - What is this community we're talking about and which form does it take? Also, which form of community structure should software developers include in their softwares so as to enhance experience with respect to the features we've discussed before? To answer those questions, we must first understand the kinds of interaction that already happen in crowdsourcing communities and where we want to take them in the future. Currently, the state-of-art is based on workers working 1-to-1 with requesters, without the ability to form communities and to work on tasks that are not considered micro-tasks. Most, if not all of our problems can be rooted to those two factors. For example, because they can't form communities, they lay vulnerable to abusive requesters. Also, because only micro-tasks are being performed, requesters are not able to fulfill complex workflows that could make the best of crowdsourcing power. To unleash this power, we must envision what it is that we want crowdsourcing communities to be in the future.

The nature of the interaction

Nowadays, interaction connecting requesters and workers are solely 1-to-1, as mentioned before. It means that every worker, at any given moment, is going to be working on a task that has as its only point of interaction the result submitted to the requester and further interactions with him/her. This model is in complete fit for a platform focused uniquely on micro-tasks, that by definition are not complex operations and do not require multiple workers to interact with each other. However, if we envision a future where crowdsourcing is the driving force behind complex workflows, we need to go further from that. And thats where guilds come into play. It is common knowledge that complex work usually needs groups of people who differ, even if slightly, from one another when it comes to abilities. Even if they have a common ground in a certain area, for a complex project to be built, it is fundamental to have people with different personalities and skills in order to properly deliver the right results. Several kinds of organizations in the real world reflect that. Companies, for example, at some point of their history are going to be run by groups of people who have different skill sets and personalities even if they report to a leader (CEO). Cooperatives, while having most of the workers perform the same job (collecting useful objects from garbage, collecting and distributing milk), also have people who are better at actually performing the task in hand but also people who are more comfortable doing logistics, PR and so on. The online world is no different.

Suggesting guilds as a solution

So far, we've seen that having community organized into groups to perform all kinds of tasks is fundamental. So, in order to unlock the next level of work in crowdsourcing it is necessary that workers are able to fraction themselves into groups focused on accomplishing common goals, in which everyone contributes a little in order to to complete the task in hand. Our suggestion is that the community implemented by software programmers should rely on some fundamental aspects:

- to be democratically governed;
- to have clear thresholds of entry and leveling systems;