Hi All, Has anyone ever used ledger for managing crowdsourced work? I'm thinking, for instance, of how it might be used by a requestor on Amazon's Mechanical Turk (mturk). Amazon's web interface and API both leave a lot to be desired from the standpoint of project management, workflow, and long-term records -- you really need to build your own. I'd like to be able to put together a system that can coordinate work across multiple crowdsourcing and outsourcing providers, such as using mturk in concert with oDesk, ziptask, TaskRabbit, etc. I think ledger can make a good core for this, due to its commodity-agnostic way of doing things.
As an aside, has anyone ever noticed that accounting data looks like a hypergraph, where each transaction is a hyperedge? Ledger, because of its flexibility, is almost a general-purpose flat-file hypergraph database. Some of the following whackiness comes from the thought that project management and workflow are (hyper)graph problems. I don't think I'm taking full advantage of that in these examples, and I'm open to better ideas. Sticking with mturk for this example, let me first define some terms -- for an 80,000-foot overview, see https://requester.mturk.com/tour/how_it_works. A "requestor" is the person paying "workers" to do things. Requestors can also pay bonuses to selected workers. Requestors can assign qualifications to selected workers, and only allow workers with those qualifications to work on a particular task. Mturk workers are anonymous, using IDs which are a long ASCII string, such as "B3LJKHC0NH9TIX". A task is called a "HIT", and each HIT can include multiple similar "assignments". For example, a HIT might be "match address with street view photos", and might contain 1,000 assignments. For quality control, it's typical for mturk requestors to post redundant assignments; those 1,000 assignments might only contain 100 unique addresses, each of which are matched to photos by 10 workers, and the requestor might pay bonuses or assign qualifications to workers whose answers agree with at least 6 others. I'm thinking of taking advantage of ledger's multi-currency ability to track and report not only USD payments but qualifications, bonuses, and individual work records. The USD part should be easy, but my accounting is rusty and I'm just starting to play with ledger, so I'll state this in English instead of as ledger entries for now: - USD deposit to Amazon account (debit assets, credit equity) - USD transfer when posting a HIT (debit expense, credit liability:mturk) - USD transfer when worker answers a HIT (debit liability:mturk, credit liability:{worker_id}) - USD transfer when rejecting worker's answer (debit liability:{worker_id}, credit expense) - USD payment to worker when accepting an answer (debit liability:{worker_id}, credit assets) - USD payment to amazon for their percentage fee (debit expense, credit assets) - USD payment of bonus to individual for a given HIT (debit expense:bonus:{worker_id}, credit assets) It gets more interesting when tracking work records and qualifications. HITs, assignments, and qualifications can be commodities, each with their own commodity code. Amazon assigns these codes; again, long ASCII strings. I'm picturing something like the following, though I'm not yet sure this is right. The stuff inside the left-hand {XXX} is the commodity codes: - {hit_id} expansion of balance sheet when posting a HIT (debit receivables:mturk, credit income) - {assignment_id} expansion of balance sheet when HIT is answered (debit receivables:{worker_id}, credit income) - {assignment_id} contraction of balance sheet when rejecting an answer (debit income, credit receivables:{worker_id}) - {assignment_id} transfer when accepting an answer (debit assets, credit receivables:{worker_id}) - {hit_id} transfer when all assignments in a HIT are complete (debit assets, credit receivables:mturk) - {qualification_id} expansion of balance sheet when assigning a qualification (debit expense:{worker_id}, credit assets) As I said, I *think* that's right -- can anyone see anything wrong with it? One thing I'm stuck on is what the payee fields should contain for those transactions, given that each worker_id already shows in the subaccounts. I'm sure the most ledger-ish way will become obvious to me after using ledger for a while, but does anyone have any ideas based on what I've said so far? In case it's not obvious, all of the above transactions are from the perspective of a single traditional company, where workers are cost centers. I suspect a worker should instead be a profit center -- an independent accounting entity, with their own chart of accounts and P&L. If I understand ledger right, that would cause an explosion of mirrored transactions. But doing that on the accounting backend does help get rid of at least some of the central command-economy of a traditional business, and brings nice implications for how work is managed. I'd love to hear anyone's thoughts or experiences using ledger for that sort of decentralized governance, even on a tiny scale. Steve -- --- You received this message because you are subscribed to the Google Groups "Ledger" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
