Your project settings

The way you grant permissions to contributors as they gain Contribution Points (C.Pts) will greatly affect the way you run your project and how others interact with each other. In other words, there are governance implications to your choice of settings. With all the settings below you’ll find that as your project progresses, a natural equilibrium will be formed. It’s a bit hit and miss, but you’ll get there in the end.

Limiting how many tasks can be accepted

There are two options available to you for limiting tasks, and they are:

Contribution scaled

A changing limit that increases (and decreases) with C.Pts earned. When every multiple of the C.Pts set is earned, a user will be granted further capacity to accept an additional task. An example would be: the scale is set at 10CP. At every multiple of 10 C.Pts, a user will be able to undertake an additional task. So, someone with 3 C.Pts can accept 1 task; 10CP = 2 tasks; 13CP = 2 tasks; 78CP = 8 tasks and so on and so forth.

Fixed limit

A straight forward hard cap on the number of tasks a user may under take.

Governance

Limiting the number of uncompleted tasks a user can have at any one time is an important element to managing your project. If you have dozens of members in your team it can become something of a free for all, and reeling it all in can be difficult if people aren’t particularly responsive in chat or are just outright not discussing anything they’re doing. It’s in situations like these that you might be better off setting a low limit on the number of tasks that can be accepted by yourself and your contributors. If the poop is hitting the fan big time, you could go all out and set a fixed limit of 1 task. However, in doing so, you have to accept that not only may your contributors feel stifled, but productivity will certainly decrease as people often switch between tasks. That said, if you’re still in big, chaotic teams but you want to offer more experienced contributors more freedom, maybe you might consider setting a scaled limit. The higher you set this the less tasks people can under take, so you could set it to the maximum of (currently) 25 C.Pts and limit all but the largest contributors. Again, this could have productivity issues and people may feel discouraged as their potential for building C.Pts is greatly reduced, however, there’s always the prospect of hitting the next threshold level to spur people on.

That’s all good and well but what about the reverse scenario of this? If you’re in a small, very close knit team (~10-15), where everyone is communicating well and there isn’t a mob of people randomly accepting tasks, then you can allow more tasks to be accepted by individuals. This means multi-tasking can take place and there’ll be an increased rate of contribution gain (and work being completed) keeping everyone happy. If you are planning on letting in further contributors down the line, then again, in this case, opt for a scaled limit to give you a chance to evaluate the skill of newcomers before they accept a whole load of tasks.

When contributors can create tasks

This is simply the threshold level of C.Pts at which contributors may start adding tasks themselves. This follows a very similar logic to limiting tasks, in that, in large teams you’ll want to gravitate towards a higher threshold, and in small teams, a lower threshold.

The level at which you set this threshold has implications on project management. With additional people able to create tasks the autonomous nature of Crowdsourcer.io projects can give your team that needed boost and greatly increase productivity. No longer does work need to stop whenever you’re offline… But you only want high quality tasks and equally you don’t want people abusing the system, so set the threshold accordingly depending on the dynamics of your project. A general rule of thumb is higher level of communication from contributors + fewer contributors = lower threshold. You’ll want to set this to work in accordance with your other settings, especially with voting rights as below.

When contributors can review tasks

This is the C.Pts level at which contributors may vote on tasks. This means upvoting and downvoting tasks which could push them into or out of review. Obviously this could have a big impact on the way your project comes together. Generally speaking, in newer projects you’re going to want to set this threshold at higher level than the threshold at which contributors can create tasks. The reasoning behind this is that you want a buffer period in which you (and other proven contributors) can review the new tasks that another contributor is making, before that contributor can influence the outcome of the review. This prevents individuals from creating low quality tasks that aren’t positively adding to the project.

Sometimes though, there can be situations where you allow contributors to vote before they can add tasks, and if that’s case, go you, you’ve got a project built on true, unadulterated Crowdsourcer.io principles where everyone is contributing and collaborating with the correct attitudes and mindset. In these situations more people have voting power, likely because there’s a great level of trust within the team, and thus everyone is holding everyone to account - creating a more level hierarchy in the project. Often this occurs later down the line, but it can happen quickly in smaller teams.