Noon, October 1st, Conference Call

1. The Big Plan
   • BALUG in general
   • sponsorships/funding/budgets/policies, etc.
   • general direction, plans, and vision for BALUG?
2. BALUG Web & Email Issues
   • beta.balug.org - where, objectives, participants, etc.
   • longer term Internet plans (redundancy, fail-over, RSVP system, etc.)
   • Website
     1. Do we have access/own all of the resources that we need?
        • not yet:
          • need to get full control of DNS (Michael Paoli following up on this)
          • redundancy/failover? Once we're off of DreamHost we're down to exactly one system shared with SF-LUG - and that system will be going through major changes soon (i.e. downtime).
            • What are BALUG's requirements for hosting the site?
              1. System & Storage?
              2. Physical Access?
              3. Bandwidth?
     2. Can we move forward without the old broke mysql stuff?
        • yes and no:
          • yes - we've got beta.balug.org. - can put it anywhere we want and use it as long as we want
          • no:
            • unless we want a gaping hole in BALUG's history, archives, and web site, etc., we still have more work to do to extract 2003-09 - ~2007-03 content (meeting minutes/links/summary pages and contents from speakers, various other useful web & wiki pages)
            • we can't smoothly transition the lists without doing some well timed and coordinated mysql extracts and loads. Yes, we can get subscriber's e-mail addresses, and a slightly munged form of the list archives without the mysql pieces, but without the mysql pieces we'll lose all the other stuff (e.g. list subscribers names, preferences and passwords, non-munged archive contents, etc.)
     3. Anyone opposed to a hosted wysiwyg solution like sitekreator.com?
        • yeah, I'm not keen on the idea:
          • Haven't we already been sufficiently screwed by "managed hosting sites" where we don't have full control of the materials/tools/software/etc. and easy ability to quickly replicate the same functionality and content elsewhere?
          • "managed hosting" sites usually let us do what we want - but only so long as it's something the hosting provider will let us do - it can be very constraining and problematic. We really don't need more of those issues/limitations.
          • do we really want to be subject to terms that aren't under our control and can be changed at any time without notice, and be agreed to the terms in advance?
          • various folks might also object on various "political"/freedom grounds.
     4. How can we implement an RSVP system for events?
        • simple e-mail alias? (That's what BALUG had historically)
        • snazzier web form, with reminder option(s), etc.?
          • Should reminders be optional?
        • we probably want to avoid some 3rd party system that folks may not particularly trust and/or that may have terms some or many may find objectionable (e.g. many folks don't want their e-mail addresses made available to yet another 3rd party site that may end up leading to spam or unwanted promotional e-mails, etc.)
        • we probably need to consistently "push" folks towards RSVP to get RSVP responses that would be reasonabe indicators of probable attendance. E.g. if the event is promoted and publicized in inconsistent ways (not necessarily a bad thing itself), but when it's promoted, if there's nothing that implies folks need to RSVP, or they need to refer to our web site (where it would tell them they need to RSVP), then they typically wouldn't RSVP - and as publicity coverage (and response) may vary, we may be left with litle clue as to how many folks to actually expect.
3. Event Communications
   • Which lists/locations? What is the timing? Who posts?
     1. Internal BALUG mailing lists
     2. External LUG mailing lists
     3. RSS from the website
        • feasibility & implementation timing?
     4. iCal and/or similar notification/calendaring systems?
     5. Flyers
     6. Member blogs
     7. Speaker blogs
     8. Event listing websites
     9. Social Networking: Facebook, MySpace, others?
4. Speaker Coordination
   • What is our goal… driving meeting attendance or supporting local causes?
   • How to ensure that we don't double book speaking slots?
     • Update BALUG Speaker Coordination (note that that page may eventually move - but for the time being, that's where it is) - that's what it's there for. If one doesn't put information there that a speaker is booked/confirmed (or even tentative) for a date, then folks will presume the date is open. Folks aren't going to remember that e-mail from N days/weeks/months ago - especially if they weren't on balug-speaker-coordinators@balug.org at the time (and having a bunch 'o individuals trying independently to track the status would be rather redundant with what the wiki page is intended to do; also if folks separately maintain their own copies of such status, when they have conflicting information, how would one determine which information is correct? … with the wiki page it's out there for all to see (and even the revision history of who made what changes and when)).
     • also use balug-speaker-coordinators@balug.org for general speaker coordination - e.g. so the rest of the speaker coordinators are at least aware of some of the key bits of information - like how to get in touch with the speaker and any issues/communications of note. Don't make yourself the single point of failure. Also make sure the speaker is aware of balug-speaker-coordinators@balug.org for contacting us. That doesn't mean every bit of communication needs to go out to balug-speaker-coordinators@balug.org, but if aliens abducted you for a couple weeks, enough communications should have already gone out to balug-speaker-coordinators@balug.org that we'd be able to reasonably pick up the pieces.
   • Best Practices Guide for Speakers
     • did a quite good page of that before; it's still to be extracted from the old BALUG wiki stuff (and no, I don't feel like writing up all that work again, but if someone else wants to, feel free; we can always reintegrate useful bits from the older materials into a newer writeup once we've retrieved the older materials)
5. Event Logistics
   • Update from Mae Ling on the Four Seas
     1. Menu Changes
        • Number of dishes won't change
        • Variety will change & rotate monthly between 4 entrees from the beef, pork, chicken & veggie menu items
        • Menu will rotate monthly between noodles & rice, both of which will be veggie
     2. 50+ people, we can eat upstairs (how to forecast this?)
     3. No more Musical Chairs
        • Portions of food will be determined by the number of blue tickets instead of by number of people sitting at the table
     4. Feb. 2008 - 2008-02-19 - any conflicts between date, venue, and Chinese New Year?
   • Name tags?
   • Address bottlenecks:
     1. Sitting down for dinner promptly
     2. Selling dinner tickets
     3. Late comers
     4. Musical Chairs & non-eaters
     5. Dinner to speaker transition
     6. Door Prizes
   • How can we improve the AV equipment?
     1. Portable Projector (Can borrow from Untangle, Speaker is bringing his own for October)
     2. Portable Screen (About $300)
   • Time for community announcements, how to keep them concise & on topic?
   • Publicizing the next event
6. Finances
   • setting up a bank account
   • budget for flyers, website & anything else?
7. Mailing Lists
   • Keeping Mailing Lists Useful
     1. Flaming: Try to squash it or accept as inevitable
     2. Spam Etiquette: Send every thing down the mailing lists or Send only what the group needs
     3. Unsolicited Bulk Mail: How to minimize

* Get (more) detailed information (text blurbs, etc.) for upcoming confirmed speaker engagements

• update website with the above
• continue to tweak and improve our dining experience and coordination (cat herding and menu improvements, avoiding musical chair syndrome, etc.)
• continue to line up speaker(s)/presentation(s) more future meetings

• In general, increasing moves to a more "production" infrastructure (reliable and redundant web, lists and e-mail) (probably don't need super-high availability, but being able to fail over or recover to alternate system in relatively quick order (minutes to hours, rather than days to weeks) would be a very good thing)
• Migration off of DreamHost.com - including salvaging all that's feasible and of significant interest to BALUG, and smooth migration
  (including:
  • control of and (eventual) migration of DNS (
    • Michael Paoli: e-mailed domain registrant on 2007-09-08 & 2007-09-30
    • Michael Paoli: left phone message(s) and e-mailed again on 2007-10-10
    • Mae Ling Mak: e-mailed domain registrant 2007-10-14
    • need to follow-up as necessary to gain control of registrant and DNS delegation information … without being excessively pesky about it)
  • lists and list archives (including passwords, names, preferences, etc.)
  • lots of wiki pages that were functional there
  • presenter information, presentation/slides and such, and links to such,
  • meeting writeups/minutes of past several years
  • past approximately 3 years of BALUG history
  • (most) all the HTML page stuff
  • information for speakers
  • speaker coordination resources
  • spiffier information on directions to the meeting location
  • other useful resources and pages of information
  • etc.
    )
  • get regular off-site automated backups in place (covering absolutely everything BALUG has hosted on DreamHost.com., if feasible - e.g. including stuff that DreamHost.com only allows access to via MySQL client)
    • have some manual backups of some(/much/all?) of the content
  • new landing places for stuff moved/extracted off of DreamHost.com
    • beta.balug.org. - where should that be? (at least thus far and temporarily, it's on the sf-lug.com. box … but it could be almost anywhere)
    • sf-lug.com. box (and the major migration/upgrade of that to a new box!)
      • BALUG has an IP (208.96.15.254) for its use on that box
      • basic new web infrastructure exists http://www.new.balug.org/
        • As of 2007-09-01 some http://www.new.balug.org/ web content automatically propagates to http://www.balug.org/ (to ease transition)
          • increase the automated http://www.new.balug.org/ –> http://www.balug.org/ web updating
      • Mailman (list software) is installed on sf-lug.com. box, but isn't configured yet
      • BALUG needs to create its own e-mail infrastructure off of 208.96.15.254 (not yet in place, other than the sf-lug.com. box has been reconfigured so it's not using 208.96.15.254 for SF-LUG / default e-mail on the sf-lug.com. box). Note also that BALUG is also (at least thus far) using some of the SF-LUG.com e-mail infrastructure (most notably a bunch of forwarding aliases).
      • wiki - sf-lug.com. has a wiki configured for it (and BALUG is using some of that) … but don't yet have such configured separately for BALUG (under it's own IP address and DNS names and such) - so, the BALUG stuff that's there so far may not be at all in it's "permanent" location.
  • DreamHost.com content extraction
    • Any PHP and MySQL volunteers? (As of 2007-09-24 we've started to get at least some volunteer(s) to step forward on that.) BALUG could use assistance/consulting advice with PHP and MySQL; that could aid transition from the old DreamHost.com hosted site of www.balug.org. and lists.balug.org. Maybe we can leverage some "talk" list(s) or similar resources for answer to specific questions? Nothing all that major to do, but those aren't at least presently expert fields of the current BALUG sysadmins, and they'll likely otherwise manage to muddle through them anyway. Mostly just need to dump some MySQL data - and preferably in most useful/portable format(s) feasible - e.g. we may not be reloading that data into MySQL, but may want to process and pull out relevant bits via perl or other means … though reloading into MySQL might also be a possibility. There's also some (slightly) broken PHP stuff to fix (or diagnose and make a "fix" recommendation). Presumably (my best guess) the PHP stuff was all working with the same, or a slightly older version of PHP, and changes in PHP version and/or some minor goofs in some PostNuke PHP web data have gotten the "old" stuff to the point where it's effectively quite non-functional … but it's probably not all that horribly difficult to fix … at least enough to usefully extract information - which is key objective. Anyway, if some person(s) want to volunteer a bit of assistance/consulting on MySQL and/or PHP, that may be of significant benefit to BALUG.
    • List archives and subscribers, etc.
      • automate backups of this data, as complete as feasible
        • it's presently being done approximately monthly manually (last done 2007-09-03); covers a rather imperfect and limited view of archives (munged @ –> " at " and most headers stripped, and no backup of any attachments), and list subscriber e-mail addresses (but not names, passwords, or preferences)
      • optimal extraction/migration may require fair bit of use of MySQL
    • Older web content (most notably many wiki pages)
      • "just in case" backup of raw data - may have some(/much/all?) of that covered, but that's also a worst case extraction scenario (may not be feasible to extract and reconstruct from such outside of DreamHost.com environment)
      • optimal extraction/migration probably requires some (more) PHP expertise and possibly also some (more) MySQL expertise
  • DNS phased migration off of DreamHost.com
    • have created new.balug.org. and beta.balug.org. (including slave(s))
    • start phased change of balug.org. (get registrar control, add NS records for balug.org.)
    • add slaves for balug.org. (have queued up good volunteer slave resources once we can allow them to do zone transfers)
    • continue to maintain balug.org. zone in mode compatible with DreamHost.com until fully migrated off of DreamHost.com (work in progress - currently being done with (to be new) primary master on ns1.balug.org.)

• e-mail (@balug.org, etc.)
  • The @balug.org e-mail addresses are mostly fairly managed at this point - have functional forwarding aliases in place, have the information on the expansion of the aliases also on the sf-lug.com. box. Main thing missing from @balug.org is reasonable spam filtering - DreamHost.com doesn't offer spam filtering for forwarding only e-mail addresses - they only offer it for e-mail addresses that are fully hosted on DreamHost.com (e.g. the mail stays on DreamHost.com. and is accessed via a web interface … not very handy for forwarding aliases where one wants the mail to be sent to multiple recipients).

This list originally based upon some earlier partial lists / status reports, e.g.:
Any good words as to the gathering of data from the old balug website ?
http://www.balug.org/ updated! :-) (& related information)