The first part of the GitHub campus experts’ training is to write an impact proposal. My impact proposal was largely focused on ensuring future generations of organisers can effectively inherit the existing organisation and continue to make the community their own.

Specifically - the concept of knowledge transfer was very central to my thoughts throughout. As it happens, GitHub itself was a potential solution for this. Knowledge transfer is important for student communities as churn rate of positions is high. Once new people join to keep the organisation going, how can they quickly get up to speed?

Generally, a new organising team is elected each year. But even during a single year, new people can join, and people can leave. This is largely because students often over-commit. An unpaid, voluntary role often must take less of a priority than studies or paid work.

The idea was to use a GitHub organisation to run a student community. At first, I wasn't confident everyone would switch. Maybe people would just stick to Slack? But I was pleasantly surprised - it seemed to work well.

Repo

Repositories are used for separating concerns of the organisation. The most heavily used repo as of writing is HackSheffield/3, which contains everything about HackSheffield 3.0. I'll focus on that repo, but there are also repos for general community issues, publicity materials, our website, and some other projects.

In the directory structure are things like contract templates, signed contracts, email templates, and other assorted things. Before we can get to the point where we have signed templates, we need... Issues!

Issues

Each repository has issues. So for the example of HackSheffield/3, we had a few types of issues as you can see by the set of labels:

They can be further filtered by Author:

and User assigned:

Generally, most tasks or discussion points for organising an event come under these categories. There may be other ones that are useful but this is what we found.

The most heavily used labels are probably sponsorship followed by catering. These things specifically had their own project boards...

As students in CS, many of us are on GitHub every day. So issues updated simply appear on our GitHub homepages. So when one person contributes, it encourage everyone else to feed back about that contribution.

Another way to encourage GitHub contribution was to set up a Slack integration to post there. This is effectively an alternative notification channel, allowing people to consume updates in another way (with push notifications!) on top of GitHub's email or website notifications.

Projects

For the previous hackathons we used a mixture of Slack and Trello to organise the events. Slack for the main discussion, and Trello for status tracking.

This brought up some issues with getting people to update their Trello board. Most discussion therefore just happened on slack. No one was actively using Trello at the time for anything else. So generally it was just one person trying to keep things up to date based on Slack discussions. That's not really collaboration. Oftentimes, people would just talk on Slack and forget to add decisions to Trello. It just wasn’t central enough to the organisation process.

Enter GitHub Projects. I think GitHub Projects were a much better solution for us.

The conversation is already happening on the issues. So as soon as status changes, that issue’s card in a project board can be moved to a different status column. In addition, when the status changes on the board, that is displayed on the issue page.

GitHub now feels central to the organisation process.

Vision

This brings me, finally, to the visionary benefits of this system. One day, if people persevere with GitHub, people can simply look at past years’ repositories for the relevant files or issues on past events. Often, sequel events can save a lot of time and effort by looking at the context around things. Questions can be answered. Confidence can be given to organisers based on what had happened before.

For example…

Sponsorship

"Let's contact this local company about sponsorship! Can anyone find an email address? Hopefully they will respond to our blind email.”

That turns into "Let's contact them through our previous contacts and leverage the knowledge of the past to our advantage. Let me just look at the past repo to see what happened.".

This is effectively using GitHub as a CRM. Maybe a CRM would be better suited to the task, but GitHub works well for event organisers. Despite not being created specifically as a CRM - it is general purpose enough to act as one.

Students organising Hackathons don't want to learn professional CRM software (and check and update it daily!). But they do want to learn how to use Git and GitHub! They are learning Git and GitHub to organise their community, whilst in the process learning how developers can collaborate on code.

Vendors

With catering, you get similar benefits. You can look up what meals were there before with a simple search through issues using tags. Then, you can look at specific issues to see the progress on the caterer if updates were made. Were they professional? How much did it cost? Did they make things easy for us? All of these questions can be answered.

Being able to answer these questions with a quick search gives us power. It saves time. It gives us the knowledge required to make decisions with confidence. It means one organiser’s work in 2017 is helping the organisers in 2018. At the time, they might not realise it, but they could be massively influencing the direction of the next event simply by a quick positive or negative comment on an issue.

This means it is important to keep issues up to date. By not updating your issue when the situation changes, you are doing a disservice not only to the current organisers but those in the future too.

New team features

At GitHub Universe, new team features were announced. Stay tuned for more on how usage adapts… but it looks exciting.

If anyone has any questions, you can find me on Twitter @_mattburman or otherwise via my website