Migration Plan

The idea is to bring existing member content over to this new Bucketworks Members site, so that

• the original Bucketworks site can devote itself to providing information about the facility, its role and the mission and vision for it in the community, and its programs
• This site can be used by Bucketworks Members to
  • display information about themselves to the Bucketworks community and the community at-large, and
  • develop shared, member-to-member communications and activities.

How we’ll do those things is still being worked out - we encourage member participation in this working-out process, just as we do in most facets of Bucketworks.

Here are some ideas on a page for discussion of Using The New Site.

For the sake of conversion, Staff input is required.

Here’s a link to the Migration List, on the main Bucketworks site -

Pages on the old site with relevant information

• Membership
• Group Membership
• Business Services
• Theatre Members

Tegan has generated a list of wikigroups, removed the obvious non-member groups from the list. Staff needs to work through the list and assign each to a treatment category.

How does this plan of attack look - please comment if you spot any issues with it:

Wikigroups untouched for 6 months

1. copy oldest member wikigroups over, completely as-is
2. delete source pages except HomePage (or most-used page if there is no HomePage)
3. on old HomePage, add wiki code explaining the move, providing link to new placement, email contact - see example Tegan’s old homepage. Everything there is code that can be pasted on any homepage of any group.
4. on new member wikigroup, add a generic GroupAttributes if none exists on the old one - setting read-password.
5. grab any uploads, too.

Contact for members looking for their old wikigroups: - right now this just goes to Tegan

Wikigroups untouched for 1 month

Same as above, do as a second round

Wikigroups in current use

Contact owners and plan the move. On this new site, members will not (hardly ever, anyway) have the option of hiding content behind passwords. Making stuff unreadable on here would pretty much defeat the purpose of its community-development function. So we’d figure out a password scheme that works for them, and help them relocate material that ought not be made public. Offer boilerplate text for helping their visitors follow them, and let them keep as much as they want on the old page, so long as it’s a single, inactive page - to be revisited in 6 months.

Access to moved material

With the oldest material, most ‘owners’ will never ask for access to their stuff; they’ve forgotten it ever existed, and its contents have expired. When an owner does ask for access, though, the process will be for Tegan (or who-ever) to discuss protection strategy, and assign new custom read and edit passwords to the group and/or pages for the owner.