Recently there have been questions from various parties about the future of a hackathon platform I have been working on called Dribdat, originally announced and mentioned on this forum. I wrote a précis of what I think makes Dribdat relevant to the open data community, with some question marks about the future of the project.
From a School of Data standpoint, hackathons are an excellent testing ground for data sources and way to apply learning hands-on in a challenging-yet-supportive environment. Dribdat helps by connecting participants and visitors to new projects, and helping to spread data literacy through well documented/ cross-referenced/ sustainable development.
Some of the possibilities being considered may also be of interest to other communities and users. The central question is that I am trying to work out here, is how best to use limited capacity to optimally „hack“ on this project - and at the same time, open up to wider collaboration. I am writing this in hopes of finding additional contributors to support the next development sprints, or at least getting some feedback on whether/how to continue the project.
During the pastfewhackathons we made improvements to the platform and raised several issues via participants. Here they are in order of most commented, along with brief discussion.
This is a big one, and points to a rewrite of the platform along the lines of a JSON linked data schema based standard we’ve been working on. Since the API is already in place, the basic task of aggregating hackathon results across platforms through this process should take around 3-5 days to prototype and deploy.
This is more of a community appeal than a specific issue, nevertheless it represents the work it takes to maintain an audience, and engage fellow developers in planning future sprints. I would say 2-4 days could be well spent in formulating a strategy and renewing efforts here.
This is a nasty issue, we should really fix it and move on to Python 3 like the rest of the planet. 2-4 hours should do it, hopefully, unless libraries need to be swapped out.
The problem is not just old browsers, it’s also the honeycomb itself which has is not very well UX-engineered, and the design of which is getting old. I would like to replace it with a nice, custom infographic - 1 day of work.
This one should be a low hanging fruit, but I’ve not managed to decide which dashboard to use, and potentially points to a revamp of the analytics/scoring process. 1 day.
As the platform stems from the open data movement, being an exemplary user of web data standards is important. I think we could well spend 2-3 days implementing a better strategy for showcasing and linking to datasets in the platform.
This issue is kind of a dupe, but it also shows that users care about how the page look. I would reformulate it to say: improve the project page design! We have some good ideas already. At least 1 day, the more the better.
We keep getting asked about this… I would spend 1 day and Just Do It™.
Ugh. Can’t believe this is still broken. 2-4 hours.
People like this approach. We should build it in 2 hours.
Fix it please. Quick. 30 minutes. Done.
Annoying but not trivial. 30 minutes.
Requires further research, otherwise not much code work. 4-6 hours.
Improving Etherpad support would be a really nice value-add. 2-3 hours.
Must have, especially if we can support more platforms. 4 hours.
I personally resent this bug. Must. Destroy. 2 hours.
This one should really be the top of the list, as number 1 user annoyance. 4 hours.
I’d love to see this happen, in a GitHub-friendly way. Needs design. 1 day.
Cool idea, possibly duplicated by #112. 2 hours.
Actually just a shell script or something would be fine to start with. But yeah, freezing an event would be important. 4 hours.
I like this idea. 2-3 days to do it right.
There are a few “if’s” here, but generally, we should. 2-3 hours.
Oh, yes. Linked to #112. 2-4 hours.
So much cry, this one. 3-5 hours.
A sure crowd-pleaser this would be. 2-4 hours.
This is where it all begins, and the UX stinks. Run a focus group. Do some sketches. Try out some frameworks. Spend 2 days to improve this critical area.
