Identified a problem in your community?
Maybe Code for Boston can help and we can address that problem together. Please read through our few ground-rules for new projects before you submit your idea.
How we take on new projects
- We prefer submissions in the form of problem statements. A good rule to start with is to phrase your idea in the form of:
"How might we (thing you want to change here)".For example: "How might we better enable citizens to be knowledgable about local policical issues" we consider a good problem statement, but "Let's build an iOS app to track how people use parks in our community." we consider to be a poor problem statement. The reason behind this, is that we want to avoid starting from a point where we have already made many assumptions about the project. Who knows if an iOS app is the best choice, and what problem are you trying to address by tracking people's opinions?
If you already know what you want and you just need it built, we're not the group for you - we do not do "spec work" by any means.
- The project must be open-source for its entire lifetime. If this is code, it means freely available on github. If it isn't code, this means that the progress and deliverable 'thing' is openly available in some other accessible way.
- The project must solve a real civic need (while there are plenty of good ideas out there, we limit ourselves to civic tech related, social good projects). We realize this is a somewhat fuzzy distinction, which is why we always will have you discuss your problem statement/idea with Code for Boston core team members before we commit to anything.
- Due to our tie to Code for America, and the diverse group of our members, we may not be able to take on projects that are political in nature. Projects focused around things like open-data and transparency are fair game, but projects to support a partisan political effort are 'iffy' at best. (i.e transparency tool for campaign finance is good, website promoting a candidate is a no-go).