-
Notifications
You must be signed in to change notification settings - Fork 2
Adding READMEs to all directories #584
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: sk/joss-publication
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## sk/joss-publication #584 +/- ##
=======================================================
+ Coverage 85.50% 87.61% +2.11%
=======================================================
Files 72 76 +4
Lines 3235 3505 +270
=======================================================
+ Hits 2766 3071 +305
+ Misses 469 434 -35 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Note: I have only made changes to README files, but I have imported changing from the main branch so a lot of files appear to have changed |
|
Would you mind if I rewrote this branch history just so that we don't get the changes coming up in the review? |
tomaroberts
left a comment
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.
Hi @skeating – thanks for this. Various comments scattered throughout the review – some of them are just general thoughts. I do think the front page README needs an overhaul as a priority, and as I was reviewing the PR I was thinking the documentation should be in something like ReadTheDocs, but obviously that's a fair amount of work.
A couple of questions:
- Is there a requirement from JOSS to have a README in every directory?
- How did you generate all of the README files and the HTML and Markdown at the bottom of the files?
- Do future developers need to update the READMEs manually according to any changes they make?
|
|
||
| Save the credentials in `.secrets.env` and a LastPass `Hasher API <environment> secrets` note. | ||
|
|
||
| SK QUESTION: is the reference to Last Pass something that is specific to us or is it a dependency somebody else would need. actually I assume the whole Azure thing is rather how we have chosen to do that rather than a necessity for somebody i.e. they might use a different system for storing their hashes |
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.
@stefpiatek – see "SK QUESTION" text.
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 specific to us and how we share passwords in the team, as long as they have their own azure tenancy then they should be fine to manage this with the code as-is
| ## Notes | ||
|
|
||
| - The height/weight/GCS value is extracted only within a 24 h time window | ||
| - The height/weight/GCS value is extracted only within a 24 h time window <SK: I assume this refers to what can come out of OMOP > |
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.
Agree – this either needs a fuller explanation or deleting.
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.
Yeah this is outdated and should be removed
| instances are retrieved. If the study does not exist locally, the entire study is retrieved from the archive. | ||
|
|
||
| Once the study and all its instances are in `orthanc-raw`, the study is sent to `orthanc-anon` via a C-STORE | ||
| Once the study and all its instances are in `orthanc-raw`, the study is sent to `orthanc-anon` via a C-STORE <SK: Please explain what C-STORE operation> |
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.
Suggest specifically calling it a "DICOM C-STORE" operation and linking to some documentation. Could link to the official NEMA DICOM docs, but they are a bit impenetrable, hence link I chose.
| Once the study and all its instances are in `orthanc-raw`, the study is sent to `orthanc-anon` via a C-STORE <SK: Please explain what C-STORE operation> | |
| Once the study and all its instances are in `orthanc-raw`, the study is sent to `orthanc-anon` via a [DICOM C-STORE operation](https://www.medicalconnections.co.uk/kb/Basic-DICOM-Operations). |
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.
Yeah this looks good
Co-authored-by: Tom Roberts <tom.roberts@ucl.ac.uk>
stefpiatek
left a comment
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.
Sorry this had sat on my list for ages. Still not quite sure about the benefit of a readme listing the files for every directory but maybe we can chat about what we're aiming for with it
| @@ -0,0 +1,10 @@ | |||
| ## 'ISSUE_TEMPLATE' Directory Contents | |||
|
|
|||
| ### Files | |||
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'm not too sure about having each of the files listed for each README, feels like something that will get out of date very quickly but having a readme for the point of it and perhaps highlighting key files?
Might be worth chatting about it?
| @@ -0,0 +1,16 @@ | |||
| A directory that contains the files used for linting. | |||
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.
| A directory that contains the files used for linting. | |
| Custom linting |
|
|
||
| Save the credentials in `.secrets.env` and a LastPass `Hasher API <environment> secrets` note. | ||
|
|
||
| SK QUESTION: is the reference to Last Pass something that is specific to us or is it a dependency somebody else would need. actually I assume the whole Azure thing is rather how we have chosen to do that rather than a necessity for somebody i.e. they might use a different system for storing their hashes |
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 specific to us and how we share passwords in the team, as long as they have their own azure tenancy then they should be fine to manage this with the code as-is
|
|
||
| The `project_config` module provides the functionality to handle | ||
| [project configurations](../README.md#configure-a-new-project). | ||
| [project configurations](../README.md#configure-a-new-project). <== SK comment I'm not sure this goes to exactly the right place OR the name in the # is misleading |
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.
Yeah agreed, this should point to the configs readme
| [project configurations](../README.md#configure-a-new-project). <== SK comment I'm not sure this goes to exactly the right place OR the name in the # is misleading | |
| [project configurations](projects/configs/README.md) |
| for the appropriate tag scheme using [Kitware Dicom Anonymizer](https://github.com/KitwareMedical/dicom-anonymizer) | ||
| and deletes any tags not mentioned in the tag scheme. The dataset is updated in place. | ||
| - Will throw a `PixlSkipInstanceError` for any series based on the project config file. Specifically, an error | ||
| - Will throw a `PixlSkipInstanceError` for any series based on the project config file. {SK: this sentence doesn't quite make sense to me} Specifically, an error |
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.
| - Will throw a `PixlSkipInstanceError` for any series based on the project config file. {SK: this sentence doesn't quite make sense to me} Specifically, an error | |
| - Will throw a `PixlSkipInstanceError` for any series that should be skipped (based on the project config file). Specifically, an error |
| If a `manufacturer_overrides` is defined, it will be used to override the `base` tags, if the | ||
| manufacturer of the DICOM file matches the manufacturer in the `manufacturer_overrides`. Any tags | ||
| in the `manufacturer_overrides` that are not in the `base` will be added to the scheme as well. | ||
| [SK: Between this and the previous read me I'm not sure this is totally clear, is it possible to have a full example of the yml file linked so that base and a manufacturer_overrides make a bit more sense ] |
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.
Yeah I think we should just have a readme in the projects/configs directory that talks through all the configuration options. There is a template here https://github.com/SAFEHR-data/PIXL/blob/main/template_config.yaml, perhaps we move this to the projects/configs directory?
| to its destination (eg. FTPS). It also uploads DICOM data to its destination after it has been | ||
| processed by the Imaging API and orthanc(s). | ||
| It no longer accepts messages from rabbitmq. | ||
| It no longer accepts messages from rabbitmq. <SK: Please explain> |
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.
Yeah agreed, this is a historical change
| ## Notes | ||
|
|
||
| - The height/weight/GCS value is extracted only within a 24 h time window | ||
| - The height/weight/GCS value is extracted only within a 24 h time window <SK: I assume this refers to what can come out of OMOP > |
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.
Yeah this is outdated and should be removed
| instances are retrieved. If the study does not exist locally, the entire study is retrieved from the archive. | ||
|
|
||
| Once the study and all its instances are in `orthanc-raw`, the study is sent to `orthanc-anon` via a C-STORE | ||
| Once the study and all its instances are in `orthanc-raw`, the study is sent to `orthanc-anon` via a C-STORE <SK: Please explain what C-STORE operation> |
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.
Yeah this looks good
| ### Scripts | ||
|
|
||
| `./scripts` contains bash and Python scripts to check the individual components of the system test. | ||
| `../scripts` contains bash and Python scripts to check the individual components of the system test. |
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 can actually be deleted as I think it referred to test scripts that no longer exist
Description
Adds a README to all directories to facilitate easier navigation of the tree
Also adds comments where existing README did not make sense/was confusing
Corrected a few areas that were slightly confusing to read
Note changes to files other than README are from merging the main branch back into this one
Type of change
Please delete options accordingly to the description.
Suggested Checklist
mainbranch.squash and merge