Are you interested in contributing to one of Code for Greensboro's projects? Great! Here is an overview of how to get started.
I have a great idea for a project...
Slow down there! One of the great things about Code for America is that there are many brigades that share their projects online, open-source and for free. Every community is unique, but before reinventing the wheel ask yourself "Has another brigade tried to solve this problem?"
If so, has anyone else already built what you need? Great! Then all you need to do is fork your own copy of the project repository (repo for short) and add in any data relevant to Greensboro and your application. Congratulations, you've solved a problem for our community and saved yourself a lot of time and effort in the process.
Then again, maybe another brigade kind of did what you set out to do, or maybe the app they created was a good start, but you can think of a number of ways to build on it. Good news, with your forked copy you now have your own version to build and tinker with to your heart's content.
That said, you probably don't have all the time in the world to contribute to an open-source project. Whether it's family, a job, a college education, or just the latest show on Netflix your life is probably busy already. To build and maintain an open-source project on one's own can be time consuming and a lot of responsibility. Plus, as things progress you may want to implement features you don't have the technical background for. Fortunately...
Many hands make light work
One of the great things about working with a Code for America brigade is that many of the attendees come from a diverse set of backgrounds, and have a varied set of skills. They can be back-end developers, designers, marketers, civic activists, photographers, system administrators, data analysts, and much more. Brigade projects are worked on collaboratively, either at a hacknight or remotely through our Slack community and our GitHub organization.
In the same vein, it's not enough to simply assume we understand the needs of, and have the answers to all of Greensboro's problems. It's great that we can make apps that are open-source and free to use, but if no one in the wider community needs what we provide, we'll have wasted a lot of time and effort.
That's why when starting a new project, it's important to establish a Community Stakeholder from outside of the brigade to make sure what we're building is truly going to be useful to the people in Greensboro effected by the problem.
This person could be a non-profit employee, someone who works for local government, a subject matter expert, or a local resident who is doing volunteer work around issues relevant to the project. The important thing is that the Community Stakeholder understands the core goals of the project, and can think about the needs of the end-user. The Community Stakeholder is there to keep the dev team grounded and the project on-track with it's core purpose (more on this in a future post).
Remember build with, not for.
Gathering the team
So you have your idea, and you've talked with the stakeholder(s) involved in the project, but there is still a lot of work to be done. Surely now it's time for you and a few friends to put the nose to the grindstone and start coding right? By knowing what needs to be done, what the community wants, and having the technical skills to implement the solution surely the project will build itself.
Believe it or not, we've already tried this approach and it left us with a variety of meandering projects and little measurable success. The reality of working in a volunteer organization is that people's time is limited. Folks will move, get new jobs, or maybe just lose interest. It happens. To make sure a project is seen through until completion we've established several key roles for any project taken on by the brigade. You've already heard about the Community Stakeholder, but there's also...
The Project Champion
This person is the project's biggest fan. Maybe they had the initial idea, maybe they talk about it constantly, perhaps they dream about it at night. The chief role of this person is to be the "face" of the project and recruit others to work on it. They are also the chief point of contact for the Community Stakeholder and is responsible for keeping them up to date on what's happening with development. They're most likely going to be the person to onboard new contributors and build a sense of community around existing volunteers. Expect to see this person at hacknight giving updates and answering questions from the group.
The Project Maintainer oversees all the development details of the project. This could be doing code review, managing documentation, overseeing code commits, and any other practical detail of development for the project. Their job is to handle the technical details of the project and make sure things get done. Most days, they'll be found idling in the project's slack channel or making changes in the GitHub repo.
Of course no project can get done by management alone. We need volunteers to do the work of coding, designing, data wrangling, content creation, and anything else to make sure that the project is a success.
Unlike the other three roles discussed, the time and involvement for this position is more flexible. It could be one day that you just see an issue on GitHub that needs work, create a solution, submit a pull request, and that's about the end of your involvement. You could also be up all hours of the night building the core functions of the project, debugging, or writing documentation. How much you put in is entirely up to you.
Tools of the Trade
AKA our "tool chain". These are the main tools we use to build our projects. These are subject to change over time and as our development ecosystem evolves, but for the moment three main tools we'll be using are:
GitHub is where the source code and a record of changes and updates for the projects are stored. Everything you need to get up to speed can be found here. Issues that need to be worked on, tasks and todos under the Projects tab, discussion between other contributors, and any documentation that can help you get your bearings. Additionally, you can figure out who the project lead is, and core contributors are by reading the commit history.
Slack is our main tool for communicating outside of meetings. It is a group chat software that deeply integrates with a variety of services, and can be run in a browser, a desktop client, or as a mobile app.
In addition to announcements about upcoming meetups and interesting links, this is the central place for the project team to communicate both privately and publicly, as well as host files and documents relevant to the project. Click here to get connected to the community.
Most likely, you won't have to deal with heroku directly when working on brigade projects, but this is the cloud service where everything is currently hosted.
Alright, I have my team, I know the tools, what are the actual rules for contributing code?
Well shucks, you caught us. Remember how I alluded to our previous lack of development methodology? Well, all this stuff about the framework you just read is still being tested out.
Right now we are working on the NC Offender Reentry Resources Hub with Code for Asheville as a sort of "test project" to see what parts of the framework still need to be tweaked. As the Reentry project moves forward, we'll add information to this page on the proper way to contribute code, the process for which pull requests get approved, and so forth.
Of course, if you have ideas or just want to jump in don't hesitate to contact us and we'll plug you into the project directly.
Otherwise, happy hacking and stay tuned to this page as our process refines.