This topic grew to include not only meetings and meeting cycles, but also managing the Partnership and the wider community. What follows is a rationalised (hopefully) summary of the points made rather than a linear narrative.

Meeting cycles

In response to a question it was agreed that it was better to have someone at a Partner meeting, if possible, rather than no-one at all. Whilst there was potential advantage in the same person/people attending there is no problem substituting where it helps and different people may better suit different meeting focuses.

Partner meetings are partly about inducting new Partners and encouraging others: this notion should be extended to developer meeting too. It may be appropriate to open Partner meetings to institutions "on the bubble".

Meetings in early 2014 are now likely to be January (UCSD tbc) and April (Stanford following LibDevConX).

The Hydra Connect meeting each year will be the meeting in the year that people should attend if at all possible. It will have a clear focus on showing what others are doing with Hydra and bringing people together. There will not be a parallel coding track as such because we shall want the devs present to be mingling and discussing what they and their institution are about, but we should poll devs on whether they would like a dev meeting immediately following on. The Connect meeting will be open to "adopters" of Hydra as well as formal Partners so that we can get the widest possible understanding of the HydraSphere.

Connect was envisaged as a September meeting (from 2014) but there was discussion of having it in winter to act as a counter-balance to Open Repositories in the summer which also has a "show and tell" aspect. Further discussion suggested that a two-day Connect might be immediate followed by a two-day annual strategy meeting. The strategy meeting could include reflection on the showcase just completed.

There was general agreement that a Partner meeting immediately following LibDevConX, normally the last week in March - but probably April in 2014, remains a good pattern. This meeting is generally a little more dev focused than our others.

There seemed to be a general feeling that three timetabled Partner meetings was enough (many folks meet at OR as well) but an acceptance that there will also be a lot of "working together" which may involve some in additional face-to-face meetings.

It was agreed that it would be very useful to be able to publish an annual timetable of meetings (even if we could be no more exact than the month) including Hydra Camps. Is this the academic year or the calendar year?

Managing meetings

It is useful to be able to announce the main theme of a meeting far enough in advance that institutions can discuss who best should attend. Topics might usefully be cherry picked from the Strategic Plan.

After each meeting an aggregated set of action points should be published as was done after Boston (thanks, Steven).

Although difficult it may be helpful to non-attendees who want to Skype in if major topics cold be anchored to a time - but subsequent discussion queried the value of Skyping in. The ability to dynamically (re-)organise a meeting is probably more important.

Expanding the community

Do we want 50/100/500 Partners? We need to show steady and continued growth but this can be through adopters. Partner meetings would become very difficult if attendance grows much further. Perhaps the partnership bar should be set a little higher? But it was agreed that we should not charge for Partnership. Maybe we should set a "window" for Partner numbers at any given time.

High adoption is good for encouraging further adopters, and the right adopters might contribute to the project's sustainability.

Growth management should be part of the strategic plan but a pragmatic approach to short timeframes is more productive than worrying about what might happen 5-10 years out.

If we pursue "adopters" over more new Partners (but mustn't create ill-will) we need to be clear about what adopters get from us as opposed to what we provide for Partners and to be clear why the jump from one up to the other ought to be attractive to some. All that said, we might still want to actively pursue new partners beyond the US in order to increase our visibility and viability there.

The Hydra Project is seen by some as a model of open source in action. We need to figure out how to spread this message. Some potential adopters/Partners would see a more structured and formal governance structure as attractive - representing a more mature product? Some argument for tightening up our strategic direction.

Browser not supported