KM4Dev Core group Skype meeting

From KM4Dev Wiki
Revision as of 16:23, 14 November 2014 by Davide Piga (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Agenda

No agenda is set for this meeting.

Minutes

Transcript of KM4Dev core group discussion

On Friday 29 April, 8 of us (Ana Maria, Carl, Ewen, Karen, Lucie, Nancy, Pete, Simone, Sophie) had a conversation about the functioning, governance and particularly payment for the work of the core group. Prior to the chat, Pete and I talked to Riff to make sure we'd gather his ideas too. The chat was initiated by an email from Ewen sent to the core group on 19 April followed by another email (20 April, to the same core group) by Pete based on the discussion with Riff and a final one by Pete (28 April) with budget breakdown and suggestions.

We started off the discussion reflecting about the likelihood of the proposal that was submitted to one potential donor to be accepted – which Pete estimates at 7.5 / 10 now. The KM champion that has been supporting some donor's staff advocacy for our proposal so far is on leave, and with a structural reform process ongoing within that donor agency there are more risks of not receiving funding now than a couple of weeks ago. However, regardless of whether this proposal is successful or not, KM4Dev will have to find funding and deal with the above-mentioned issues anyhow.

For 1.5 hours we discussed a set of related issues around the central theme of 'paid work for `core group members?'. They are summarised with the in-principle decisions that we have made below. However, an important distinction should be realised to follow the decisions: As part of the proposal (and arguably any other funding proposal we may get for KM4Dev) we suggest setting up a steering group of 6 members (3 KM4Dev core group members and 3 members from the funding agency).

The difference between the core group and the steering group are the following:

  • Core group vs. Steering group
  • Community-focused vs. Project-focused
  • Conflicts are dealt with by core group members vs. Conflicts escalate to core group
  • 5-6 days of work per year vs. Amount of work depending on task/project
  • Members self-selected / Open group vs. Members selected by core group and according to clear ToR / closed group
  • Unlimited members (right now: 17 members) vs. 6 members
  • Unpaid work vs. Partly paid work: Payment per task, not per hour/day of work

The key agreements:

About core group membership and governance:

  • Core group members should commit for 5 to 6 days of work per year and this will remain voluntary – If you can't commit that time do not apply; we are all busy and that cannot be a reason not to read messages and remain silent at all times.
  • The core group (CG) currently comprises 17 members of which 3-4 are not active. Accountability for our activity as CG members has not been enforced so far. But this will change as we need to move on to a more functional core group, acting consistently. We intend to review membership on a yearly basis by sending a reminder to everyone asking how they're doing and what their perspective is regarding their involvement in the core group. If within 3 weeks (including a reminder) we don't hear from them they are ejected from the core group mailing list.
  • We do recognise however that for new core group members it may be difficult to find out how things work – so we suggest setting up a core group buddy system whereby every core group member that wishes can have a buddy to talk with and check things before engaging with the wider core group (as and when felt). In order to avoid over-burdening of any one member, everyone can have only one buddy and be someone else's buddy (e.g. Ewen may have Lucie as buddy and be buddy for Peter).
  • The list of activities that a core group member commits to individually and that the core group has to deal with collectively will be summarised in terms of reference which Carl and Karen will prepare and share with the core group by 15 May. A draft list of these activities follows below.
  • With respect to the intensity of activities at the moment, we suggest putting a moratorium on new core group memberships until the next face to face event.
  • Past that date, when we start recruiting, we also suggest a 3-month period during which both the new CG member and the rest of the CG decide if it's a fit, after which commitment is firmed up.

About steering group membership, governance and funding:

  • The proposal includes various projects/activities for which we will invite community members to develop proposals. Nancy already suggested some ideas for how to go about this process and Pete's email (see final section about engaging with the wider community below) picks upon them. The projects / activities will be managed by steering group members as highlighted in the table above. Those members from the steering group will retain a stipend amounting to 5 to 10% of the project/activity funding to keep oversight, manage, contract, assist and arbitrate as and when disagreements arise.
  • The exact procedure to allot grants for the projects/activities is difficult to assess so we will closely monitor the process for the first activity funded and reflect on how we go about administering it. We will have to select groups that show they have credentials to deliver the work promised. In principle it could follow the recent KM4Dev innovation grant scheme.
  • Members from the steering group will be elected through a transparent process posted on the community. They will have to develop a proposal to split the funding among themselves for the various tasks at hand. For specific cases – e.g. people who work for UN agencies cannot get funded for those activities – a specific discussion in the core group should help determine flexible alternatives if need be.
  • Transparency and honesty at all steps of the process is central to us. If a core group member takes part to a project, s/he will not be part of the core group discussions that relate to his/her project – this will be agreed among other core group members prior to the discussion. We believe that we will be able to decide collectively on a case by case basis, bearing the above principles in mind.
  • A core group member can thus be also a steering group member but then not involved in project activities. Or the other way around. But no one can cumulate core group, steering group and project staff functions.
  • For the sake of having someone aware of the proposal development process, keeping a close relationship with the donor and to manage the relationship with grant administrator Helvetas, we suggest that Riff consider joining the steering group or recommend someone else from Helvetas – Pete will contact Riff about this.

About engaging with the wider KM4Dev community:

  • Still on the transparency front, it is becoming urgent to inform the whole community about the donor proposal – even though it is not secure – to start a transparent process of inviting members to come up with proposals. Pete has drafted a mail about this and is expecting feedback from all core group members by 4 May.
  • There is not yet another discussion planned but that will follow after next week's interactions re: the proposal for the whole KM4Dev community.
  • Although Nancy raised the question, we didn't answer as to sharing these minutes with the community – but I believe we should.

The next discussion points among core group members will be about:

  • Criteria for the selection of steering group members;
  • Exact arrangements on the buddying system in KM4Dev and recruiting new core group members;
  • Although we will not invite new core group members until then, the next KM4Dev event (realistically back to back with the Rome Share Fair in September) has to be organised and this is where we usually recruit members from the wider community, to spend 2 – 5 days of preparation/facilitation.

If you have any question or comment, please feel free.

Notes:

Draft list of core group activities:

  • List management for a month, with others, 2 times per year
  • Running one conversation/ being an animator of conversations at least over one period
  • Reading every single email shared on the core group
  • Attending three core group meetings per year
  • Managing the sign up grid and making it public
  • Preparing and facilitating annual meetings
  • Keeping up with the core group email messages or asking for help when you fall behind (in other words, stay engaged somehow)
  • Supporting projects in some way (I.e. we are accountable if we get `donor money)
  • Ensuring there is a management structure to deliver agreements with external funding agents, and that any Project Steering group is monitored in their buck stopping role (raising red flags)

The wiki pages dedicated to administrative management of KM4Dev will be expanded with these activities, to keep track of the core group activities and who's on duty on a regular basis – this oversight has to be included in the collective responsibility of core group members and preferably included in individual ToRs to avoid the 'everyone does it – no one does it' phenomemon.