Group 03: nameforme - Py

Submitting Author: Daniel Cairns (@DanielCairns), Eyre Hong (@eyrexh), Bruce Wu (@BruceUBC), Zilong Yi (@ZilongYi) All current maintainers: (Daniel Cairns (@DanielCairns), Eyre Hong (@eyrexh), Bruce Wu (@BruceUBC), Zilong Yi (@ZilongYi)) Package Name: nameforme One-Line Description of Package: A helper python package that can be used to generate names. This could be used to come up with baby names, character names, pseudonyms, etc. Repository Link: https://github.com/UBC-MDS/nameforme Version submitted: v1.1.0 Editor: Daniel Cairns (@DanielCairns), Eyre Hong (@eyrexh), Bruce Wu (@BruceUBC), Zilong Yi (@ZilongYi)
Reviewer: @ranjitprakash1986, @Althrun-sun, @netsgnut, @kellywujy Archive: TBD
Version accepted: TBD Date accepted (month/day/year): TBD

Description

A helper python package that can be used to generate names based on the dateset. This could be used to come up with baby names, character names, pseudonyms, etc.
Source Data: Contains baby names born in the United States for each year from 1880 to 2017, and the number of children of each sex given each name. Names must appear at least 5 times in each year to be included. (Source: http://www.ssa.gov/oact/babynames/limits.html)
This package is similar to the existing names package by Trey Hunner (last updated in 2014), however, our uses a more recent dataset (with names up to 2017), and more options for users to customize what type of names to generate, including the ability to generate similar sounding names.
You can check the online documentation of this package on readthedocs.

Scope

Please indicate which category or categories this package falls under:
- [x] Data retrieval
- [x] Data extraction
- [x] Data munging
- [ ] Data deposition
- [ ] Reproducibility
- [ ] Geospatial
- [x] Education
- [ ] Data visualization*

Please fill out a pre-submission inquiry before submitting a data visualization package. For more info, see notes on categories of our guidebook.

For all submissions, explain how the and why the package falls under the categories you indicated above. In your explanation, please address the following points (briefly, 1-2 sentences for each):
- Who is the target audience and what are scientific applications of this package?
- Are there other Python packages that accomplish the same thing? If so, how does yours differ?
- If you made a pre-submission enquiry, please paste the link to the corresponding issue, forum post, or other discussion, or @tag the editor you contacted:

Technical checks

For details about the pyOpenSci packaging requirements, see our packaging guide. Confirm each of the following by checking the box. This package:

[x] does not violate the Terms of Service of any service it interacts with.
[x] has an OSI approved license.
[x] contains a README with instructions for installing the development version.
[x] includes documentation with examples for all functions.
[x] contains a vignette with examples of its essential functions and uses.
[x] has a test suite.
[x] has continuous integration, such as Travis CI, AppVeyor, CircleCI, and/or others.

Publication options

[ ] Do you wish to automatically submit to the Journal of Open Source Software? If so:

JOSS Checks

- [ ] The package has an **obvious research application** according to JOSS's definition in their [submission requirements][JossSubmissionRequirements]. Be aware that completing the pyOpenSci review process **does not** guarantee acceptance to JOSS. Be sure to read their submission requirements (linked above) if you are interested in submitting to JOSS. - [ ] The package is not a "minor utility" as defined by JOSS's [submission requirements][JossSubmissionRequirements]: "Minor ‘utility’ packages, including ‘thin’ API clients, are not acceptable." pyOpenSci welcomes these packages under "Data Retrieval", but JOSS has slightly different criteria. - [ ] The package contains a `paper.md` matching [JOSS's requirements][JossPaperRequirements] with a high-level description in the package root or in `inst/`. - [ ] The package is deposited in a long-term repository with the DOI: *Note: Do not submit your package separately to JOSS*

Are you OK with Reviewers Submitting Issues and/or pull requests to your Repo Directly?

This option will allow reviewers to open smaller issues that can then be linked to PR's rather than submitting a more dense text based review. It will also allow you to demonstrate addressing the issue via PR links.

[x] Yes I am OK with reviewers submitting requested changes as issues to my repo. Reviewers will then link to the issues in their submitted review.

Code of conduct

[x] I agree to abide by pyOpenSci's Code of Conduct during the review process and in maintaining my package should it be accepted.

Please fill out our survey

[ ] Last but not least please fill out our pre-review survey. This helps us track submission and improve our peer review process. We will also ask our reviewers and editors to fill this out.

P.S. *Have feedback/comments about our review process? Leave a comment here

Editor and Review Templates

The editor template can be found here.

The review template can be found here.

Package Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

[x] As the reviewer I confirm that there are no conflicts of interest for me to review this work (If you are unsure whether you are in conflict, please speak to your editor before starting your review).

Documentation

The package includes all the following forms of documentation:

[x] A statement of need clearly stating problems the software is designed to solve and its target audience in README.
[x] Installation instructions: for the development version of the package and any non-standard dependencies in README.
[x] Vignette(s) demonstrating major functionality that runs successfully locally.
[x] Function Documentation: for all user-facing functions.
[x] Examples for all user-facing functions.
[x] Community guidelines including contribution guidelines in the README or CONTRIBUTING.
[x] Metadata including author(s), author e-mail(s), a url, and any other relevant metadata e.g., in a pyproject.toml file or elsewhere.

Readme file requirements The package meets the readme requirements below:

[x] Package has a README.md file in the root directory.

The README should include, from top to bottom:

[x] The package name
[x] Badges for:
- [x] Continuous integration and test coverage,
- [x] Docs building (if you have a documentation website),
- [ ] A repostatus.org badge,
- [ ] Python versions supported,
- [x] Current package version (on PyPI / Conda).

NOTE: If the README has many more badges, you might want to consider using a table for badges: see this example. Such a table should be more wide than high. (Note that the a badge for pyOpenSci peer-review will be provided upon acceptance.)

[x] Short description of package goals.
[x] Package installation instructions
[ ] Any additional setup required to use the package (authentication tokens, etc.)
[x] Descriptive links to all vignettes. If the package is small, there may only be a need for one vignette which could be placed in the README.md file.
- [x] Brief demonstration of package usage (as it makes sense - links to vignettes could also suffice here if package description is clear)
[x] Link to your documentation website.
[x] If applicable, how the package compares to other similar packages and/or how it relates to other packages in the scientific ecosystem.
[x] Citation information

Usability

Reviewers are encouraged to submit suggestions (or pull requests) that will improve the usability of the package as a whole. Package structure should follow general community best-practices. In general please consider whether:

[x] Package documentation is clear and easy to find and use.
[x] The need for the package is clear
[x] All functions have documentation and associated examples for use
[x] The package is easy to install

Functionality

[x] Installation: Installation succeeds as documented.
[x] Functionality: Any functional claims of the software been confirmed.
[ ] Performance: Any performance claims of the software been confirmed.
[x] Automated tests: Tests cover essential functions of the package and a reasonable range of inputs and conditions. All tests pass on the local machine.
[x] Continuous Integration: Has continuous integration setup (We suggest using Github actions but any CI platform is acceptable for review)
[x] Packaging guidelines: The package conforms to the pyOpenSci packaging guidelines. A few notable highlights to look at:
- [x] Package supports modern versions of Python and not End of life versions.
- [x] Code format is standard throughout package and follows PEP 8 guidelines (CI tests for linting pass)

For packages also submitting to JOSS

[ ] The package has an obvious research application according to JOSS's definition in their submission requirements.

Note: Be sure to check this carefully, as JOSS's submission requirements and scope differ from pyOpenSci's in terms of what types of packages are accepted.

The package contains a paper.md matching JOSS's requirements with:

[ ] A short summary describing the high-level functionality of the software
[ ] Authors: A list of authors with their affiliations
[ ] A statement of need clearly stating problems the software is designed to solve and its target audience.
[ ] References: With DOIs for all those that have one (e.g. papers, datasets, software).

Final approval (post-review)

[ ] The author has responded to my review and made changes to my satisfaction. I recommend approving this package.

Estimated hours spent reviewing: 1

Review Comments

All functions are working without error. The parameters are well-design. The only place that I need to do some exploartion myself to understand the usage is that find_old_name() function is able to handle sex as a input according to the usage description, but the example given does not demonstrate how to use this filtering parameter. I found the sex= parameter in VScode’s function documentation hints, but it would be more user-friendly to explicitly demonstrate the usage of sex= parameter in the usage description.
For the sex parameter, inputting f or m does not work for find_old_name() since it does not match the case of “F” and “M”. I suggest to make this case-insensitive so that it is consistent with find_name() function.
In find_unisex_name() function, i suggest to add more description of the bar= parameter’s mechanism. It was a bit tricky to understand what that means and how it influences the output without a detailed description. The restricted range of bar value (0 to 1) could have been mentioned too.
Would it be possible to print out more than 10 names at a time? Or simply a lookup function that shows all names matching the user's expected criteria?
In general I found the documentation could be more elaborated to fully demonstrate how versatile this package could be.

Very practical and interesting package! The GitHub repo is well organized and followed best practices. Great work team!

Package Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

[x] As the reviewer I confirm that there are no conflicts of interest for me to review this work (If you are unsure whether you are in conflict, please speak to your editor before starting your review).

Documentation

The package includes all the following forms of documentation:

[x] A statement of need clearly stating problems the software is designed to solve and its target audience in README.
[x] Installation instructions: for the development version of the package and any non-standard dependencies in README.
[x] Vignette(s) demonstrating major functionality that runs successfully locally.
[x] Function Documentation: for all user-facing functions.
[x] Examples for all user-facing functions.
[x] Community guidelines including contribution guidelines in the README or CONTRIBUTING.
[x] Metadata including author(s), author e-mail(s), a url, and any other relevant metadata e.g., in a pyproject.toml file or elsewhere.

Readme file requirements The package meets the readme requirements below:

[x] Package has a README.md file in the root directory.

The README should include, from top to bottom:

[x] The package name
[x] Badges for:
- [x] Continuous integration and test coverage,
- [x] Docs building (if you have a documentation website),
- [x] A repostatus.org badge,
- [ ] Python versions supported,
- [x] Current package version (on PyPI / Conda).

[x] Short description of package goals.
[x] Package installation instructions
[ ] Any additional setup required to use the package (authentication tokens, etc.)
[x] Descriptive links to all vignettes. If the package is small, there may only be a need for one vignette which could be placed in the README.md file.
- [x] Brief demonstration of package usage (as it makes sense - links to vignettes could also suffice here if package description is clear)
[x] Link to your documentation website.
[x] If applicable, how the package compares to other similar packages and/or how it relates to other packages in the scientific ecosystem.
[x] Citation information

Usability

[x] Package documentation is clear and easy to find and use.
[x] The need for the package is clear
[x] All functions have documentation and associated examples for use
[x] The package is easy to install

Functionality

[x] Installation: Installation succeeds as documented.
[x] Functionality: Any functional claims of the software been confirmed.
[x] Performance: Any performance claims of the software been confirmed.
[x] Automated tests: Tests cover essential functions of the package and a reasonable range of inputs and conditions. All tests pass on the local machine.
[x] Continuous Integration: Has continuous integration setup (We suggest using Github actions but any CI platform is acceptable for review)
[x] Packaging guidelines: The package conforms to the pyOpenSci packaging guidelines. A few notable highlights to look at:
- [ ] Package supports modern versions of Python and not End of life versions.
- [x] Code format is standard throughout package and follows PEP 8 guidelines (CI tests for linting pass)

For packages also submitting to JOSS

[ ] The package has an obvious research application according to JOSS's definition in their submission requirements.

Note: Be sure to check this carefully, as JOSS's submission requirements and scope differ from pyOpenSci's in terms of what types of packages are accepted.

The package contains a paper.md matching JOSS's requirements with:

[ ] A short summary describing the high-level functionality of the software
[ ] Authors: A list of authors with their affiliations
[ ] A statement of need clearly stating problems the software is designed to solve and its target audience.
[ ] References: With DOIs for all those that have one (e.g. papers, datasets, software).

Final approval (post-review)

[ ] The author has responded to my review and made changes to my satisfaction. I recommend approving this package.

Estimated hours spent reviewing: 2 hrs

Review Comments

Nice and interesting concept developed into a full fledged package. I enjoyed my time trying to get my name to show up, it's probably not in the database! I support the simplicity of the concept while being useful to those who experiencing a conflict in choosing suitable names for newborns.
The details in the package are well put together and everything works smoothly while being tested. The functions perform the task as claimed in the README description. Nicely done!!
The references to similar package is clear, cited through the appropriate link and the differences from them similar package is clearly stated. Nice work!
The higher level working of the functions is well done, I did find some minor concerns in a couple of the functions and they are explained below:
Function find_name - The usage section doesn't tell the user about the argument format. For instance, in the provided example I thought "F", "A" perhaps meant the starting and ending letters of the expected name. After a few trials I inferred: the first string is for sex and only takes "M" or "F" or "uni" as inputs and that the second argument is the starting letter of the expected name. Perhaps this can be made clear in the USAGE section and the documentation.
Function old_name - Similar concern to the one mentioned above, the description in the usage says we can specify the 'sex', however I was not clear of the format in which the sex argument should be entered. for instance the following codes gave an error

find_old_name('M', limit = 5)

find_old_name('1990s', 'M', limit = 5)

Then I figured out the following is the correct way to use this function find_old_name('1990s', sex = 'M', limit = 5)

Perhaps this can be made clear in the documentation.

For function find_old_name, when I entered the year as '1990' instead of '1990s' it took some time to run the code and then finally suggested to enter a valid year/sex. Could argument validation checks be made faster? Since currently it takes the same amount of time to solve a valid argument or notify an invalid argument, scaling the package in future may decrease user convenience in using the package.
I reviewed the code and it is well structured, easy to read and understand. Nice work in documenting it and sharing and interesting application of package creation process!

Package Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

[X] As the reviewer I confirm that there are no conflicts of interest for me to review this work (If you are unsure whether you are in conflict, please speak to your editor before starting your review).

Documentation

The package includes all the following forms of documentation:

[X] A statement of need clearly stating problems the software is designed to solve and its target audience in README.
[X] Installation instructions: for the development version of the package and any non-standard dependencies in README.
[X] Vignette(s) demonstrating major functionality that runs successfully locally.
[X] Function Documentation: for all user-facing functions.
[X] Examples for all user-facing functions.
[X] Community guidelines including contribution guidelines in the README or CONTRIBUTING.
[X] Metadata including author(s), author e-mail(s), a url, and any other relevant metadata e.g., in a pyproject.toml file or elsewhere.

Readme file requirements The package meets the readme requirements below:

[X] Package has a README.md file in the root directory.

The README should include, from top to bottom:

[X] The package name
[X] Badges for:
- [X] Continuous integration and test coverage,
- [X] Docs building (if you have a documentation website),
- [ ] A repostatus.org badge,
- [ ] Python versions supported,
- [X] Current package version (on PyPI / Conda).

[X] Short description of package goals.
[X] Package installation instructions
[ ] Any additional setup required to use the package (authentication tokens, etc.)
[X] Descriptive links to all vignettes. If the package is small, there may only be a need for one vignette which could be placed in the README.md file.
- [X] Brief demonstration of package usage (as it makes sense - links to vignettes could also suffice here if package description is clear)
[X] Link to your documentation website.
[X] If applicable, how the package compares to other similar packages and/or how it relates to other packages in the scientific ecosystem.
[X] Citation information

Usability

[X] Package documentation is clear and easy to find and use.
[X] The need for the package is clear
[X] All functions have documentation and associated examples for use
[X] The package is easy to install

Functionality

[X] Installation: Installation succeeds as documented.
[ ] Functionality: Any functional claims of the software been confirmed.
[ ] Performance: Any performance claims of the software been confirmed.
[X] Automated tests: Tests cover essential functions of the package and a reasonable range of inputs and conditions. All tests pass on the local machine.
[X] Continuous Integration: Has continuous integration setup (We suggest using Github actions but any CI platform is acceptable for review)
[X] Packaging guidelines: The package conforms to the pyOpenSci packaging guidelines. A few notable highlights to look at:
- [X] Package supports modern versions of Python and not End of life versions.
- [ ] Code format is standard throughout package and follows PEP 8 guidelines (CI tests for linting pass)

For packages also submitting to JOSS

[ ] The package has an obvious research application according to JOSS's definition in their submission requirements.

Note: Be sure to check this carefully, as JOSS's submission requirements and scope differ from pyOpenSci's in terms of what types of packages are accepted.

The package contains a paper.md matching JOSS's requirements with:

[ ] A short summary describing the high-level functionality of the software
[ ] Authors: A list of authors with their affiliations
[ ] A statement of need clearly stating problems the software is designed to solve and its target audience.
[ ] References: With DOIs for all those that have one (e.g. papers, datasets, software).

Final approval (post-review)

[ ] The author has responded to my review and made changes to my satisfaction. I recommend approving this package.

Estimated hours spent reviewing: ~ 2 hours

Review Comments

(Review based on the latest commit on main as of writing, commit https://github.com/UBC-MDS/nameforme/commit/8cbb2d3b0d816da00cc5779c1ffde49395e7390e)

First, congratulations on the releasing of the package. It is a fun, simple (yet cool!) idea to use this dataset to suggest baby names.

What I like most is the code is clean and neat. I can see that other reviewers have already given excellent comments over the functionality aspect over the package. I would therefore would like to focus solely on the code-side of things instead.

(Some comments are similar to what I have made in the R package, which can be viewed here.)

1. Consider following PEP 8 and other Python styleguides.

I know that this is not strictly required, and the linting routine is not even in our CI/CD workflows, but a consistent code style can be much easier for others to contribute and build on. (We are lucky that in Python we have relatively consistent code style, unlike JavaScript.) For example, by using pycodeguide:

$ pycodestyle nameforme.py
nameforme.py:9:1: E302 expected 2 blank lines, found 1
nameforme.py:11:80: E501 line too long (88 > 79 characters)
nameforme.py:14:17: W291 trailing whitespace
nameforme.py:23:80: E501 line too long (84 > 79 characters)
nameforme.py:32:1: W293 blank line contains whitespace
nameforme.py:40:1: W293 blank line contains whitespace
nameforme.py:44:1: W293 blank line contains whitespace
nameforme.py:48:1: W293 blank line contains whitespace
nameforme.py:51:1: W293 blank line contains whitespace
nameforme.py:55:1: W293 blank line contains whitespace
nameforme.py:56:32: W291 trailing whitespace
nameforme.py:57:80: E501 line too long (115 > 79 characters)

[..snip..]

It might even be better to integrate this into CI/CD to trigger for every PR.

2. Consider DRYing your code, instead of Writing Every Time.

An example would be the snippet of loading the CSV dataset:

url = "https://raw.githubusercontent.com/rfordatascience/tidytuesday/master/data/2022/2022-03-22/babynames.csv"
raw_df = pd.read_csv(url)

This piece of code appears for 4 times in the nameforme.py function. You may consider refactoring by, e.g., wrapping it as an utility function:

def load_raw_data():
    # You may also do data wrangling here, e.g., dropping unnecessary columns
    url = "https://raw.githubusercontent.com/rfordatascience/tidytuesday/master/data/2022/2022-03-22/babynames.csv"
    return pd.read_csv(url)

While the line count does not seem to decrease much, the real benefit is that when we want to, say, change the upstream dataset which may have a different structure, it would be easier.

3. Consider enhancing your test cases, especially the conditional guards.

Looking for 100% line coverage for all projects is impractical, but it is always beneficial to cover edge cases. For example, currently the line coverage report shows that we are missing 7 lines, which are related to error handling cases (e.g., throwing exception when the type is not expected, out of range). It would be beneficial that this kind of behaviors to be documented in form of a working test case.

4. find_old_name should have better guard.

I realized this when I tried out the sex parameter in it, but realized that this does not work with lower cases (e.g., 'f' or 'm'), unlike find_name. The offending piece of code is:

    df = data[data["tp"]==tp]
    if sex == "uni":
        F = df[df["sex"] == 'F']["name"]
        M = df[df["sex"] == "M"]["name"]
        uni_df = list(set(F).intersection(set(M)))
        if len(uni_df) < 10:
            return uni_df
        else:
            return np.random.choice(uni_df, limit, replace=False).tolist()
    else: 
        df = df[df["sex"] == sex]["name"]
        return np.random.choice(df,limit,replace=False).tolist()

It could be simplified, rewritten, with an added guard as:

    df = data[data["tp"] == tp]
    if sex.upper() == "M" or sex.upper() == "F":
        df = df[df["sex"] == sex.upper()]
    elif sex != "uni":
        warnings.warn("Invalid sex specified, assuming unisex")
    return np.random.choice(df["name"],limit,replace=False).tolist()

This can allow the m and f be used, while warning the user if values other than "f", "m", "F", "M", "uni" be used.

5. find_name and find_old_name have different sex definition, which can be confusing.

It might be best if the parameter can be unified. For example:

"M" or "m" for Male
"F" or "f" for Female
None for Unisex

Alternatively, it might even be better to use enums instead, so that the user can pass in a Gender.MALE, Gender.FEMALE, Gender.UNISEX as a parameter.

6. find_unisex_name has a conflicting docstring definition.

The said function is defined as def find_unisex_name(bar,limit=10), but provides the parameters as:

    limit : float
        A float controls the minimum proportion of the neutral names in a single year in the dataframe.
    count : integer
        The length of the output with a default value of 10

It would be better to use consistent variable naming, with documentation review in place.

7. Consider using ValueError, IndexError instead of generic Exception.

Python libraries provide a lot of specific type of exceptions for different occasions. For instance, this snippet from find_name would be better fitted to use ValueError:

    if not (sex == 'F' or sex == 'M' or sex == 'f' or sex == 'm'):
        raise Exception("sex should be either 'F'/'f' or 'M'/'m'.")

Overall, I enjoy reading the code of your project, and despite hiccups, your documentation is good. Great work!

(Reviewed using pyOpenSci review template

Package Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

[x] As the reviewer I confirm that there are no conflicts of interest for me to review this work (If you are unsure whether you are in conflict, please speak to your editor before starting your review).

Documentation

The package includes all the following forms of documentation:

[x] A statement of need clearly stating problems the software is designed to solve and its target audience in README.
[x] Installation instructions: for the development version of the package and any non-standard dependencies in README.
[x] Vignette(s) demonstrating major functionality that runs successfully locally.
[x] Function Documentation: for all user-facing functions.
[x] Examples for all user-facing functions.
[x] Community guidelines including contribution guidelines in the README or CONTRIBUTING.
[x] Metadata including author(s), author e-mail(s), a url, and any other relevant metadata e.g., in a pyproject.toml file or elsewhere.

Readme file requirements The package meets the readme requirements below:

[x] Package has a README.md file in the root directory.

The README should include, from top to bottom:

[x] The package name
[x] Badges for:
- [x] Continuous integration and test coverage,
- [x] Docs building (if you have a documentation website),
- [ ] A repostatus.org badge,
- [ ] Python versions supported,
- [x] Current package version (on PyPI / Conda).

[x] Short description of package goals.
[x] Package installation instructions
[ ] Any additional setup required to use the package (authentication tokens, etc.)
[x] Descriptive links to all vignettes. If the package is small, there may only be a need for one vignette which could be placed in the README.md file.
- [x] Brief demonstration of package usage (as it makes sense - links to vignettes could also suffice here if package description is clear)
[x] Link to your documentation website.
[x] If applicable, how the package compares to other similar packages and/or how it relates to other packages in the scientific ecosystem.
[x] Citation information

Usability

[x] Package documentation is clear and easy to find and use.
[x] The need for the package is clear
[x] All functions have documentation and associated examples for use
[x] The package is easy to install

Functionality

[x] Installation: Installation succeeds as documented.
[ ] Functionality: Any functional claims of the software been confirmed.
[ ] Performance: Any performance claims of the software been confirmed.
[x] Automated tests: Tests cover essential functions of the package and a reasonable range of inputs and conditions. All tests pass on the local machine.
[x] Continuous Integration: Has continuous integration setup (We suggest using Github actions but any CI platform is acceptable for review)
[x] Packaging guidelines: The package conforms to the pyOpenSci packaging guidelines. A few notable highlights to look at:
- [x] Package supports modern versions of Python and not End of life versions.
- [ ] Code format is standard throughout package and follows PEP 8 guidelines (CI tests for linting pass)

For packages also submitting to JOSS

[ ] The package has an obvious research application according to JOSS's definition in their submission requirements.

Note: Be sure to check this carefully, as JOSS's submission requirements and scope differ from pyOpenSci's in terms of what types of packages are accepted.

The package contains a paper.md matching JOSS's requirements with:

[x] A short summary describing the high-level functionality of the software
[x] Authors: A list of authors with their affiliations
[x] A statement of need clearly stating problems the software is designed to solve and its target audience.
[x] References: With DOIs for all those that have one (e.g. papers, datasets, software).

Final approval (post-review)

[ ] The author has responded to my review and made changes to my satisfaction. I recommend approving this package.

Estimated hours spent reviewing:

Review Comments

Your package is very distinctive, I like your theme very much, I think it will have broad application prospects.
The code is concise and easy to understand, very structured, with the characteristics of software engineering.
There are a lot of commits each time, and various details reflect the level of cooperation of your team.
The package is fully functional, with very distinctive methods and functions, decoupled and modularized.
You guys have made a great package that I think I will use someday!

UBC-MDS / software-review-2023