This week pick one of these four foundations and prototype it. Rapid prototyping as before: it can be a paper prototype, a quick code hack (front-end only), or a video. People interested in contributing to infrastructure should check the #infra slack channel, and Infrastructure wiki page.
- 1 Foundation 1: Macro+micro
- 2 Foundation 2: Input/output transducers
- 3 Foundation 3: External quality ratings
- 4 Foundation 4: Open Governance
- 5 Let's name our system!
- 6 Deliverable
- 7 Help regarding Web Technologies
- 8 Submitting
- 9 Weekly Survey
Foundation 1: Macro+micro
How does it work? Is it negotiation, oDesk style? Or job boards anyone can check, like Mechanical Turk? How do we address quality and make sure that people don't just grab a task, work for ten hours, and then submit low quality work? How do we unify macro with microtasking?
A unified model! All tasks can be taken up without negotiation by anyone who qualifies, and worked on immediately. For all task submissions on our marketplace, we require at least one milestone. That milestone serves as a checkpoint: if it's a microtask, it can be after 5% of tasks are complete; if it's a macrotask, it might be a description of what they should do first (e.g., "Submit an architecture diagram of the code you will write"). The requester can set the number of max workers who they will pay to do each task in the milestone. The results of that milestone can be used to select specific workers to qualify to work on the rest of the task, or just to launch the rest of the tasks with no qualification. The requester can add as many milestones along the way as they want; we suggest one every couple days.
Foundation 2: Input/output transducers
Who pays for it? How does it work?
Michael doesn't buy the algorithmic transformations here yet; they'd be too noisy.
Suggestions for input transducer
Suggestions for output transducer
By default, the platform checks a box that sends all work for review to a worker who is one (or two) levels more advanced than the worker before publishing it back to the requester. It is done by publishing a new task back to the marketplace with the right qualifications. This default adds cost and time, but addresses quality control. To address speed, we can provide feedback (as simple as something like a progress bar may be) to the user that it's making progress, even before it gets reviewed, so it's not super slow...
Foundation 3: External quality ratings
Is it algorithmic or human? Who exactly rates who on what dimensions?
Michael's note is that we can't base it entirely on accept/rejects or 1-5 stars, since there's a major positive bias in these scores on oDesk and AMT. Interesting suggestion was to make it like AirBnB, where feedback cannot be later linked to a single job.
Foundation 4: Open Governance
How exactly will this work?
Most people seemed to be suggesting that we elect representatives, with the ability to put things to an everybody-ballot when necessary.
Let's name our system!
This is your opportunity to suggest names for our system. What do we call the system we're working so hard for? Be creative! :-) You can vote here to post an idea or upvote existing one's.
If you've worked on the lo-fi prototype, then create a wiki for your submission. However, if you've worked on the front-end prototype of a foundation chosen then host it on Github pages, and add a link so we can visit your site and play with it.
Quick tip for people working on front-end: Populate it with some mock data (fake data you invented, but which looks realistic) so that we can see what it would look like if it were actually used. Ie, if it's a job market, there should be some fake job postings. If it's an interface for moderation, there should be some fake task to review, fake comments, etc.
Help regarding Web Technologies
Codecademy (covers the basics)
- http://www.codecademy.com/tracks/web (HTML and CSS)
- http://www.codecademy.com/tracks/jquery (jQuery)
Codeschool (covers additional advanced topics)
- https://www.codeschool.com/paths/html-css (HTML and CSS)
Create Wiki Pages for your Team's Submission
Please create a wiki page for your team's submission at http://crowdresearch.stanford.edu/w/index.php?title=Milestone_9_YourTeamName&action=edit (substituting in YourTeamName with the team name). Copy over the template at Milestone 9 Template .
We have a service on which you can post prototypes, comment on them, and upvote ones you like.
Post links to your prototypes only once they're finished. Give your posts the same title as your submission. Do not include words like "Milestone", "Prototype", or your team name in the title.
-Please submit your finished prototypes by 11:59 pm 29th April 2015, and DO NOT vote/comment until 30rd April 12:05 am
[Everyone] Peer-evaluation (upvote ones you like, comment on them) from 12:05 am 30th April until 9 am 1st May
Step 1: Please use http://crowdresearch.meteor.com/needcomments to find submissions that haven't yet gotten feedback, and http://crowdresearch.meteor.com/needclicks to find submissions that haven't been yet been viewed many times.
Step 2: Once you find an idea of interest or less attended, please vote and comment upon it. Please perform this action from 3 to 5 submissions - this will help us balance the comments and votes. Please do not vote your team's research proposals. Once again, everyone is supposed to vote+comment, whether you're the team leader or not.
COMMENT BEST-PRACTICES: As on Crowdgrader, everybody reviews at least 3 submissions, supported by a comment. The comment should provide constructive feedback. Negative comments are discouraged - if you disliked some aspect of a submission, make a suggestion for improvement.
[Team Leaders] Milestone 9 Submissions
To help us track all submissions and browsing through them, once you have finished your Milestone 9 submission, go to the link below and post the link:
Please fill out the weekly survey so we can continue to improve your crowd research experience.