Culture > How to get your project rolling at Progressive HackNight

Published on Jul 5, 2017 by La Vesha Parker

How to get your project rolling at Progressive HackNight

Progressive HackNight exists to make great ideas happen.
Progressive HackNight exists to make great ideas happen

Progressive HackNight exists to make great ideas happen. Sometimes, we see some great ideas proposed at the start of the hacknight, but not many people work on them or stay involved after the night. This can be caused by a multitude of things, but we can reduce the chance of it happening by taking a look at how you can best set yourself up for success, no matter what stage your project is in.

We’ll start with a few basic suggestions that apply to all projects (regardless of what stage of ideation or development they’re in). We’ll later look at what changes you can make as your project develops to improve its effectiveness at the hacknight.

The basics of making your project fun and easy to contribute to

Make your project Open Source!

We absolutely ❤️ open source at Progressive HackNight, and it’s easier to contribute to, here and outside the community, as opposed to propriety software.

Know what problem needs to be solved

Have a vision of what you want to get out of the night. It will help you drive the work and conversation done towards that goal. Telling the hacknight attendees of this goal when pitching to the group will also help them understand the scope of the work they might do that night.

Understand your project well

It’s hard to contribute to a project if the representative of that project doesn’t know how it should work. That definitely isn’t meant to imply that only engineers should pitch projects–anyone should feel welcome to pitch, but it’s important to know the expected behavior of your project, and to know how contributors can get in touch with engineers/designers on your team if you can’t answer all of their questions. Having a regular contributor or two on standby to answer questions via email, Slack, or IRC will also get the ball rolling.

Have easily digestible tasks

Coming to a working group and saying “we need to do the frontend” will probably result in an unproductive night. Many of the folks who come to a hacknight are likely unfamiliar with your project, and won’t be able to dive in to fix a large-scale problem in 2.5 hours. Be sure to break this into small tasks first, like “update copy on sign up page”, or “Replace all generic button components with new custom Button components”. Bonus points for establishing yourself as a breakout group on the Progressive HackNight site and/or using GitHub issues to organize all of this!

If you do want to address a bigger issue, it might be worth bringing it to one of the discussion groups first to figure out how to break it up into manageable tasks first!

Have a clear guide to contributing

Staring at an open source project with no idea how to get started is never fun. Providing insight into the culture of the project and how to make changes is always helpful. Every small detail is useful:

  • How do I open a pull request? Who do I assign it to?
  • Where can I find issues/tasks meant for new contributors?
  • Do you use a particular branching model for git (i.e. GitFlow)?
  • Who do I contact with questions?
  • What software does this project rely on?
  • Is there a way to test my code/design before pushing to production?

Having this all explained in a README or google doc will make the lives of new contributors significantly easier.

Tell folks how to join your community after the hacknight

Our bi-weekly hacknight only lasts a few hours. There are some issues that can be solved in 1-2 hours, but others might take longer. Make sure the contributors know where to go for questions they might have as they wrap up their work into a pull request. Have an IRC channel, Google Group, or use Slack? Ask them if they’d like to join it to continue the conversation. Who knows, you might come out with a new cohort of contributors!

Consider starting with an installfest!

If you’re pitching an existing project, you probably have everything set up and running smoothly on your personal laptop. The people who want to contribute don’t have that yet, and sometimes setting up a project on your local machine is the most frustrating part of contributing! Take time to show them how to get set up. Better yet, have an installation guide they can check out ahead of time, so they can get a head start and come to you with questions!

How to advance your project through stages of development

Your project doesn’t have to be fully fleshed out or well-established to engage new contributors. Let’s take a look at what you can do to pique the interest of potential contributors, no matter what stage of development you’re in.

I have an idea for how to solve a problem, but it has yet to fully take shape

Whether you’re a designer, developer, project manager, or creative, the Pitch Zone working group is the best place for projects that are still in the ideation phase. It’s worth taking time to hammer out more details before starting a working group of your own, so your project will be perceived as being organized when you do eventually pitch for a working group. If you don’t know who is best to help you map out your project, explain what your goals are and then ask the community! We’re all more than happy to help.

Jot down a few notes on what you want to figure out in the night. We dedicate about 2.5 hours to working, so think through what you can do in that time.

Be sure to leave your contact info with participants, tell them how they might continue to contribute to your project, and feel free to open a channel in our Slack to discuss your project outside of the hack night.

I am a member of a project that’s started being developed with a few others

Before immediately involving others in feature requests, it’s worth taking time to work on documentation for your project. Sometimes, the eye of an unaffiliated developer/designer can really help with determining what still needs to be documented and how to document it. Consider making your working group focused on documentation to establish the rules of understanding and contributing to your project so you can return to the next hack night with a project that is easier to contribute to.

If you already have established documentation and it’s easy for a new contributor to ramp up, take a look at the next section to make your project welcoming to new designers and developers!

I am a member of an established project with multiple developers and documentation

If your project is already established and you want to open it up to new contributors, there are a few basic things contributors will need to know.

The basics

To get started on any project, developers and designers need to know:

  1. What needs to be done compared to the skillset they have to offer
  2. How to get set up to contribute
  3. How to add the work they’ve done to your project.
  4. How to communicate with other people working on the project.

The basics, explained

Have a set of 2-3 tasks you want to get finished that night.

These should be easily digestible, short tasks that don’t require deep knowledge of existing code (i.e. tests, small features, small UI/UX tweaks). Be sure to call out exactly which skills are needed for the tasks you want to address that night. Need a designer who is well-versed in accessibility standards or an engineer who knows React? Call that out when you pitch!

It’s best to set up a project as a breakout group on our site, and you can also have these tasks as issues in GitHub if you have your own repo. GitHub issues can also have labels–consider a “New Contributor” label to indicate that a task/issue is aimed at people curious about contributing to your project.

If the task at hand is more of a discussion, consider writing notes/takeaways from that discussion as a comment on the issue so for posterity, and come up with action items for a future hacknight

Lastly, we recommend ZenHub to keep track of where different issues are in your pipeline.

We recommend ZenHub to keep track of where a label is in the pipeline.

Have an easy onboarding setup.

Have a complicated development environment? Be prepared to help people install all necessary software and have an INSTALLING.md guide for installing everything. Not a developer? Have one on call for quick questions about getting set up.

Have a system in place for submitting Pull Requests (code reviews)

This system should be described in a CONTRIBUTING.md guide (or the like), so contributors can reference it later and you won’t have to field repeated questions. You should also have an engineer whose contact info you can provide for issues with contributing. We don’t want code to remain on a developer’s computer forever because it isn’t clear how to contribute.

Have information on how to talk with people working on the project

Does your team communicate using IRC, Slack, email, or an intricate system of Google Doc comments? Explain that. That info is nice to keep front and center in your project’s README.md.


That’s it! We can’t wait to see what ideas you bring to Progressive HackNight. Questions or suggestions? I’d love to hear them. Send them to me at vesha@proghacknight.com!


About the author


Vesha is a member of the ProgHacknight Steering Committee