Catalog Project

LibriVox Catalog Project

Description

The Librivox Catalog project is meant to serve the following purposes:

1. To allow listeners to find the items they are interested in. #Listener Requirements
   1. To search and browse the catalog on many different facets: author, title, reader, solo vs. collaborative, ...
   2. To provide listeners with a means to tag and discuss recordings/works (a la Flickr?)
2. To allow MCs to manage projects: #Emcee Requirements
   1. To initiate or cancel a project
   2. To post, schedule, assign, and monitor status of work to be done
3. To allow readers to participate in projects: #Reader Requirements
   1. To volunteer for, provide links to, and check off work within a project
   2. To track what they have volunteered for, what they've finished, and the schedule for their work-to-be-done
4. To allow catalogers to provide detailed cataloging information to be used by listeners to find recordings
   1. To see what is not yet cataloged, is partially cataloged, is mis-cataloged, ...

Requirements

1. #Catalog Security And Administration
2. The Librivox Catalog should present a simple search face to the casual user. PageLayoutRequirements
3. Additional roles are assignable to any given user, providing access to other areas of the application as needed (e.g., one could be a listener and a cataloger, but not a reader or MC).
4. We should keep as much interaction between participants as possible in the forum. This helps keep the people aspects of Librivox close to what they currently are.
5. ... more requirements, please ...

Design

Initial Database Design #Flow For Works

---

Listener Requirements

1. Free-text search
   1. Yahoo!/Google-style search: enter search terms in the search box, get a list of results.
   2. Advanced search: like the above, but with pull-downs to allow search to be limited to specific fields (author, reader, title, ...)
   3. Tag search for items tagged by the reader or by others
2. Tag mechanism
   1. add (shared) tags to works
   2. tags are related to users, so removing a user removes the users tags (to avoid tag-based spam) (yes, people suck sometimes)

Emcee Requirements

Discussion

I really need to know more about the editing/proofing process. Is editing done by the MC, or by someone else? and I have no infor on the proofing process at all.

Requirements

1. Start a project, defining the work to be done in terms of recordings to be made.
2. New projects are added to the "active works" index, available to users with the "reader" role.
3. Add volunteers to the project, possibly creating users for them if needed?
4. Assign/reassign/deassign recordings to users.
5. Establish a schedule for the overall work and the individual recordings.
6. Projects owned by MCs who drop their MC role are given to the "orphaned" user.

Reader Requirements

1. To find what works are available to be read for
2. To volunteer for a recording
3. To note that a recording is complete, and either upload it or point to it on another server (possibly with multiple protocols? http:. ftp:, ...?)
4. To get a list of the items they've volunteered for, the status of those items (as far as the catalog application knows), and the due date(s) for the item(s).
5. Recordings owned by a user who drops the reader role are automatically put back on the "waiting for volunteers" list and the MC is notified.

Catalog Security And Administration

The catalog will need to be secure. This will entail

1. backups
2. user security

Administration should probably be decentralized as much as possible; what model is best for this?

1. "Root" or "Admin" users - can add or delete anything anywhere; dangerous if one of these is hacked.
2. Role-based: unless a user has a certain role, some data and pages are invisible to him/her.
   1. listeners and anonymous users have no roles. They cannot write anywhere, but can read the reader pages (to encourage "I could do this").
   2. readers have the reader role. They can see their own reader page.
   3. MCs can see all reader pages (including ones for other projects). They can give users the reader role by selecting them when they volunteer. The have CHUD for their project pages and recording status pages.
   4. Catalogers can see ... what? What do they need to see? Catalogers can give other users the cataloger role.
   5. Any user can drop a role for him/herself; a cataloger can decide to stop cataloging, for instance. Items controlled by users who drop roles must be reassigned; we'll need an "orphaned" user for projects underway that have lost their MC, and works to be cataloged that were owned by a user who is no longer a cataloger.

Flow For Works

A work follows these steps through the recording and cataloging process:

1. proposal
   1. proposal is floated on the forum
2. accepted (by metacoordinator)
   1. metacoordinator opens project in catalog
   2. metacoordinator supplies basic cataloging info (title and author; works to be recorded)
3. obtain project coordinator
   1. Project is posted to the forum as needing a coordinator
   2. Also appears on the "looking for coordinators" page
   3. Coordinator volunteers on forums
   4. Metacoordinator adds coordinator to project
   5. checked off on "looking for coordinators" and note posted to forum
4. Call for volunteers to forum
5. Readers claim parts
   1. coordinator enters who, what, and when due into catalog for each part
6. Readers post parts
   1. coordinator
7. some parts posted
8. all parts posted
9. book coordination complete (waiting for metacoordinator)
10. book completed
11. Cataloging complete
12. Ready for release