Research Software Communities: Organising events to help develop and grow your community
Research Software Communities: Organising events to help develop and grow your community
Posted on 18 June 2019
Research Software Communities: Organising events to help develop and grow your community
By Simon Hettrick, Jeremy Cohen, James Graham, Carina Haupt, Connah McKendrick, David Gillespie
This post is part of the CW19 speed blog posts series.
The number of research software communities is growing rapidly - local communities, regional communities and national communities are all gaining recognition and interest amongst the large number of developers and researchers who write software to support/undertake research. Communities can provide a wide variety of activities to support their members but events offer the main opportunity to meet and interact with other community members. However, there are many different types of event.
What kind of events do software communities need? Well, it depends on the community, its profile and aims, and its members. Typical events that software communities could benefit from might include lectures, workshops, training and technical seminars. However, these events themselves are not capable of sustaining a community.
The question of what kind of events communities need seems simple but is deceptively complex to answer!
First, we should perhaps ask “What is a community?” Are the needs of one software community the same as others? How can you be inclusive and engaging at events, and sustainable, getting people to sign up as members to the community and engage actively! This post will try to pose some answers to these complex issues and provide some recommendations.
Challenges
Let’s first have a look at the typical events like lectures, workshops, and training sessions and why they can fall short in their ability to help with building communities. The obvious influences on attendance are: location, time, topic, and how attendees rate the quality/usefulness of an event (which will affect re-attendance).
Based on our experiences and analysis of the DLR software engineering community, people are much more likely to attend an event if it is located at their work location. Reluctance to travel can be a problem even if an event is located just 10 minutes away.
Event timing/duration are obvious constraints, given that researchers tend to have hectic schedules. The time of day that an event takes place can be a particular problem. For example, a lot of community events are hosted in the evening, which can be very impractical for parents or carers. The topic of an event can have different influences: If a topic is considered to be interesting, people will attend, despite the need to travel or if the event timing is impractical. But a wide range of topics in an event series, can prevent the creation of a community, even if more people attend in total.
Lastly, if the execution of an event is not carried out well, people will not return, therefore making community creation impossible.
Optimising these attributes can increase the potential of events helping with community building. But in our experience, the community building potentials are still limited.
Diversity
Diversity and inclusivity, in the context of a Research Software Community, include many factors, such as: gender balance and inclusion of researchers with differing levels of experience and across different faculties or schools. It is also important to support under-represented groups within a community’s target audience by working to ensure that the community offers a variety of activities that can appeal to all its potential members. The group of people attending an event may be heavily influenced by the language used to describe it, as well as both the format and the content of the event itself. An example of the importance of language is demonstrated by an event that was initially described as a “Hackathon” and subsequently changed to a “Collaborative Coding” event - this change in terminology took the gender balance from almost 100% male, to an even mix between the genders. The name “Collaborations Workshop” is itself an example of the successful use of language to promote diversity and inclusivity. Similar issues have been noted with the use of the term “Software Engineering”, which may exclude those researchers with less programming experience, those from subject domains not perceived as traditional producers of software, or those not seeing themselves as Engineers of any kind.
Once an event is running it is important that participants continue to feel included. Short ice-breaking activities are one possible mechanism for this. Examples of this are a game in which attendees are given a Scrabble tile and asked to form groups spelling themed words.
Not just a lecture: Developing ideas and activities
To adapt to the changing needs of a software community, it is important to provide a range of different events that each cater for a different need in the community. There is a tendency in academia to think of all community events as being seminar series. Although seminars provide a convenient method of delivering a large amount of information to a group of people, they are not always well suited to the “community” model. Communities thrive on communication and networking and in a seminar that communication is almost completely unidirectional. Any community, especially one with such diverse needs as a software community, has to be supported with a range of events. Seminars may well be an important aspect (although we suggest 30 minutes is sufficient for a talk), but other networking events should also be provided. For example, discussion groups in which a large community is split into smaller groups (5-10 people) to discuss an issue, surgeries (where people are provided with short one-to-one sessions with experts in different areas), lightning talks (where a large number of people present their ideas in very short - say two minute - talks) are all valuable approaches to support and develop the communication between community members.
Conclusions and Recommendations
As highlighted above, software communities need to provide a variety of different types of events to ensure that they can support their members and can be sustained in the long-term. However as we have discussed, simply running events is not sufficient. How events are promoted, structured and presented to the community holds the key to ensuring that they encourage interest in and engagement with the community. We conclude with a set of 4 recommendations that we believe are of particular importance in building a strong and sustainable software community:
-
Offer a combination of event types - seminars, training, discussion, networking and socials. Include a range of activities to offer wider appeal amongst potential attendees
-
Think about diversity - even if you are in a community that lacks diversity, ensuring that you make an effort to demonstrate some level of diversity in your community will help to make it feel more inclusive and open to potential newcomers
-
Be inclusive - think about event timing, consider varying timing of events to suit different groups of attendees, think about topics and subject areas
-
It should be fun - encourage informal engagement, have fun activities to appeal to new members, don’t only stick to the classics like “beer and pizza”!