University of Sheffield students don't have access to a culture of open source contribution in the outer community. HackSheffield, CompSoc, and the mainline Computer Science course itself do not make a focus of bringing developer skills to the outer community. Right now, the focus lies in teaching the fundamentals themselves, but bringing these to the wider community is something that I have personally found difficult, as have others. There's this vague statement of 'find a project that's got "help wanted" attached and get contributing', but there are so many questions surrounding that - the scale of the undertaking, whether one knows enough about the language to do what's required in the right way, and naturally, that daunting feeling of being so small in comparison to the scope of some projects and the faces behind them.
This is a problem I still have personally, and it is one that has been recognised by the society. It needs some power behind it to be tackled, however. I'd like to make this not just a journey of solving it for myself, but a journey for the community of developers within the University. Perhaps what I do will go on to inspire a change in the approach of student software development communities across the country. After all, my toolset is very much shaped by the experience of others, and the freedom of software should by proxy create a free community of information and expertise that evolves the skillset of developers everywhere. That is my vision.
I intend on creating a platform for open source collaboration within the HackSheffield society, This will involve passing on the skills needed to contribute to open source software, finding opportunities both within and outside of HackSheffield to do so, and recognising the contributions made by its members as individuals.
Naturally, the main ingredient of collaboration is a project - a common goal, a problem, an improvement. Without these, the concept of upskilling developers for open source in the real world wouldn't be a necessity within HackSheffield. So the question here is obvious:
The answer isn't quite as obvious as the question, because depending on the familiarity and confidence of our developers, there are varying degrees to which this could be done:
- Internally managed projects at HackSheffield, such as our front-facing website and some tools that can be used across the society. An idea I have had personally is a registration system that we could incrementally flesh out - with the right hardware, we could use Eventbrite tickets as passes to get in and out of the event and keep a constant register of all present.
- Individually managed projects in small groups. These are a grey area as they'd need to be run by someone competent with using Git and GitHub to be stable, but I feel like with a common goal (and time) these would get the same level of enthusiasm and power behind them as a good hackathon project!
- External projects - the prime example being ones with 'help wanted' issues. The society should keep an eye on projects that permit contribution in this way and are open to beginners. I'm aware there might be a section on GitHub's Discover that reveals projects of this kind, though I've browsed it myself and it seems a little daunting. However, experience in dealing with the first two kinds of projects would increase developers' confidence and lead them this way.
As I have previously discussed with Matt, we need to engage and sustain the interest of HackSheffield members. HackSheffield is quite a remote society, for lack of a better word - with no weekly socials, most of our experiences are shaped by the hackathons we attend as a group, and for those working on projects at those events, the groups in question are normally fairly small.
Another challenge is that while this is a fun activity, it's within the field in which we intend to work, so learning something new on top of a whole day of lectures is likely to be a bit of a pain. So the question is:
I can't call this a perfect idea without seeing its effects, but here goes either way. A new bite-size format for workshops would be good - the idea of spending a whole evening learning Git after a day of lectures is quite tiring as a concept, so I suggest the following format:
- Some time for social gathering to begin with, to foster the kind of friendships and communities I've seen in my experience at SLUGS. HackSheffield's current role as more of a background society could well be expanded to fill this void for many computer scientists who perhaps haven't reached out to others on their course for whatever reason. This is something I empathise with greatly.
- A couple of talks, each lasting about 20 minutes maximum (with maybe 5 minutes minimum to get the message across) aimed at providing a particular skill. This could also include some sandbox exercises to familiarise with the concept locally.
- More socialising, as before.
This will be a sandbox, to some degree. The vast majority of us will learn some valuable things about Git collaboration at scale, the things necessary to control it, and ease of use for all. Matt and I have been introduced to some concepts that will be useful for this, but the main question we want to answer as a means of addressing control as an issue is:
How do we ensure the safety of what is put into production, no matter the skill level of the developers working on it?
In a talk at GitHub Universe, we were introduced to GitHub's branch protection features. This would mean that we could task a particular group of people with assessing code quality. We are also aware of continuous integration as a concept, which would be a good rabbit hole to dive down in this instance, since it would save students' time and ensure fast responses. Bots that police repositories are also a good option - this was brushed over in the talk.
This ties into control to some degree, but we want to assert that code that's being pushed is being done in a correct manner and, naturally, is good code. Coding practice is something that's taught within the confines of the course, but linters and fixers aren't. The very basics of Git are rushed into a group assignment, leaving many potential users somewhat alienated if they don't already bear an enthusiasm for the ins and outs of software development. There's more to Git than many of us know about, and the most vital intermediate/advanced tips need distributing on our quest to upskill developers.
People know Git and GitHub to a variety of degrees. How do we get everyone on the same level and ensure a standard?'
The aforementioned branch protection features are good as a quality control measure and safety device, but good code isn't guaranteed even with those. The society is already very good at educating people on basic Git commands such as add, commit, push and so on. But there are many things that don't get expressed as important tools to have to a great enough extent within the local community. Squashing, rebasing, dealing with conflicts effectively, and writing good commit messages are all things I can't say I've seen discussed heavily enough. I'm glad to say that I'm starting to practically understand squashing and interactive rebase as of this post. What needs to be done here is the existing Git workshops need to be tailored to include these or further workshops need creating, with the goal that even if you already know Git, you should attend to learn some best practices (if not, link to git-scm to let them do it on their own time).
The existing workshops tend to be run by CompSoc, in which we have crossover - Rob in particular. More marketing needs to be done from HackSheffield towards CompSoc with this in mind, and we need to collaborate on these workshops. We also need to find the available assets from git-scm and GitHub itself to base these workshops on, and try to distribute the details to those who can't make it for whatever reason. One workshop we should run should be on linters - linters are very useful tools to have at your disposal, so it would be well worth running a talk about those - ALE in Neovim, Autoformat in Vim, atom-beautify in Atom, and whatever anyone else uses.
It also needs to be made very clear that in order to contribute, it's very necessary to have this level of knowledge, and in the meantime, running bots to police commit names and contents would be a good move.
The goal of giving credit is to foster an environment that draws attention to the more positive experiences that this program would provide, and to build things in that general direction. The credit that this program provides should also increase enthusiastic society members' chances at joining the committee. As a whole, every positive or negative experience provided should power the program forward to become a strong part of the society in future years - contributing to open source, in summary, shouldn't be scary and should be a vital part of any serious potential software ceveloper's portfolio. As its main goal is inclusivity, this credit should not create unhealthy competition, and should instead build an atmosphere in which the achievements of others inspire one to contribute more. So the question this time is:
A lot of this is done naturlaly by the GitHub platform. Filling your individual contribution graph across a diverse array of repositories is a goal of most GitHub users and is even recommended by recruiters as a way to mark yourself out as a devoted developer, so there is a major personal benefit there.
On a community scale, GitHub's other visual representations of commit data per repository are good ways to measure your contribution. I'd also suggest the creation of weekly socials in which there's some form of show-and-tell about the impact individuals might've had on repositories lately, recent learnings, useful tools adopted, etc, also featuring a short workshop. (It'd give us a neat way to drain that sticker stash...)
As a side note, I'd like to add that HackSheffield intends to use GitHub for as much as possible. I don't want this to amount to marketing for GitHub despite our extensive use of the platform - that is not the primary role of a campus expert, a concern expressed by the head of GitHub Education, John Britton.
So, to summarise, what I've laid out here is a pretty drastic programme, but it's all built with the goal of getting aspiring student software developers out into the wide world of open source to make a name for themselves, a discovery for the society, and an impact in the community. Whether that's their first commit in a group repository or squashing their many local commits clean for a fix in React doesn't matter - the intent is to create something for all levels of skill, and a natural curve to follow that can ease people into the wild. Some of it is simple society stuff - events and workshops, for example - but some of it looks at software development from a higher level with the aim of creating transparency in the society and achieving more together.