Archive:Hosting chapters/Plan

(Redirected from Hosting chapters/Plan)
Jump to: navigation, search

We want to neatly pre-package a complete chapter website for each of our chapters, including a mailing list, blog, and wiki. That way, new chapters won't have to go through a long, painful process to get inadequate webspace from their school (if it even exists), and people won't have to worry about off-campus hosting donated by random alumns vanishing. FC.o is here, and it is here to stay!

Mailing lists

Each chapter should automatically receive two mailing lists: one for the general public, and one for their "core team". (The chapter can decide for itself whether it wants the public list to be announce-only or discussion too.)

Naming conventions need to be decided upon, I'm actually not certain what they should be.

FC Swarthmore has an "core" list and a general [freeculture] list, both being discussion lists, but only the "core" list receiving e-mails about planning events and grunt work. Valuable discussions have arisen on the public [freeculture] list many times at Swarthmore, and I think there are benefits to permitting discussion there. Florida FC has a "discuss" and "announce" list, just like the national org. Perhaps the differing approaches depend on the size of the school... maybe the Swat approach is better for small schools and the UF approach is better for massive schools.

Perhaps it would be best if each chapter could decide individually what the mailing lists will be named and whether they will be discussion or announce-only (and therefore what the appropriate names would be). Could each chapter have its mailing lists on its own subdomain, so that they can name the lists whatever they want without having to worry about naming conventions? Also, every e-mail to the mailing list would thereby remind the subscribers of the chapter's website URL.


Each chapter should receive a Wordpress blog, from our Wordpress MU or Lyceum installation. It should come with a default Free Culture theme which they can tweak / replace, and plugins which they will find useful.


Each chapter should get a Mediawiki install, with relevant default pages to provide the wiki with some initial organization. See the UF wiki.

Integrate with chapter registration form

Chapter founders should be able to select which of these 3 things they need, and enter in all of the necessary information to configure them upon registration. Once the chapter is approved, the chapter website will be automatically created.

  • The Chapters database itself may need some overhauling... perhaps we should move to a Django app from our outdated no-longer developed Mudbag database?
  • The registration form *definitely* needs to be overhauled to provide more useful information... it needs to have better explanations / more room for explanations of what info should go in each field.


Use cases

OpenID login

  • Chapter representative registers on our wiki
  • Chapter representative goes to an admin web page
  • Chapter representative authenticates to admin site via OpenID

Chapter registration

  • Chapter representative goes to a web page
  • Chapter representative enters his personal information / his chapter's information
  • A core member receives an email from the system with this information
  • The core member approves the registration
  • The chapter is registered

Chapter map

  • Chapter is registered and marked as active
  • If registration info includes the school's address, use that, otherwise use whois on the school's URL to get its address.
  • Take the address, geocode it using e.g. the Yahoo geocoding API into latitude & longitude, store it in the chapters database.
  • Pull the lat/long from the DB along with chapter name + website, put a pin on the map of our chapters (e.g. using the Google maps API).

Sending out goodies

  • Chapter representative enters that he wants PK, EFF, CC (etc.) goodies
  • Core member receives email for confirmation
  • Core member approves goodie request - I guess this could be automated if we had an inventory tracker, which we really should. That would help close the t-shirt store bug. [1]
  • The goodie requests should be time-stamped, and we should be able to mark them as "shipped"

Chapter contacts email list

  • When you become the current chapter contact, you are placed on a mailing list that admin guys can email, e.g. (no need to remove old contacts unless they want to be removed... a chapter can have more than one contact)

Admin oversight

  • Core member logs into web app
  • Core member finds out who the current chapter admins are, and their private contact info
  • Core member calls up Demonstration University leader to ask him what his favorite food is

Chapter hosting

  • Chapters should be able to request web hosting things.
  • Those requests need to be turned into actual web sites, and the way that works is different for wiki farm hosting, mailing lists, and blog farm hosting.
  • If any hosting is requested, a subdomain is created for the chapter.

Chapter wiki farm hosting

  • Chapter admin goes to a web page
  • Chapter admin requests a wiki at
  • An fc.o sysadmin gets emailed asking if that's okay
  • He clicks the link in the email, and the wiki gets made

Chapter subdomain IP address pointing

  • Chapter admin goes to a web page and logs in
  • Chapter admin says he wants to point to some IP address
  • The scripts modify our DNS to make sure the domain name exists and points to the main server IP
  • The scripts modify our Apache configuration to have no vhost configuration

Chapter subdomain forwarding

History in chapter contact info

  • Core member goes to web page and logs in
  • Core member finds out that Miss Watson used to be the chapter contact, and sees her old contact info

Tracking people

It would be nice to be able to note (perhaps only to admins) people's involvement with fc.o, like being able to say, "Mr. Mumble was on FC-Discuss for two years and is now a chapter leader in Demonstration University".

Managing project domains

  • Core member wants to create a new project,
  • ...


Wiki farm

  • Need a script to mysqldump the template, change the table prefix, and insert it into a new table prefix
  • Step 1: Create Reed's wiki - need chapter-local images/ and LocalSettings.php and index.php (can actually remove the PHP if slick)
    • Actually the template doesn't have uploads enabled so images/ isn't so important
  • Step 2: See what can be generalized
  • Central mediawiki install in