WorkingGroups

From Noisebridge
Revision as of 04:48, 12 August 2018 by Beka (talk | contribs) (→‎Problems that arise in WGs and how to address them)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Working Groups at Noisebridge[edit]

SocialMediaWG[edit]

The SocialMediaWG works on Noisebridge's social media content and infrastructure.

Tools for Working Groups[edit]

This section should be used to record all of the useful tools we've built or found that are relevant for working group management and organization.

WG information/documentation template[edit]

WorkingGroupTemplate for making your WG's page on this wiki

Properties of a good working group[edit]

  • Plenty of members
  • Spacetime availability
  • Appropriate skills
  • Eagerness to learn new skills
  • Communication
  • Sharing of access
  • Openness to new members
  • Do-ocracy! Do-ers decide, non-do-ers stand aside
  • Well-defined scopes and progress tracking
  • WG-run infrastructure
  • Up-to-date documentation, group info, source repos, etc.
  • Good tooling

Problems that arise in WGs and how to address them[edit]

This is a non-comprehensive list of problems that can arise in working groups, together with advice on how to address those problems by improving the WG's use of the above properties.

Please add new examples as they become apparent.

Some piece of infrastructure keeps going down and maintenance isn't happening
This usually happens because the members of the working group who've been bottom-lining a particular piece of infrastructure have had changes in their availability, but these changes weren't fully communicated to the group. It also tends to happen because the other members of the group can't pick up the slack, because of their own constraints, or of inability to access the infrastructure, or so forth. Consider working on the following properties:
  • Plenty of members: get better at asking if you have enough members
  • Spacetime availability: manage availability better, dedicate well defined times to working on the WG if possible
  • Sharing of access: make sure all WG members have the access necessary
  • WG-run infrastructure: make sure that infrastructure isn't on personal servers, personal accounts, etc.
  • Openness to new members: invite in more members, especially if there are people who've been trying to work on infrastructure already
  • Communication: be proactive in communicating changes, and synchronize more often (have meetings, hackathons, whatever)
Some piece of infrastructure is under a personal account or on a personal server, and we can't share UN/PWs
This usually happens because it's a quick and easy solution to a problem. A quick fix to put out a fire. Consider working on the following properties:
  • WG-run infrastructure: Set up alternatives that are for the WG instead. Get WG-run servers, WG-run email addresses, etc. and move things over asap.
  • Sharing of access: Once the WG has its own infrastructure, share all of the UNs, PWs, etc.
Some piece of infrastructure is under the Noisebridge account or server or something like this, and the WG needs access to fix or improve things
This usually happens because it seemed like a good idea to build a central place where things are run from. Consider working on the following properties:
  • WG-run infrastructure: Not everything needs to be on "official" Noisebridge servers or accounts or anything like this. It's ok to decentralize, and often is better. Create new decentralized things where possible, and move centralized things over.
Participants in Noisebridge need access to something the WG is responsible for, but not to maintain it, and don't need to be part of the WG
This usually happens when the standard methods of using the infrastructure are also the standard ways of maintaining the infrastructure. For example, social media accounts have a UN/PW and that's the way to do everything on the account, whether it's posting new content or maintaining the account's styling and Noisebridge aesthetic. The former probably should be more open, but the latter is more infrastructural. Consider working on the following properties:
  • Good Tooling: Look for ways the infrastructure already provides to grant lower access levels than Admin level, and if they don't exist, try to build new an interesting ones! Maybe this means building a new tool, maybe it means buying a service level, who knows.
The Working Group needs new members for sure, and there are people who are eager to help out and definitely capable, but they're new or not everyone in the WG is familiar with them enough to be fully convinced
This usually happens when people feel very personally responsible for infrastructure. Consider working on the following properties:
  • Openness to new members: accept the need and give in to it! You don't have to shoulder all the burden, and shouldn't. Welcome the new members in, but steward them, be there to help them and address your worries from a position of on-boarding not one of exclusion.
  • Do-ocracy! Noisebridge is a do-ocracy, do-er's decide, non-do-er's stand aside. Don't stand in peoples way if they're trying to fix or improve infrastructure. It's only Noisebridge at risk, not people's lives or something.