Steering committee development

Hi all,

we’ve had a few conversations recently about what the DataSHIELD steering committee might look and function like. We are now at v0.1 of what that might be and we are looking for some input from the community to see if we are heading it the right direction.

Purpose of the steering committee (with some examples)

  • Ensure funding sustainability.
    • By contributing resources to core projects
    • Volunteering groups for maintaining core components.
    • Putting in (joint?) grants that cover core components.
  • Guide the technical direction.
    • Should we concentrate on particular development priorities?
    • Is it ok to make a substantial breaking change to the code?
  • Sign off policies.
    • As the code of conduct and contribution policies are developed these need sign off.

Membership of the steering committee (in no particular order)

  • 1 PI/senior representative from each engaged consortium/cohort group.
  • 1 or 2 senior DataSHIELD user representatives who would gather feedback from the community.
  • 1 independent software representative outside of DataSHIELD.
  • 1 from OBiBa.
  • 1 or 2 senior DataSHIELD developers.
  • 1 lay person.
  • 1 ex-benevolent dictator.

Ideally the steering committee will meet 3 or 4 times a year (mostly virtually, but we should aim to align with common face to face meetings where possible).

The Newcastle team is happy to support the initial administration of the committee, but that doesn’t mean we want to chair it - we’d rather that was someone external to us.

So, over to you. What major purposes have we missed and which other groups of people should be on the membership?



Hi Olly,

Thanks for starting this conversation off, I think it’s really important this is moving forwards as it will help make DataSHIELD stronger for successfully tackling the challenges of the future.

This is a good list already :slight_smile: I probably wouldn’t have put stuff in the same order as you, but I recognise that at this stage it’s a brain-storming exercise and not in any kind of priority order. Thus, here are some additional off-the-top-of-my head thoughts about things I would add/change (some with explanations):

  • Guide strategic/technical direction
    • this overlaps substantially with what you’ve described as setting the technical direction, I’ve just expanded it slightly so it isn’t restricted to only technical issues. Other examples may be the development of working groups, e.g. to look at legal issues
  • Policy development and overview
  • Maintain and promote visibility
  • Representation of DataSHIELD to the wider world
    • I’m thinking here of if/when DataSHIELD is invited to participate in conferences or needed to give media interviews etc.

My only concern here is with the first membership group - representatives from each engaged consortium group. This might be hard to define, especially when the consortia run out of funding (e.g. RECAP Preterm is only funded until the end of March 2021), and then the question becomes how to define which is an eligible consortium to be represented etc. I unfortunately don’t have an good suggestions about how answer to this problem yet, but wanted to flag it so that we could all think about it.

Actually, one additional thought I’ve just had is to maybe set a limit to the size of the steering committee - e.g. “The steering committee will be limited to X number of people, with membership made up from the following groups (suggested numbers indicated in brackets): … [and then put your list here]”. The reason for this is if it becomes too large, it becomes unwieldy and impractical.

Anyway, thanks again for getting the discussion going!



Thanks Andrei,

I’d more or less agree with everything you have said. The first point on membership is a really hard one, the only ‘workable’ suggestion I have for that at the minute is to make it point number one on the agenda for the first proto-steering group meeting. (Passing the buck).