Jim Lynch's Roster Project Home Page

Table of contents

List of Features
Current Status
To Do Items and Volunteer Request
Download or browse the files

Roster is a collection of perl scripts that automate some of the tasks involved in adding students and staff to an arbitrary number of arbitrary types of school servers.

Features:

text-based database keyed by unique student ID code contains one record per student detailing common login name and password on all servers, classes taken, account status for each server.
teacher and class databases.
master student roster, printed and in tab-delimited database form.
individual class rosters (printed and database) emailed to teachers.
handles mid-semester adds and drops if upstream (school-district) download provides info about new or dropped students.

Project status:

Somewhat stable. Documentation poor, but general plan to create man pages for each script and file format planned. Volunteers wanted to help w/ simultaneous internal and external doc project to create documentation sufficient to allow use and expansion. Once this is done, volunteers wanted to help create new server types. OOPizing is in progress. APIs in constant flux, but stablizing. laney.edu has been using Roster for several semesters; alameda.edu for one semester. Vista and Merritt colleges has expressed interest, merritt.edu is in the process of integrating it. See the README file to get a feel; I will be updating this document shortly; it and the internal TODO list are far out of date.

Need to do:

Documentation!! Make it useful to someone who has downloaded the tarball and has no access to me.
NEW!! roster-0.8.* series completely solves this!! generalize to multiple departments and multiple campuses, presently only knows about CIS dept, kludges abound in individual sites.
come up with nice way to view the data (only way now is take master tab-delimited db and import into, say, a spreadsheet or db app)
come up with nice way to edit data (no nice way now)
make it useful for admins who do not program, and do not program in perl (VERY long term: for now, user must know perl)
error recovery systems. Presently, very few system calls are checked for possible error return status. All such calls must be checked, and an infrastructure needs to be planned and created that will handle error conditions in a robust manner that makes the conditions recoverable and understandable at the level of the application. Obviously, this is a long-term goal.
support for more of the people involved: presently, students were and are the main group handled, and that has worked fine up to now. However, it's time to begin handling the lab assistants in an automatic way. The four groups of accounts I see are: faculty, staff (admins and other lab staff who hold varying rights), students and system accts. Eventually, adding a student by hand will be handled, as well as adding lab staff who need access to resources.