Before contributing, please read our code of conduct.
This is an overview of our process for contributions, but we have more information at cityscrapers.org.
We mostly communicate in GitHub issues and pull requests, but sometimes longer conversations or troubleshooting questions are better suited for our Slack. Request an invite to our Slack with this link.
You can also reach out to us over email at email@example.com.
We want this project to be accessible to newcomers to open source and Python in general. Here are some steps for getting started contributing, but if anything isn't clear feel free to reach out on our Slack, ask a question in a GitHub issue or email us at firstname.lastname@example.org.
1. Find an open issue to work on
You can find open issues by using the "help wanted" label. Issues that are good for new contributors are labeled "good first issue", and issues that are currently being worked on by someone are labeled "claimed".
Once you've found an issue that interests you, check out the site and see if the links are still active and it seems doable to you. If everything looks good, comment on the issue that you're interested, and we'll mark it "claimed" so that others know you're working on it. We try to limit contributors to working on one issue at a time.
We ask that you let us know if you are no longer able to work on an issue so that others can have a chance. Any issue that doesn't have activity for 30 days after being claimed may be reassigned. If an issue labeled "claimed" doesn't have any activity in a month or so, you can comment and ask if it's available.
Notice something that's not working as expected or see a site that we should be scraping? Open an issue to let us know!
Interested in contributing to City Scrapers projects but you don't see issues that interest you in this repo? Check out the
city-scrapers GitHub topic for other City Scrapers projects.
2. Make changes
We use the GitHub flow for development where contributors fork their own copy of the code, create a new branch in git, make changes and then a pull request for those changes to be merged. More info on this process in the development documentation.
Once you've been assigned to work on an issue, check out our development documentation for more info on how set up your local environment and write a scraper.
3. Open a pull request
In this project, making a pull request is a just way to start a conversation about a piece of code. Whether you're finished with your changes or looking for some feedback, open up a pull request.
We have a pull request template that includes a checklist of things to do before a pull request is done. Fill that out as much as you can (don't worry if you can't check everything off at first) when you open the pull request.
We use GitHub Actions for running checks on code to make review easier. This includes everything from running automated tests of functionality to making sure there's consistent code style. When you open a pull request, you'll see a list of checks below the comments. Passing checks are indicated by green checkmarks, and failing checks with red Xs. You can see outputs from each check by clicking the details link next to them.
We'll do our best to be responsive, but please reach out in Slack, email, etc. if you don't hear back after a week or so.