London Governance Discussions

From CrisisCommons
Jump to: navigation, search

Topics for founders weekend

  • Topic 1: CrisisCamp for Europe. CrisisCamp has been very successful in the US, but hasn’t had much uptake across Europe (i.e. we’re it). Do we need to change the way that we work, in order to get more Europeans into the camps? Suggestions include targeting specific technical universites in the way that the USA appears to have done.
  • Topic 2: Project processes. There should be an easy way of recording that a project is available and that it's safe for CrisisCamp to work on (i.e. not potentially damaging to children etc). There should also be better monitoring of projects so CrisisCamps leads can negotiate work for their teams ahead of their camp dates.

Governance

Goal

The goal of CrisisCampLdn is to maintain a technology-based crisis response team (people, tools, infrastructure) and to deploy that team in response to appropriate large-scale humanitarian crises. Maintenance of the team will be through regular (nominally monthly) "CrisisCamp" meetings; deployment of the team will be through weekly CrisisCamp meetings at the start of each suitable crisis. CrisisCampLdn shall be supported by, and part of, the global CrisisCommons organisation.

Responsibilities

CrisisCampLdn is organised by a Governance team consisting of a General Manager, Facilitator, Project Coordinator, Outreach coordinator, Inreach coordinator, Venue coordinator and External Advisor.

The overall responsibility for each CrisisCampLdn rests with the General Manager. Each team member can delegate tasks to other team members as required. In particular, the General Manager should delegate responsibility to the Facilitator as required.

Role Responsibilities
General Manager Overall responsibility and information hub, password coordinator
  • Acquire venue for each CrisisCamp
  • Ensure insurance for camps
  • Ensure regulatory compliance (data protection, copyright etc)
Facilitator Make the projects happen
  • Maintain a list of CrisisCampLdn volunteers and their skills
Project Coordinator Make the projects happen
  • Maintain a list of active CrisisCampLdn projects
  • Maintain a list of potential CrisisCampLdn projects
Outreach Coordinator Information coming in, information going out
  • Prepare and distribute press releases on CrisisCampLdn
  • Identify potential funding or resource sources for CrisisCampLdn.
  • Arrange VIP visits to CrisisCampLdn.
Playgroup Coordinator Manage the ‘tasks anyone can do’ projects for people who are less techie but still want to participate.
Venue Coordinator Look after hardware, space and passwords
  • Ensure facilities at the venue
  • Ensure internet access at the venue
External Advisor *

Project Process

Somewhere to keep notes on the CrisisCamp project process

Internal view of CrisisCamp project process

1) An external agency fills out the online TechAid form. Or an agency approaches a CrisisCamp representative with an idea for a project. Or a CrisisCamper suggests a project to their facilitator. If possible, the project description should include a clear statement of the goal of the project; it should always include contact details for the project proposer. The project is added to the CrisisCamp “Proposed Projects” area.

2) A facilitator is assigned to the project. For online TechAid forms this will be the global CrisisCamp facilitators (i.e. Heather/Noel); for local approaches this will be the local CrisisCamp facilitator. The facilitator’s name is added to the project’s “Proposed Projects” description.

3) If the project goal is not well defined, the facilitator starts a discussion with the project proposer about what the goal should be, and if necessary (i.e. if it’s outside the scope of the facilitator’s knowledge), adds the project goal to a dedicated CrisisCamp discussion area (probably a wikipage for now) for wider CrisisCamp discussion.

4) If the project goal is well defined, the CrisisCamp facilitators check the goal for legal issues and overlaps with existing CrisisCamp projects and make a go/no-go decision on the project.

5) If the decision is ‘no go’, the agency is informed. If this is because their goal is covered by existing CrisisCamp software, the agency is told where to find this and who to contact on how to use it; if not, then an attempt should be made to identify other places (e.g. It4Communities) that their goals might be met. The project is added to the CrisisCamp “Nogo projects” area, and removed from the CrisisCamp “Proposed projects” area.

6) If the decision is ‘go’, the facilitator helps the owner to fill out the technical details section of the TechAid form. A wikipage is created for the project. The project details are added to the project wikipage. The project is added to the CrisisCamp “New Projects” area for all CrisisCamp teams to view (unless the project owner specifically states otherwise) and removed from the CrisisCamp “Proposed Projects” page.

7) A project manager picks up the project. They form a team with the skills required by the project. The project manager fills out the “project summary” section of the project wikipage, including their name and contact details. The project manager adds the project to the CrisisCamp “Active Projects” area, and removes it from the “New Projects” area.

TBC.

External View of CrisisCamp Project process

A first cut at the external view of the project process (i.e. a fusion of everyone’s comments so far):

1) You give CrisisCamp: your contact details and a project goal description (less than 250 words).

2) A CrisisCamp facilitator will be assigned to your project. This is the person from within the Crisis Camp team that can facilitate the conversation between the client and a Crisis Camp project manager. This is the person that either the client or project manager can talk to if the process isn’t going well. At this stage, they will either help you to clarify your project goals, give you details of software, sites, groups etc that already meet your goals or give you a reason why this project cannot be completed by CrisisCamp (and a list of alternative sources for this work, if possible).

3) CrisisCamp will advertise your project description globally (unless you request otherwise, i.e. you require work to be done in your home country) and wait for a project team to adopt your project.

4) A CrisisCamp team adopts your project. This team will be led by a project manager, who will be in direct contact with you to agree:

  • the detailed requirements of your project,
  • an estimated project timetable, i.e. an estimated start and end date for this work
  • an ad hoc question process (how to deal with ad hoc questions when they arise during the project, e.g. contact details, method of contact, availability),
  • a demo timetable (you commit to a specified amount of time reviewing and giving feedback to demonstrations of the project; we commit to creating a demo-able application for the demos) and
  • a dissemination route (how the work will be disseminated or operationalised).

5) The CrisisCamp team works on your project. The project manager will report on the team’s progress towards the project goals, either directly to you or through the CrisisCamp facilitator. For most projects, you will also be able to track progress through the team’s CrisisCamp wikipages.

6) The project reaches your goals and is released for use.

7) The project output is tested, either internally at CrisisCamp or with your help in its operational environment, and feedback on its performance is given to the project manager. For small changes, this will trigger minor fixes by the project team; for larger changes it may also trigger a project extension, i.e. a repeat of steps 1 to 7.


Notes on Project Process

The project process needs to be wider than the externally visible one, and we also need to take account of the project process work that the TechAid team have already done (see the Requests and Techaid wikipages).

The process should be the same for internal and external projects, with the caveat that we also need a category and a page for ongoing work (e.g. “System Administration”) that unlike a project does not have a clear start and end date.

Every project should have:

  • A start point. At the moment (see the Projects wikipage and Noel’s comment on the project googlegroup) we have 4 stages for each project:
    • proposed – the TechAid form has been completed, but the governance team has not approved the project for work yet
    • new – the project has been released for working on but does not have a team assigned yet
    • active – a team has started work on the project
    • completed – the project has met its goals

The start point of a project should always be the TechAid form, but there is an argument for a preliminary stage where the project goals are not yet clear and need discussion by the team. We need to create a space where these proto-projects can be discussed and worked up before the TechAid form is filled out – perhaps this could be an extension to the TechAid work?

  • Owners. The current process already enforces having an external (see the Proposed projects wikipage for examples of projects that are inactive because no contact details were supplied). But, as Alan points out, we also need an internal owner right from the start of the project. This will be the local facilitator (for local relief organisations that are talking directly to a CrisisCamp) but for projects that are received directly through the website will most likely be the global CrisisCamp facilitators. We do need a policy here of local/global btw: if someone walks into a local crisiscamp with a project idea, it should be posted globally for work anywhere unless the owner specifically objects.
  • A clear project goal: specific, measurable, achievable etc. This is more important than a project description, because without a goal you cannot tell when a project has finished.
  • A go/no go check between Proposed and New project stages. We got very worried one week because one of the “new” projects could potentially have been misused; there are also strong overlaps between some of the projects that could have been better exploited. Yes, we need a TechAid form before we start a project, but more importantly we need reassurance that the project will not get us into serious legal difficulties or waste resources by repeating work that’s already been done.

That gets us as far as the “new” stage of the project. At this point, the project needs:

  • A project manager. This person takes the project goal and produces
    • a set of requirements, including: soft and technical skills profile, owner-furnished information needed, other information sources (e.g. access to field workers) needed.
    • links to existing CrisisCamp projects (to stop rework)
    • an estimated time to complete
    • a design sketch of the finished product
  • A team. All volunteers, remember: this limits what we can reasonably ask of them.
  • A timetable. See above. You cannot commit to a set timetable if you’re using volunteer effort across several continents. You just can’t. You can commit to get to the project goals, but you can’t drive part-time volunteers in the same way that you can drive full-time staff.
  • A reporting mechanism. This too may be more complicated than it looks. We need to remember that although one agency may put in a project request, we should still be free to offer the same software and services to other agencies that need it. The notion of ‘client’ then becomes one of ‘an agency with a specific need that’s prepared to tell us what they need’ rather than ‘person with authority over the project’. This is an important distinction, and one at the heart of most open source coding.

notes for UN meeting

  • we treat internal projects the same as external ones in terms of the management process

1) Working with a client we write down a very short description (<250 words) of the project.

2) We put this up on our noticeboard to see if anyone is interested in doing it.

3) If there is interest, we then work with the client to complete the rest of the “Project Form”.

  • Our philosophy is that no project is started without the details on the “Project Form” being completed.

The project form contains the following:

  • the project “owner” – the person (in the client organisation) that “owns” the project, that can make decisions about its requirments.
  • the project facilitator – this is the person from within the Crisis Camp team that can facilitate the conversation between the client and a Crisis Camp project manager. This is the person that either the client or project manager can talk to if the process isn’t going well.
  • project manager (from Crisis Camp)
  • project description – the short description <250 words.
  • kickoff time – the project owner and project manager commit to a discussion to start the project and set the direction for the first iteration of work.
  • the demo timetable – the project owner commits to a specified amount of time reviewing and giving feedback to demonstrations of the project. Likewise we commit to creating a demo-able application for the demos.
  • ad hoc question process – a process is agreed between the client and project manager for how to deal with ad hoc questions when they arise during the project. (Eg. contact details, method of contact, availability)
  • dissemination route – the client describes how the work will be disseminated or operationalised.

We don’t start a project unless the form is complete. To test whether there’s interest a project, a partial form just containing the description can be completed. However if the client wants to then we can complete more of the form.

This is the same for internal projects which also require an (internal) project owner, with a time commitment from them and a demo timetable etc.

Action Planners

Action list for Monthly CrisisCamp

Put here the list of actions that we need to do (what, who, when) to manage each monthly CrisisCampLdn meeting. Note: D=day; H=hour.

what by when by whom
Advertise camp on EventBrite D-30 Facilitator
Advertise camp on Facebook, Linkedin, Ning, Googlegroup, Twitter, Upcoming, Geekery.in D-30 Outreach
Advertise camp on Facebook, Linkedin, Ning, Googlegroup, Twitter, Upcoming, Geekery.in D-21 Outreach
Arrange media/VIP visits to camp D-21 Outreach
Advertise camp on Facebook, Linkedin, Ning, Googlegroup, Twitter, Upcoming, Geekery.in D-14 Outreach
Organise venue D-14 Manager
Add venue to EventBrite D-14 Manager
Advertise camp on Facebook, Linkedin, Ning, Googlegroup, Twitter, Upcoming, Geekery.in D-7 Outreach
Organise internet access (Wi-fi) D-7 Venue
Organise food D-7 Manager
Organise projects list D-7 Project
Email message to attendees D-7 Outreach
Day planning meeting D-3 All
Read how to manage... D-1 All
Bring Projector/s, mains distribution blocks D Venue
Day schedule – see separate note D All
Wash-up meeting D+3 All


Monthly CrisisCamp meeting day planner

Describes activities over a monthly CrisisCamp day. Please discuss and edit as necessary.

what when by whom
Set up camp environment inc wifi 09:30-10:00 Organisers
Meet, greet, get skillsets list 10:00-10:30 Facilitator
Register (name, skillset), login, mingle, read projects lists 10:00-10:30 All
Welcome Meeting and Project Allocation 10:30-11:00 All (facilitator or nominee to lead)
Work on projects 11:00-16:30 All
Checkin 12:00-12:05 Project Managers, Facilitator
Lunch arrives (nom, nom) 12:30 All
Checkin 13:00-13:05 Project Managers, Facilitator
Checkin (optional)(1) 14:00-14:05 Project Managers, Facilitator
Checkin 15:00-15:05 Project Managers, Facilitator
Checkin (optional)(1) 16:00-16:05 Project Managers, Facilitator
Tidy up and document projects 16:00-16:30 Project Managers, Facilitator
Feedback Session 16:30-16:50 All
Tidy up 16:50-17:00 All
Go to pub 17:00-20:00+ All

(1) Checkins can be either at one or two hour intervals - with smaller groups of people, less frequent checkins have worked.

Needs

Venue Needs

  • extension cords / 4 way gangs (Core team will provide bulk but please ask peeps to bring own if poss.)
  • gaffer tape (to tape trailing cables to floor) (Core team will provide)
  • contact with Relief Web and its users
  • food & drink (hot drinks at LKL 50p in honesty box)
  • Two computers to run the projectors (twitter and IRC walls) (Would be nice to combine into one wall)
  • network infrastructure to share limited wi-fi connections (Spike got Vodafone 3G enabled WiFi/wired network)

Things we generally need for a CrisisCamp

  • Preparation: Please read Wiki Commons London pages as homework before next event
  • Communication and information
    • Wiki editing and help: Crisis Commons Wiki video
    • Realtime Chat (iRC) via Chat Server channel #crisiscampldn
    • Mailing lists
    • Website
    • coordination with all relevant and affected parties
  • People
    • Everyone spread the word, get bums on seats > it is really cool, sociable, fun, and a great place to come if you’re currently not employed or need to learn new skills or meet top people… blog & talk, bring friends! Lots of less techie stuff needed as well as solid coding skills, such as communications, project management, video, blogging
    • SEO skills
    • facilitators & project managers
    • Volunteer coordination skills
    • Relief Web project team would like to meet / call / chat to relief workers to get feedback. Note: tendency to attract people already overloaded >> need people with some slack time
  • Resources: food / drink / coffee
  • outreach to potential attendees
    • Charity organisations – Do they want representation here? (Merlin, Shelterbox, Red Cross, etc).
    • Geekyoto email out promote event
    • Africa Gathering email out promote event

CrisisCamp in a Box

Error creating thumbnail: File missing

London CrisisCamp has a cardboard box that holds all the camp tools inbetween camps. London thought it would be really cool if we could create a set of things that could be used to create a CrisisCamp from scratch: this is "CrisisCamp in a Box". We haven't got very far yet with transcribing all the things that we have in the box, but here are a couple of them.

Welcome to CrisisCamp!

1. Write your name on a label

2. Add a “geek code”

C = coder

U = user experience/design

P = project manager/facilitator

D = domain knowledge/NGO etc person

S = systems, admin, infrastructure

K = “Kommunications” and publicity, blogs, twitter, etc

3. ROCK ON!

Sign in on the laptop


Facilitators

Ask these questions to clarify and resolve

Phase 1

  • What issue/proposal are we focused on?
  • Do we have any other clarifying questions on this proposal/issue?

Phase 2

  • What are the concerns (issues, design requirements, etc) that we need to address?
  • Are there any more concerns (issues, etc) that we haven’t heard, especially ones that will stop our proposal from working?

Phase 3

  • What change to our proposal would resolve this concern?
  • What is the smallest agreement we could reach that would let us move forward?

Phase 4

  • What is the next step?
  • Who will do what next now? (or by when?)

If people look stuck, ask these questions!