Minimum Viable Guilds (MVG) MarkWhiting

From crowdresearch
Jump to: navigation, search

A Guild is an association of people for mutual aid or the pursuit of a common goal (New Oxford American Dictionary)

We came to the notion of guilds because we think they might help us provide a better crowd work platform, but, we don't have great awareness of what those guilds will look like or how they will work. As a result, I think its useful to implement the simplest form of guild and develop it as we realize what is working and what is not. This will be a process that will take some time, but doing it carefully, and iteratively will mean that the final guild system is co-designed by the community and hopefully very robust. Additionally, we are going to learn a lot of things along the way, and many of those are likely material that could be used to write papers for various venues.

To implement guilds in Daemo a few basic interventions seem necessary:

  1. In-situ Communication such as onsite chat from individual to individual and with larger groups if possible.
  2. Guild Profiles that can include basic information such as the name and manifesto of the guild.

In other words, when we provide onsite chat, as well as a way for a group of people to call them selves a group with a specific manifesto, then guilds can emerge. These are very flexible but simple guilds. They don't have any built-in features, they just let people rally around specific ideas. The main advantage of having such a simple guild system is that very few assumptions are made about what guilds should do and who they serve. In this way, guilds act a bit like a minimal unit of representation or governance in the community. They could be used to demand better pay for workers who have completed 10K image recognition tasks, while at the same time, others might use them to push Daemo to develop better survey tools. There guilds let community members leverage others they have similar interests to in order to optimize their interests specifically or generally.

This approach forces guilds to make a lot of decisions on their own, for example, how they internally manage themselves, how they gain members and how they interact with other entities in the system (such as requesters). There are some disadvantages to this, so to instigate labor guilds, worker specific guilds that afford worker specialization and internal quality assurance, we need a few more features and these can be added as extensions to the initial model. For instance, we would need things like the following:

  1. Guild specific task lists or guild specific filters for task lists so that a worker could see the work that is available to them that is coming through their guild
  2. Member ratings from within the guild context, these would be independent from the ratings workers get from other activities on Daemo and would not be public to people outside the guild. We need these so that guilds can manage leveling, provide good quality reliability etc.
  3. Guild ratings, which would reflect the total reliability of a guild, we need this so that guilds can justify their value to requesters
  4. Guild requesting in which a requestor could target a specific guild with a new task or set of tasks directly

With these features a context begins to emerge in which workers can join guilds that demand slightly higher pay per task, on the basis that the guild guarantees a certain level of quality to requestors.

How can payment work?

How can quality control work?

A day in the Life of a Guild Worker

Is there a paper here?

The first paper could be about MVGs as a mechanism and this approach to their development as a way of implementing open governance without starting with a complex system of features. I propose that after about 2 months of live use on the site, we will be able to write about many behaviors that we have observed in guilds and ways in which we think they have influenced the platform so far. At that point, we might also consider listing some preliminary revisions for a future iteration.

With these steps I think we can begin to answer the following questions:

  • How do actors in our system use guilds?
    • What utility are they getting from guilds?
    • What ways are they misusing guilds?
  • How could we make guilds work better?

Some notes on implementation

Initially we might choose to make these guilds a beta feature such that when users sign up to use them we ask for permission to observe their use on some level. For example, we might ask to have a access to their guild chat log so we can get an idea of how things are going.


References

  1. New Oxford American Dictionary, 2013 by Oxford University Press