High School Reunions – 10 years!

In scary news, my 10-year high school reunion is coming up. Since 1997, I’ve hosted the [Conroe High School Class of 1997 e-mail list](http://www.marius.org/chs97/), and I’ve been receiving more and more updates as of late.

The page has pretty much been static since 1997, with the exception of a few changes and additions of user data. It’s all manual entry in HTML, and, admittedly, from a spam-harvesting/privacy perspective, it’s horrendous.

I’ve been thinking about it, and have searched [SourceForge](http://www.sf.net/) and a few other project sites to find a better way to do it.

I can’t find any software that does what I want to do in (what I think) is the ideal sense.

### My Alumni/Reunion Software Wishlist ###

#### Pre-population ####
I’d like to pre-populate the data with every name in my high school yearbook, and this should be publicly visible. Honestly, people are going to stumble onto the site by dropping their own name into their [search](http://search.live.com/) [engine](http://www.google.com/) [of](http://www.ask.com/) [choice](http://www.yahoo.com/). Most people aren’t going to search for things like “Conroe Class of 1997” until it’s reunion time.

#### Pictures ####
One thing I’ve learned through all this is that I don’t remember who most of these people are. It’s been 10 years, and I’ve met a lot of people since then. (And, let’s be honest, I’ve slept a few days since then) I’d love to store (in the database) a blob item with photos from the high school yearbook. I know it would be a fair amount of up-front work, but I’m willing to do it.

#### Contact Info ####
Yeah, everyone stores e-mail addresses, URLs, addresses, and phone numbers. I do some of it now — but, like I said, it’s not friendly from a spam-harvesting perspective. Let unauthorized users drill down per-person and see details, but front it with a [captcha](http://en.wikipedia.org/wiki/Captcha) to keep the spam-bots out as much as possible.

#### Registration ####
This is the big one. Updating e-mail addresses, phone numbers, etc., is hard on the admin. Empower users to update themselves. Let them create a login to self-service their own account. This is an _enabler_ of other features, such as subscriptions and account take-overs.

> ##### Subscriptions #####
> RSS feeds, e-mail notifications, whatever. Give the users the choice of how they’d like to be informed of changes, additions, and deletions of the data.

> ##### Take-Over of Accounts #####
> So, someone registers an account, but we’ve pre-populated the data! Avoid duplicates, let them take over the pre-populated account and take over the management of it. Perhaps this needs an administrative approval or something similar by the people running the site. Simple enough, right: a moderated subscription process that ties the user account to a particular entry in the database.

Maybe if I get some free time, I’ll solicit these ideas to some of the folks that are hosting various SourceForge entries.