DesignDraft

This is the early design document for the Play Perl project. It's a translation from my Russian blog post, sorry if it's obscure, some points could possibly be lost in translation.

tl;dr: this is a gamified todo-list / social network for perl developers.

Targets

What's it for?

1. To help people to participate in opensource development by increasing the amount of fun they're having.

2. More publicity, more intercommunication. To help people to make their plans more public. To increase the amount of the feedback they're giving and recieving.

3. More management. Wait, that sounds wrong. More structure and better prioritization.

Maybe scrum did fry my brains, but I really think that opensource is missing, I don't know, consistency? formality? management? no, this is all wrong. Tools and process organization, which would let people do what they need to do, don't do what they shouldn't do (because nobody cares), and the give them the ability to detail and visualize their tasks on all scales. (How many times have you spent the whole weekend on the bug which probably never affected anyone ever? Do you think this is optimal? It's easy to lose the vision of the big picture while you're down in the trench, unfortunately, that's how our brains work. And I'm probably the biggest procrastinator of them all.)

About fun

As you can see in this picture, there are 4 kinds of fun: easy fun, hard fun, serious fun and people fun.

How does this model relates to opensource?

Serious fun is there already, usually. We're not going to increase it by gamification or social networking.

I don't think we want to increase the amount of hard fun :)

So, easy fun and people fun are left.

About easy fun: many projects have tons of simple open tasks: documentation, bugs that are easy to fix, simple features which nobody implemented yet. Projects that are big enough often keep a list of them and offering them to newbies on hackathones or Google Code-ins. Newbies probably won't stay for long in one place if they just want to try something new and don't actually care about the project (don't use it themselves), but still, easy fun a cool way to recruit new people to the community.

What can we do about it: help the developers to gather these tasks in one place (but I don't want to implement the full-blown bugtracker!), separate easy tasks from the more complicated ones (see below for "quest types"), make it as easy as possible for the newbie to find a mentor (see below for "pair quests").

Now, about the people fun.

First, people fun is about feedback. Second, it's about social networking.

Feedback is:

• likes of what you did as an instant encouragement
• likes of what you're planning to do as an expression of the interest to your plans (I suspect this will be a strong motivator as well)
• likes of what you're planning to do as a way to rank your tasks by their importance
• finally, there are always plain text comments

Social networking, if we're going to follow the target "encourage people to participate more", should be built around the actual tasks. But I'll get back to it a bit later.

About games.

Gamification Coursera course separates the "play" and "game" notions. Play is something without rules, pure fun; game is a closed system with specific rules. So, this section is separate from "About fun".

Why do we need "game" at all? Because it gives the pure formalized feedback and allows the user to replace the complex entangled task with obscure goal with a target with a more specific goal ("get moar points"), even if the latter one is less precise. This is important for fighting procrastination and actually doing stuff, at least that's how I understand it.

So, what can we do about games?

From the standard PBL model (points, badges, leaderboard):

• we can use points;
• we really should use badges (everyone loves achievements! they can be of different types and motivate in many various ways, for example, "do one task each day for a month");
• I don't think we need leaderboards (Gamification course says that it demotivates those who're located in the bottom half of the list; anyway, it's not worth it by now).

I've got one important argument about why we need the points.

The measurement of the completed task can be calculated based on the number of likes. Or maybe even based on the karma of whose who liked the task (so, this becomes similar to pagerank). This will motivate people not just do "something", but to do something that many people want to be done.

And now we're back to "management" talk :) One of the most important (and simple) ideas in Scrum is the backlog.

You can't rank your tasks without context. Tasks have a priority only relatively to the other tasks. So, to figure out if you should do the task, you should first put it into the general list with all your tasks. Otherwise, you're probably too focused on the local problem and are optimizing too locally.

But, I repeat, we don't want to build the bugtracker. How can we prevent the service from becoming a graveyard of tasks which will never get done? This is an important question. (I have some half-baked ideas, and I believe this is solvable. We could put a fine to gathered points for too many open tasks... or for the task which didn't got done... or, a bit less cruel, don't allow to have more than N open tasks at all! Anyway, we need to encourage the uncluttering.)

## Tasks can be of different types.

...Oops, I forgot to explain my vision of how the project will look, sorry :)

The main concept is: "you can take and complete the quests of various types". The quests can be very different, from "fix a typo in the documentation" to "release the new major Perl release".

Why do we need the types of quests?

• the quest of particular type is easier to complete than the abstract task "do something"; structure is important;
• quests of different, preset types are necessary for implementing achievements;
• different quest types is a choice; it's a hint for the player regarding what he can do today. Gamification course professor repeated a lot that having a meaningful choice in game is important. (Gamification is not the final goal, of course, but he has a point.)

On the other hand, we can't pre-declare a separate quest type for the each possible task. This means that a quest must have the description.

BTW, I don't think that we need to check whether the player actually completed the quest. Even for the "newbie quests" such as "try to install perlbrew", I don't think many people will lie that they did it when they actually didn't. (And yes, newbie learning-oriented quests are definitely a possibility and one example of the "quest type").

## Group quests. You know, WoW, guilds, raids... :)

I strongly believe that the main benefit of the pair programming is not that people check each other's code, and do less mistakes because of it, but that it's harder to procrastinate in group. Pair programming forces the person to discuss and solve the problem and don't put it aside for a while.

I've got tons of tasks which I could do in 15-20 minutes, if I tried. If there were someone who were interested in the result, or if he or she wanted to do something and asked for my help.

But I'm a bit sociophobic. And I suspect there are many sociophobic people among geeks, which don't feel comfortable to ask people for help.

So.

What if there were a place where you could explicitly declare "I'm ready to do this task as soon as someone will be ready to help"? Or, alternatively, "I'm ready to mentor anyone on this task".

And then they'd contact each other somewhere on IRC or on the website comments section or on github, do the task, close the quest and receive the "team work" badge.

This is the idea that I like most of all in this project, actually. (I actually wonder why nobody did it yet, maybe not in the opensource, in some startup... or probably someone did, but I didn't heard about it.)

This project is not...

This project is not a social network.

This project is not a bugtracker.

Ok, that's a lie. It is a social network and it is a bugtracker, but only as much as it's necessary for achieving its real goals.