TEAM

* Devanshu Mehta:

* Mike Subelksy: mike [at] subelsky [dot] com

* Cory Forsyth: cory.forsyth [at] gmail -- I know Rails and am happy to help out wherever. also wondering if, depending on the volume of items needing to be reviewed, whether using mechanical turk would be helpful.

* Billy Gray: wgray [at] zetetic.net

Feature Requests by Priority

1. Ability to add EPxx tag

2. Ability to listen to telephone inputs

3. auto-review of useable tweets

4. stats page: X reports pending, Y total reports reviewed, Z reports auto-reviewed, etc.

5. fix timestamp on alerts

Needs

Add "star" function

Latest Spec

Sweepers will log in
Tweets will be assigned to sweepers
- sweeper clicks "review some tweets"
- gets 10 tweets to review
- those tweets are released back into the pool after 10 minutes if they are not reviewed
Sweepers can perform the following actions to tweets
- Edit location
- Add a star if the they think the tweet needs particular attention

What's Needed Here:

A more complete spec
Build it!

If you think you can help, or even take the lead on this, email the team members below to see what's happening so far.

Some ideas:

We expect to have 20-30 authorized "sweepers" who will be reviewing each report,

1) for validity

2) for any fields that can be gleaned by a human but were not picked up on by the app

3) attempting to tie to polling place or other metadata where possible

Some implementation details:

1) We will have an action for the reports controller that a sweeper can visit to see reports in need of review. This will probably live at /reports/unreviewed, or something similar. This will list all reports in need of review (paginated), with probably two options for each one: a simple "reviewed" checkbox, and a link to "edit" the report -- which is where the sweeper can fix any incomplete data.

2) Each report can be in one of several states: "unreviewed" and "reviewed" are the two that make sense right now. If we require a report to be validated by multiple sweepers then there may be more than one state: "reviewed_once", "reviewed_twice", etc. That's just speculative right now.

I think the acts-as-state-machine plugin may be appropriate.

3) We'll need to add a db migration to add the appropriate fields to the report model.

Data Cleanup Interface Spec

- If we want really good data, we'll need sweepers who can watch incoming tweets and 'encode' them. The sweepers will be able to look at tweet, and then edit the content of each database field that will be associated with that tweet.

All tweets will need to be tagged with the following status info

- not reviewed

- sent question to tweeter, awaiting response

- reviewed

Once a tweet has been reviewed, the data in the database will be updated accordingly. There will be a field containing the original tweet, but the apps will all use the updated data.

If we are distributing this task out to many volunteers, we'll want to have edits confirmed by multiple sweepers.

Info: