Skip to content

Home

Jump to bottom
Patrick Altman edited this page Apr 15, 2017 · 3 revisions

Let's keep initially focused on the LXX analysis task described in http://jktauber.com/2017/04/10/update-lxx-progress/ but with the framework set up to eventually allow for other tasks.

Projects, Tasks, and Items

Projects span multiple tasks and involve a particular group of people. So a user is a member of a project and a task comes under a project. Initially, only site admins should be able to create projects.

We could implement projects with pinax-teams so they can be set up as open, invitation-only, by-application, etc.

I don't currently see any reason for projects to be hidden so we could easily list all projects as well as a list of projects that the current user is a member of.

Tasks are a set up of a particular action to be performed by project members on a set of data. Each datum / question is called an Item. So what's described in the blog post above is a single task consisting of 586 items. Tasks will eventually come in different types but we can start with just one type for this.

It will consist of the question and the two choices the user has to choose between (typewar / that-or-that style).

Core Stories

  • site admin can create a project (but see Q below)
  • site admin can config a project (but see Q below)
  • anyone can see a list of all projects
  • auth'd user can join a project (subject to how project team is set up and this introduces the notion of project managers which aren't otherwise discussed in this list)
  • auth'd user can see a list of projects they are a member of
  • anyone can navigate to a project detail page
  • anyone can, on project detail page, see list of tasks
  • anyone can navigate to a task detail page
  • project member can undertake a task, which takes them through a sequence of items

Q: not clear yet how new tasks should be set up? Is there Web UI for it or do we just do it via configuration / code / settings, etc. Given we're doing that to start with, should that apply to Projects too an eliminate some of the stories above (at least in terms of the frontend UI)

Basic Stats and Gamification

  • anyone can, on task detail page, see stats on how many people have participated, how many distinct items, how many total item response instances there have been
  • anyone can, on task detail page, see leaderboard of who has contributed the most

Eventually we can have project-level leaderboards, streaks, badges, referral bonuses, profile pages but they can all be punted for initial release for LXX parsing task (although some might be added in first couple of weeks)

Results

  • site admins can see a task results page which lists the items in a table with stats about how many responses have been given and which answer is winning
  • site admins can see an item results page which shows exactly who said which choice and when
  • site admins can see a user page which shows exactly what that person said for which item and when

Models

So I think the models are:

  • Project (how exactly this related to pinax Team we need to discuss)
  • Task (name, description, PK to Project, something indicating 'type' even though we have only one type initially)
  • Item (will depend on task type, so might just have a FK to task and a JSON field)
  • ItemResponse (user, timestamp, FK to item, answer given)

plus any denorm models we might want like an ItemResult that aggregates item response counts.

Views

  • homepage (can redirect to dashboard on auth)
  • dashboard (listing projects, etc)
  • project detail page
  • task detail page (title, description, stats, leaderboard, ability to undertake task)
  • item asking
  • task results [site admin only]
  • item results [site admin only]
  • user results [site admin only]

Some Additional Thoughts on the Item Asking

Do we want to support repetition of items? How do we handle someone wanting to go back and fix mistakes?

I'm thinking each "showing" could also show the previous answer given with the ability to go back and correct it. Remember this isn't "learning" so nothing wrong with going back and changing answers.

We might want to make the item asking actually have the item pk in the URL so you can actually link to a previous item asking. Therefore the randomization would be what URL we redirect to initially and on post.

Clone this wiki locally