-
Notifications
You must be signed in to change notification settings - Fork 26
Feature details
Different quest types have the following advantages:
- they give a user a sense of a specialization choice (we'll grant quest-type-specific achievements based on that)
- they'll act as a quick filter in a service-wide quest list (color-based coding is a good idea, I think)
- they are the first step in a task concretization; concretization is important for fighting procrastination :)
Possible quest types:
- bug
- blog
- feature
- documentation
- donate
Learning quests are repeatable: anyone can do one of these once.
Which one of these is the "type"?
- Category: code - building stuff; marketing - spreading the word; sponsoring - giving money
- Project: Moose; Dancer; perl.org (or is it "product"?)
- Action: bugfix, new feature, blog post
I'll go with "action" classification by now, but this question needs more consideration.
We also need to think carefully about the optimal number of quest types. We'll always have "untyped" quests, so by analyzing them we'll find out which types are missing. On the other hand, too many types will be confusing and distracting. Maybe we need to figure out some other benefits of types, besides achievements...
See also:
- https://github.com/berekuk/play-perl/wiki/DesignDraft#wiki-task-types
- https://github.com/berekuk/play-perl/issues/25
The basic scenario is (duh):
- create the new quest
- (do the work)
- close the quest, get points
There will always be people who don't do stuff, but just watch other people working. We can make use of them:
- let them like other people's quests (providing feedback, motivation and prioritization - #21, #22, #34)
- let them comment on other people's quests (feedback)
- they will spread the word about the service (#53, #54)
What about the people who do stuff publically on other websites (github, rt.cpan.org)? We could implement one-click "create and close the quest" for them, so that they could:
- claim the job and get points/achievements
- collect the work they did in their profile
- spread the information (after we implement #49)
Alternatively, we could import all their github and rt.cpan.org tasks automatically. But if we're going to do it, it should be done carefully, probably with the ability to separate imported and original tasks in news feed and other places. (To avoid the "graveyard" effect - 99% of events will be robot-generated, and the whole website will look like a ghost town.)