This repository includes the two files that must be included in all project submissions for Sacramento County's Hack4Sac Civic Tech Challenge:
- this
READMEcontaining instructions and information to include in your submission; and, - a
LICENSEthat allows anyone to do anything they want with your code as long as they provide attribution back to you and don’t hold you liable.
Please complete the information below:
[Enter a project title]
[Enter a short description]
- [Team Leader Name, email address]
- [Additional Team Members, email address]
- [...]
- [If you worked with County staff to develop your project, please enter the name and department of your contact]
- [Include any nonprofits or other stakeholders you engaged in the development your project]
[Include any necessary instructions for developers to setup their local development environment and deploy your project to a production server]
[Include any additional information that you would like the judges to know about your project]
By forking this repository, we'll be able to find your project which will allow the judges to review your submission. Please note that cloning this repository or copying the contents of this README to your project will not allow us to find your project. Learn more about how to fork a project repository.
You probably want your project to have a name other than Hack4Sac, so go ahead and rename your project repository. Also, feel free to edit the description and URL of your deployed app at the top of your repository on GitHub.
As long as you keep this README.md file in your repository, hack away on your project to your heart's content.
Add your project name, description, and team members at the top of this file by committing changes. In the LICENSE file, replace [fullname] with the name of the individual(s) or team you want attributed to your project. Hint: a commit history will provide valuable information to the judges about the work your team invested in developing your particular solution.
Guess what? If you've already forked this repository, then you've already submitted your project. On April 12, 2016, the judges will review all of the repositories listed here. If your repository is not listed, please let us know.
IMPORTANT: If you haven't already done so, make sure you've joined the Hack4Sac Slack Community
Hint: while optional, these tools will result in projects that help meet the needs of users and help the judges better understand the thinking behind your particular solution.
To use these tools, first replace GITHUB_ACCOUNT with the GitHub username or organization name to which you forked this repository so that the links correctly work.
This repo was created from http://hackshop.waffle.io. Use the Waffle board for this repo to always know what to do next for your hackshop project!
We’ve put together the right set of tools to help teams be productive in the shortest period of time. In addition to helping teams move fast, this tool set will allow transparency for optimized community engagement and easy continuation of the project following the event.
Hackshops apply lean principles to hackathons. By using the Hackshop format, hackathon teams can expect to learn:
- how to maximize resources in hyper-limited time constraints
- how to validate with customers before building the wrong thing
- how to document a brief, living, and lean business model
- how to continually test assumptions with rapid experimentation to deliver an MVP
Hackshops are still hackathons. The difference is the addition of the Hackshop framework for running in a lean way, to be as efficient as possible, focused on continuously experimenting and learning throughout the development process.
Hackathons traditionally center around building solutions, the most time-consuming and expensive part of the development lifecycle.
Individuals and teams show up to the event already knowing what they plan to build. Sometimes, problem statements are pre-defined, which is a step in the right direction -- but what if you're not passionate about the problem to be solved? Or what if you already have an amazing solution in mind?
Unfortunately, your amazing solution is probably not actually as amazing as you think. You may have even skipped identifying what the underlying problem is altogether. You could spend 24 hours coding a chat app for retired seniors only to find out that 10% of them use smart phones.
Hackshops focus on problems and customers first. What problem are you solving and for who are you solving it? Can you make a compelling promise to that customer that you can deliver a solution that meets their needs? Before we even talk about solutions, we focus on the customer, problem, and promise, first.
We've learned that when starting with a problem or an idea, the more we can be wrong, faster, the more we can get to a solution worth building. This approach sounds backwards, because your solution is so obviously brilliant, right? Unfortunately, probably not. Solutions that go from idea to launch without any attempt to validate or invalidate the underlying problem with a customer segment and if your solution fits their needs are rarely successful.
The Hackshop format leaves the traditional hackathon's solution-centric format behind. Hackshops focus on customers, problems, and promises first, and advocate moving quickly using succinct timeboxes to get from idea to MVP as quickly as possible. Throughout the event, teams work to prove their own assumptions wrong on their path to a viable solution.
- problem-centric approach (no solutions for the first 1/4 of the event)
- use of a lean business canvas as central to process
- customer validation before building
- rapid prototyping and experimentation
- use of continuous feedback loop (frame/build/measure/learn)
- An electronic or paper version of a lean business canvas
- GitHub, for collaboration on code and issues
- hackshop.waffle.io, a pre-built project template for managing issues in GitHub using a lean workflow
- Slack, for remote and ongoing communications (optional)
- solving problems that aren't painful or impactful
- building the wrong thing for the wrong customer
- post-hackathon death due to lack of focus or centralization of team/data