-
-
Notifications
You must be signed in to change notification settings - Fork 128
Update README #1481
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Update README #1481
Conversation
quevon24
commented
Jul 4, 2025
- Moved dev-only stuff (like uv) into its own "Requirements (for Development)" section under Development.
- Made it clear that uv is only needed for development—not for using the library.
- Added a new "Environment Setup with uv" section with step-by-step setup, including how to install uv and activate the virtual environment. Also added install instructions for different OSes.
- Added a "Code Style & Linting" section to explain how to use ruff and pre-commit, plus how to run them manually or from your editor.
- Included install steps for Arch-based systems (not just Debian/macOS).
- Updated a few outdated links (like the one to the CourtListener scrape command).
Oh my. @elisa-a-v is going to have thoughts on this one. She's been looking at these docs too lately! |
That sounds great, I think this is the hardest thing I've ever done 😅, I like documentation, but I'm terrible at writing it |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for tagging! Happy to chip in :)
Overall I think the changes proposed improve the docs a lot, but I have a suggestion that I think will make them even more helpful.
Moved dev-only stuff (like uv) into its own "Requirements (for Development)" section under Development.
This is a great idea, and we should probably extend this sentiment to the rest of the README. If I understand correctly, the docs have two different target audiences:
- those using Juriscraper,
- and those contributing to Juriscraper.
Both groups are technically devs, therefore some information is relevant to both, but some is only intended for contributors. If this is correct, we probably want to make it even clearer which parts are contributor-specific and which ones are relevant to everyone, because right now it's a bit confusing to me at least.
To do this, I would suggest:
- Moving all development-only sections to a separate
CONTRIBUTING.md
file, and link to it from the README. - Then, reorganizing whatever is left in the README in a logical way.
Simply changing the order will make the docs way more useful for everyone by making them easier to navigate. Below you'll find a suggested new structure with some adjusted headings, let me know what you think.
Structure comparison
Current README
- What is this?
- Installation and dependencies
- Install dependencies
- Then install the code
- Finally, do your WebDriver
- Code Style and Linting
- Formatting guidelines
- Joining the project as a developer
- Development
- Requirements (for Development)
- Environment Setup with uv
- Network tests
sample_caller.py
- District Court Parser
- Tests
- Future Goals
- Deployment
- License
Suggested README
- What is this?
- Want to contribute? (-> link to
CONTRIBUTE.md
) - Getting started (formerly "Installation and dependencies")
- Install dependencies
- Then install Juriscraper (formerly "Then install the code")
- Finally, set up your WebDriver (formerly "Finally, do your WebDriver")
- How to scrape courts with Juriscraper (formerly "Usage")
- Sample driver (formerly "District Court Parser", not sure if this goes here or in
CONTRIBUTING.md
)
- Sample driver (formerly "District Court Parser", not sure if this goes here or in
- Future Goals
- License
Suggested CONTRIBUTING.md
- Guidelines to contribute to Juriscraper (formerly "Joining the project as a developer")
- Code Style and Linting (merged with "Formatting guidelines")
- Requirements (formerly "Requirements (for Developers)")
- Setting up your dev environment (formerly "Environment Setup with uv")
- Sample caller (formerly "
sample_caller.py
") - Tests
- Network tests
- Deployment
Finally, I'd be more than happy to talk about this further if you want, @quevon24. I enjoy writing docs and I think (and hope! xD) I'm not too bad at it, and as someone who would actually need the docs to do anything with Juriscraper, I think I would be able to provide more input if needed, so let me know and we can chat about it.
- If you manually make whitespace or formatting changes, do them in a **separate commit** from logic changes. | ||
- Avoid combining whitespace reformatting with functional changes, as it makes code review harder. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think these two bullet points are conveying the same idea?