-
Notifications
You must be signed in to change notification settings - Fork 6
Improve numerical readability scores of our README #590
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?
Conversation
| [discussions](https://github.com/UCL-ARC/python-tooling/discussions) for this | ||
| repo, and we welcome questions there or in the `#helpme` channel on the | ||
| [UCL research programming hub Slack](https://www.ucl.ac.uk/advanced-research-computing/community/ucl-research-programming-hub). | ||
| This repository collects our recommendations for a research software project in Python. |
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 got rid of [UCL ARC] because our name is already in the title up on line 4, and in the repo header in GitHub's UI.
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.
Pull Request Overview
This PR improves the numerical readability scores of the README by simplifying language and restructuring content. The changes aim to make the documentation more accessible while maintaining all essential information.
Key changes:
- Simplified language and shortened sentences throughout the README
- Restructured sections with clearer headings and better organization
- Added a dedicated "Need help?" section for support information
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
I highly doubt it. We could do it in our own way fairly easily, but |
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.
Some thoughts
Overruled by Vale and @paddyroddy. Co-authored-by: Copilot <[email protected]>
Co-authored-by: Patrick J. Roddy <[email protected]>
|
Cheers, Paddy! I've re-requested a review from @UCL-ARC/collaborations-python-tooling to get a second. @matt-graham and @dstansby, you both wrote earlier versions of this, so your opinions are gratefully received. (If you have the capacity to review...) |
| repo, and we welcome questions there or in the `#helpme` channel on the | ||
| [UCL research programming hub Slack](https://www.ucl.ac.uk/advanced-research-computing/community/ucl-research-programming-hub). | ||
| This repository collects our recommendations for a research software project in Python. | ||
| We have a [website] if you need some advice, and a template if you're starting from scratch. |
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.
This is vague, advice for what? And starting what from stratch?
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.
advice for what?
Python tooling?
And starting what from stratch?
a research software project in Python. (the subject of the preceding sentence, pretty sure that's legal)
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.
This repository collects our recommendations for a research software project in Python. # Unchanged
We have a [website] if you need some advice for what tools to use, and a template if you're starting a project from scratch.
This feels redundant (to me) but does improve the three remaining readability scores slightly. Is that OK?
|
|
||
| 🍪 Our template is a [cookiecutter] template which automatically creates new | ||
| Python packages with our recommended tooling set up and ready to go. | ||
| 🍪 Our template uses [cookiecutter] to set up a new package with our preferred tools ready to go. |
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.
| 🍪 Our template uses [cookiecutter] to set up a new package with our preferred tools ready to go. | |
| 🍪 Our template uses the [cookiecutter] tool to set up a new package with our preferred tools ready to go. |
| > If you're making a package within a community that has an existing | ||
| > package template (e.g., [`SciKit-Surgery`](https://github.com/SciKit-Surgery/PythonTemplate)), | ||
| > we recommend using their template instead of this one. | ||
| > If you're making a package in a research community that already has a template, use theirs instead! |
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 it's worth keeping an example here of a community that uses a specific/different template.
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.
This was a deliberate change.
The parentheses and abbreviation (e.g.) decrease readability. And I wasn't too enthusiastic about the specific example.
|
|
||
| Some quick instructions for using our template are below. | ||
| We also have a longer [tutorial](./tutorial.md) that has been presented in workshops for researchers at UCL. | ||
| If you're comfortable with the command line, here are some quick start steps. |
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.
What if you're not comfortable with using the command line?
| If you're comfortable with the command line, here are some quick start steps. | |
| Here are some quick start steps. We assume you're already familiar with using the command line. |
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.
Lol. Good point.
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.
Your suggestion reduces readability (although I agree that it's good). If we drop the second sentence, the scires are much better:
Here are some quick start steps.
That works, right?
| It will have created a directory for your project: | ||
|
|
||
| ```sh | ||
| ls -ltr | tail -n1 # Show the last directory that was created |
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 find the number of non-exapanded flags in this command a bit overwhelming (but appreciate it's a hangover from before this PR, so doesn't need to be improved here)
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.
It looks like:
ls -lt --reverse | tail --lines=1
(-l and -t don't have expansions)
Is that better?
| - change directory to your project directory, | ||
| - initialise a `git` repository, | ||
| - and _install_ your new package editable mode. |
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.
Should this be an ordered (numbered) list, since it has to be done in the specific listed order?
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.
| - change directory to your project directory, | |
| - initialise a `git` repository, | |
| - and _install_ your new package editable mode. | |
| 1. change directory to your project directory, | |
| 2. initialise a `git` repository, | |
| 3. and _install_ your new package editable mode. |
Following on from #546, I've reworded our README, using vale's Readability suite.
I don't think there's a nice way to get vale to make a comparison of values between two commits (@paddyroddy?), so here's a manual comparison table (which I hope is helpful, because it was very boring to make!)
You can check these yourself with:
cd /place/where/this/repo/is vale sync vale README.md