Archive:2007-08-12

Bylaws meeting

 * A meeting to edit the bylaws by committee, despite the inherent inefficiency of such a process.
 * August 12, 2007 (Sunday), 2pm EDT (convert to your time zone)
 * in #freeculture (see IRC for help)

Agenda

 * Continue reviewing RC1 of the bylaws
 * Article VI: Dissolution
 * (backtracking) Article IV, Section 1.1. Board Elections
 * Review comments on RC1 of the bylaws
 * Prepare RC2 of the bylaws
 * diff of changes from 2007-07-29
 * Resolutions not yet implemented in this diff:
 * Run the final draft through a spellchecker
 * Add removal for cause for board members
 * diff of changes from 2007-08-05
 * Resolutions not yet implemented in this diff:
 * Add definitions of specialized terms to Article III, Definitions
 * Add removal for cause for officers of the board (removal from officer position)
 * Specify that all fractions are rounded up to the next person (e.g. 2/3 of 7 people = 4.666 = 5 people required for threshold)
 * diff of changes from 2007-08-07 (forthcoming)
 * diff of changes from 2007-08-08 (forthcoming)

Log
2007-08-12/log/bylaws

Next Meeting
The next bylaws meeting will be 2007-08-14 at 6 pm EDT (convert to your time zone) in #freeculture (see IRC for help).

Web Strategy meeting

 * A meeting to discuss communication/collaboration tools FreeCulture.org -- come with your thoughts!
 * 12 August 2007 (Sunday), 5 pm EDT (convert to your time zone)
 * in #freeculture (see IRC for help)

RSVP
If you plan to attend this meeting, please RSVP here! Please list your chapter, and link to your userpage on the wiki if you like.


 * Gavin Baker, University of Florida (alumnus)
 * Nicholas LaRacuente, Swarthmore College
 * Asheesh Laroia

Big questions

 * What tools do we need to work online most effectively (internal communication/collaboration, external communication)?
 * How can we best coordinate the work of many volunteers?
 * Improve recruitment: easy to get involved
 * Improve retention: don't drive volunteers away
 * Improve efficacy: get stuff done &amp; don't duplicate effort
 * How can we most easily get the right information to the people who need it?
 * How can we make sure the critical tasks never slip through the cracks?
 * How can we provide useful resources to our chapters?
 * How can we effectively &amp; professionally communicate with the public?

Specifics

 * How we use the wiki
 * Semantic MediaWiki


 * Single login / OpenID


 * How we use Launchpad
 * Should we use Answers ("this project officially uses Launchpad for community support")?
 * Should we use Translations ("this application officially uses Launchpad for upstream translation")?
 * This means translations of human languages (cf. "localization"), right?
 * Should we use an IRC bot for reporting bug status from Launchpad? er (Bug 126238)
 * If so, do we use a different IRC channel, or #freeculture? (see below, "How we use IRC")
 * Should we use mentoring?
 * Should we use tags?
 * Should we use series (e.g. "stable" and "unstable")? (see below, "Live beta site / SVN")
 * Should we use milestones?


 * How we use IRC
 * Should we only have one channel, or multiple channels (e.g. for teams, for chapters)?
 * See above, "Do we use a different IRC channel for the Web Team?"
 * Should our channel name be #freeculture, or #freeculture.org, or something else?


 * Live beta site / SVN
 * We should force all changes to go through SVN (Bug 125337)
 * This will prevent the site from breaking; more accurately, this will make it much easier to rollback changes when the site breaks, and track changes to see what broke
 * We should have a live beta site for testing changes as they're made (Bug 127453)
 * This way, the site won't break when we're fixing things
 * A change made on the live beta site could be marked "Fix committed" on Launchpad; a change committed to the live non-beta site (through SVN) could be marked "Fix released"
 * See above, "Do we use series on Launchpad (e.g. 'stable' and 'unstable')?"


 * Calendars
 * For meetings, teams, deadlines, etc. (Bug 127422)
 * Auto-import date of next x meeting
 * e.g. on the Contact page: It'd be awesome to say, "Come to our next volunteer meeting, which is scheduled for YYYY-MM-DD"
 * For coordinating personal schedules (Bug 127421)


 * Mailing lists
 * meta-lists: One list posts to another list
 * e.g. New posts on the blog are automatically also sent to the discuss list
 * Incidentally, should we have posts to the blog go out to any other lists, e.g. chapters or volunteers?
 * e.g. In the past, when we used the announce list, we considered whether to have posts automatically sent to the discuss list
 * Front-ends
 * Another way to make sure the message gets out, rather than meta-lists, is to use front-ends to subscribe people to our mailing lists, which can direct them to subscribe to other lists (or can automatically subscribe them) in addition
 * Gmane (or similar) feed (Bug 127746)


 * Regional communication
 * Mailing lists?
 * Web calendars?


 * Internal communication
 * Newsletter(s)? (Weekly, monthly, quarterly, semi-annual, annual? Email, blog/RSS, print/mail?)


 * SSH
 * Is it a good idea to let people log into SSH without requiring a password? Where the physical device has been compromised (e.g. by intoxication, roommates), a password is a practical barrier to people accidentally deleting our entire Web site.


 * Suggestion: we should create a "job tracker" to manage assignments better.
 * What this will look like:
 * When someone volunteers for a task, s/he will "check it out", so that other people can see who is working on what. S/he will then either complete the task and mark it as such, or "release" the task back into the pool of things that must be done if s/he cannot complete it.  It might be possible to alert people to status changes for specific issues.
 * Tasks should have priority, just like bugs. People should not check out high priority tasks unless they are actually going to do them.  Lower priority issues can be handled with less pressure.
 * IRC, mailing lists, etc. are still ways to assign, but people will no longer need to decide to take something on at a meeting or when it is announced - there will always be things to do if someone feels like putting in more time.
 * How to do this:
 * Already very similar to bug tracking - find a good program (maybe Launchpad), and see what can be customized and generalized beyond actual code bugs.
 * Suggestion: establish protocol.
 * Vague assignments are the easiest to not make measurable progress on.
 * We can use wiki pages to describe our conventions on things like blog posts, taking on tasks, contacting other orgs, etc.
 * Next time you have to teach someone how to do something, write it down in a wiki page.

Log
2007-08-12/log/tools

Attendance

 * Gavin Baker, University of Florida (alumnus)
 * Nicholas LaRacuente, Swarthmore College
 * Asheesh Laroia, Web Team leader
 * Nelson Pavlosky, George Mason University Law / Swarthmore College (alumnus)
 * Peter Olson