SlideWiki Developer Hackathon V4 : Summary Report
The SlideWiki DevOps team (Development and Operations) normally works in different places, time zones, and on different days. We work in a distributed team via GitHub (see a visual representations of our recent GitHub activites) and other systems. Hackathon V4 in Southampton allowed us to easily collaborate as a group or in small teams so that we can efficiently and effectively focus on a set of tasks and goals for three days. During the hackathon we worked together to learn about the technical details of the SlideWiki system, improve SlideWiki, design and create new features. We also review and plan our current development, decision, and communication processes.
This is a pictorial summary of our 3-day SlideWiki hackathon which took place at the University of Southampton on June 14-16 2017:
There were 16 attendees from the SlideWiki ›$DevOps team who attended this hackathon.
Our teamwork really started by a Scrum-style stand-up, where each developer briefly addressed the progress of tasks or user stories s/he is in charge of, any help s/he might need or give, and plans for the rest of the day.
Before Lunch we also looked at our testing server to identify the most urgent tasks for the hackathon.
We continued to upgrade the packages used in our system, especially React & Fluxible, to have the latest and greatest Open Source Software included in our release. We also held breakout sessions to look at improvements for homepage before our public release, and a session to discuss licensing of content in SlideWiki.
The rest of day was spent on pair testing and programming to achieve our goals for release.
Finally we gathered to discuss research topics related to SlideWiki, as many developers are also doing research. The presentations can be found on our experimental SlideWiki server.
On the second day we again started with our stand-up, where we briefly discussed what we did on the first day, if we needed help or could help others, and what we planned to do next. We also reviewed the latest state of our experimental server, which includes the results from work the previous day. We checked how far we got, and whether there were any new issues or tasks to address.
Next we looked at performance optimization in a break-out session. We had discussed this before in an online teleconference call, but now we identified performance improvements that we could quickly implement together during the Hackathon. Each participant in the break out was allocated a task, for example, reducing the size of the libraries used in SlideWiki such that users can load SlideWiki in their browser faster with less internet bandwidth.
Another break-out session involved the status of the Natural Language Processing and content recommendation in SlideWiki. The developers involved gathered to discuss the current state and future research and development that could be undertaken within SlideWiki.
An important benefit of a Hackathon is that we can be together to directly solve problems and implement new features head-on, e.g., by sitting together behind one screen (pair-programming). A large part of the hackathon is reserved for these activities as we have found that they are highly-effective. This was our focus for the afternoon.
We started our third day with our stand-up, with each participant briefly describing what they had achieved during the previous day, if we need help, and what we will do this day. Many issues were resolved and new features were close to being ready to merge into the platform.
During the day we also discussed our ongoing development priorities for after the public release to enable us to continue to improve SlideWiki and add planned features. A break-out focused on how to connect SlideWiki to existing platforms, for example; Slideshare, Prezi, Google Slides, SlideBank, and Sliderocket, and to look at best practices of existing platforms.
After pair-programming for the past two days, and adding new code to SlideWiki, the final activity of the Hackathon focused on testing the new code and fixing any bugs that came up during testing. We wrote down over a dozen testing tasks on a whiteboard (with number-identifiers of the complete task description in our project management tool JIRA) and then asked attendees to complete these tasks and report any issues. Issues were directly examined and fixed by people involved in the creating the code related to the issue.
In the afternoon we concluded with a break-out session on real-time concurrent editing of slides, an upcoming deliverable that required design decisions.
Overall we had a successful Hackathon creating 47 development tickets and completing 23 in three days. As well as providing an opportunity to program together, these meetings enable us to ensure we can work effectively through our distributed network and develop a close working relationship that is necessary for agile development.
Report by Abi James and Klaas Andries de Graaf. Pictures by Ali Khalili.