-
-
Notifications
You must be signed in to change notification settings - Fork 26
Home
Before you start, be sure to keep a pen/paper handy. Write down any questions; at the end, we'll help you through them if you don't get the answer on the way.
This project is part of Code For Boston which is a volunteer organization focused on helping deliver technical projects that are sponsored by states/cities/municipalities.
Jobhopper is a project designed to provide a web-based interactive tool to leverage privately generated job transition data (hence jobhopper) with data from public sites like O*Net and U.S. Bureau of Labor Statistics to provide information to help policy makers make programming and planning decisions. Two doctoral students and staff from the City of Somerville job development office initiated this project with Code for Boston and provided both the private data and set up interviews with professionals representing the four different personas being used to develop the criteria for the project. More details on the data are available in the README.md file
Our primary tools for this project (and Code For Boston generally) are GitHub and Slack. Once you have joined the project, you'll be added to a specific channel for the project. You'll need to create a github and slack account. Once you've done that, please post that information to Jed Pittman or Annie LaCorte so we can keep github project kanban boards updated.
Git is a source control system where we store code to keep it safe, to make sure we know how the code changed over time, and are able to automate actions with the code like combining different versions of files.
If you are not sure what git is, you should learn about git before going forward.
It goes without saying everyone should follow the Code For Boston Code of Conduct. Beyond that, this is an opportunity to learn and contribute whatever you can.
- Participants who want to stay involved should plan to spend 10 hours per month on the project.
- If you cannot make a Tuesday night session (730pm-930pm) that is fine as long as you're working your issue, just let folks know in slack in advance.
- Fork the main repository (see below for details)
- Clone it locally
- Read the README.md file at the top level and the data/README.md
- Read the rest of this wiki
- Review the slack channel
- Try to get the project setup and database setup locally on your machine using the README.md files.
We track our issues on the current sprint's project board. The Current Sprint Board has columns to show progress. As you work on the issue, move the issue into the correct column. (Some folks don't have permissions to move issues between columns due to the structuring of github's permissions -- so when these docs say to do that, just update the issue in comments and/or update the title of the issue and once we see the change, we'll move it for you.)
- ToDo - Items in the sprint that are scheduled to be done.
- InProgress - Items in the sprint that are being worked on actively.
- InTesting - Code changes that require testing/validation prior to being merged. Coding is done, testing is in progress.
- Done - Any issue that is worked on and finished OR closed because needs change.
Try to only have one issue at a time and take issues that have downstream items that depend on them only if you can turn them around fairly fast. Any issue that gets no activity may be reassigned.
Once you're done with an issue (or as far as you can take it), you should feel free to grab an issue from the top (or near top) of the todo list that you think you can do with minimal help.
If you think an issue is not clear, please leave a comment and do a mention to Jed or the creator and we'll try to make it clear.
If you're stuck on an issue, reach out to other teammates if you think they can help using slack or comments. If you cannot get help for a period of time (1-2 days), then feel free to make a comment that the issue is blocked (with the reason). You can then put it back at the top of the todo column until it becomes unblocked. This will allow someone else to take it. Then you can take another item from the list. If any decisions/information is developed, add/update documentation so the entire team has it available.
We're generally trying to make sure that all items are done at the end of the sprint, and most that have been taken are done at the end of Tuesday night each week. To that end, keep issues small (1-2 hours of work). If needed, add an item to the ticket that says "enter issue(s) to continue x". That is perfectly fine. If you think the ticket warrants a large issue, that is fine, but mark that as (BIG) in the title. As we groom each week, we'll get better at this.
If you think an issue is too big/hard/you cannot complete it, just write a comment in the issue and put it back in the todo list at the top. This should be rare. Only take an issue if you feel pretty confident you can do it yourself.
You should be familiar with Git Commands prior to doing this work.
- Make sure you're logged in to GitHub.
- Go to jobhopper here: https://github.com/codeforboston/jobhopper
- In the upper right hand corner, click the fork button to create a fork.
- Use git to clone a copy of the forked repo.
- Make a new local branch to fix the issue. Recommended naming is ISS-# where # is the issue id for the code you're changing.
- Make your changes on your local copy.
- Test as much as possible locally.
- When satisfied, do another pull from upstream to be sure nothing has changed prior to your finishing your work. Resolve any issues locally and rerun your automated testing.
- Commit and push your code up to your forked copy (in github, this is the version of the code with your name e.g. https://github.com/yourusername/jobhopper)
- File a pull request (PR) from your copy to the develop branch. Include your testing output and a summary of your changes including anything extra.
- Make a note in your ticket that the issue is ready for review.
- A member of the team will review your code, make comments etc as needed/approve the code if it looks good.
- Once there's code that is approved, a team member will merge it into the develop branch.
When you are doing a code review, check for the following:
- The code change is linked to an issue in the current sprint.
- You're sure that the code either addresses all of the requirements in the issue OR some, and an explanation (perhaps a follow up issue) is created; we want to be sure nothing gets lost.
- You see that there is proof (or explanation) that the code has been tested. For UI, the jest testing output. For Django, the test output.
- You understand/agree with the code changes. If there's something you don't understand, look it up or ask the contributor. This is a chance to learn. Once you're ok with the change, make a comment to that effect.
- If you have permissions, merge the code into develop and close the related issue and bring to done column on the sprint board. (Otherwise, someone will see your comment and do that for you.)
- NOTE: if there are ongoing discussions on a pull request, do not merge until there is agreement.
Ideally once per sprint, a member of the team will "build" a full release of the code for the version in question,
- Get the latest code for the version in question
- Run all tests (automated and manual) and ensure they all pass, if not, work with team to fix issues
- Merge the code into master once final
- Create a new version numbered branch off of master
Having the following tools at your disposal should make you able to contribute more on the project. Git, VI (or some form of text editor), VSCode, Linux Shell Commands
Python, Javascript, SQL
Django, React, Pandas, D3