Tag Archives for theory

Teaching Ourselves & Each Other: Blogging & Sharing

Theory: Making space for folks to engage in self-teaching is empowering others to teach themselves

An opportunity to honor agreements about process and collaboration:

  • With the Femme Conference, when we agreed on using google-docs as part of our process, that meant we would use the file-sharing and form-making capacities
  • Some people kept sending docs as links not “sharing” –> sent gentle reminders twice over a few months to “Share” so we can all access
  • Some people sent me g-docs with their forms in them –> sent a gentle reminder to make forms in gmail and “share” it with me and the Collective gmail account.
  • Are these details kind of trivial? NO! They determine whether the entire technology setup is going to be collaborative or a shitstorm of emails and confusion.

An opportunity to give people access to resources and to support accessibility by providing resources:

Blogging was happening a lot by four committees and not at all from the other five committes. In the interest of accessibility, I created a google doc how-to and shared it. [download it here] It contains both direct links to WP’s documentation on blog posting and a step-by-step Best Practice Guide that uses screenshots from the actual femme2012.com blog to help folks see exactly what/where they are doing:

 

Accessibility: Process and Outcomes

How was this development accessible?

Pushback on designer/web-creator’s role as a corrective to gatekeeping of former web developer and as a site of power for the input of individuals and committees:

  • Admin Logins shared with many [some security measures in place]
  • Author/user logins shared with all – ability to post to wp blog universal
  • Insistence that committees create their own content for web pages via shared google docs means that many people can input into the content and easily add and edit to it — more voices in the process of developing.

Why is building in wordpress accessible for this project? Because so many people are able to use WP and feel comfortable in it already or quickly after beginning to use it:

  • WP is accessible to many people at various states of comfort with technology due to its WYSIWYG interface, semi-obvious taxonomies, and [relative] build-out simplicity.

 

Agility in Site Development

THEORY: When design is agile, we’ve produced “less than” and not taken too many ideas into the mix, stayed within or below scope, waited for users to respond to product, not overdeveloped before getting user information.

For example, the previous website was a Joomla! build from former developer, heavy and not accessible by anyone who didn’t know the Joomla! CMS [not that the designer was willing to share a login, but anyway].

How was this development agile?

  1. The first web presence implementation was just one HTML page [no screenshot available] — just getting the Save The Date and conference theme “out there” [and collecting SEO on the URL]
  2. Second was Twenty10 WP theme [the default theme] with a header and a few pages — just getting the Call for Submissions forms up and public without any major design work
  3. Third implementation of WP Page Lines framework theme with more design, bells n whistles — adding in pages that were requested, more attractive design, and integrating social media presence.

Non-agile ideas that were researched and discarded:

Radical Pedagogy

Theory: Seeing the connections between participant’s senses of Self-ownership, Responsibility to the project/process, and Horizontal Power

–       need systems that reinforce everyone’s power within the system: including people who think they “don’t know how to use the system”

–       Horizontal power is reinforced where there is leadership on the process and people who are resources, but no one owner

–       Ex: Google Forms instead of web forms, everyone had to learn to make them themselves [and that was a challenge for some folks], but now have power over shutting form down, control of info in form, access to applicants instantly, etc.

Collaborative Technology Reasoning: Beg, Borrow, Buy

Why collaborate with a specific technology? Why not just get our work done some other way and all hand it in? For starts, in a collective–or any horizontal project–there’s no manager to hand it in to, no boss, no one to organize the work for you but you. Getting organized is a systems-level problem that best be addressed as soon as possible.

And for projects that have principles that base around justice, equality, accessibility, and collective or direct-democratic decision making, the choice of platforms is a political decision.

For the 2012 Femme Conference, we needed to set up a system where 14 core organizers and 30 subcommittee members can work together — both in terms of accessibility and capacity. Systems we chose thus had to be not overly hard to learn or use, but still must allow for organization and effectiveness.

We looked at possibly using:

I tried to get people to use Crabgrass [open source!] or Basecamp [more useful!], but the request from the majority of the other organizers was that most people had existing Gmail accounts and were familiar with the interface, so we went with G-docs

  • Theory: Choosing the achievability of agility and accessibility over principles, choosing to fight battles later with other technologies. For example, I decided to force WP participation rather than “force” the use of a platform that no one would use.

In an ideal build we’d have Crabgrass or Open Atrium sitting on a Drupal site, but in an ideal world we’d be paying someone to build this. Better to pick that which will actually happen and — most importantly, that which people are willing to interact with.

  •  Theory: I like to occassionally remind people that Gmail is a “begged” resource that datamines our every word typed in, just to raise awareness of the issues in using “free” software that’s not Free/Libre software.