automata

[eliotwrobson]

Submitting Author: Eliot Robson (@eliotwrobson)
All current maintainers: (@eliotwrobson, @caleb531)
Package Name: automata
One-Line Description of Package: A Python library for simulating finite automata, pushdown automata, and Turing machines.
Repository Link: https://github.com/caleb531/automata
Version submitted: v8.2.0
EiC: @isabelizimm
Editor: @sneakers-the-rat
Reviewers: @phildong , @irisdyoung, @NimaSarajpoor
Reviews Expected By: March 28th, 2024
Archive:
Version accepted: 8.4.0 (repo, pypi, archive)
Date accepted (month/day/year): 06/29/2024

---

Code of Conduct & Commitment to Maintain Package

• I agree to abide by pyOpenSci's Code of Conduct during the review process and in maintaining my package after should it be accepted.
• I have read and will commit to package maintenance after the review as per the pyOpenSci Policies Guidelines.

Description

• Include a brief paragraph describing what your package does:

Automata is a Python 3 library implementing structures and algorithms for manipulating finite automata, pushdown automata, and Turing machines. The algorithms have been optimized and are capable of processing large inputs. Visualization logic has also been implemented.

Scope

• Please indicate which category or categories.
  Check out our package scope page to learn more about our
  scope. (If you are unsure of which category you fit, we suggest you make a pre-submission inquiry):

  • Data retrieval
  • Data extraction
  • Data processing/munging
  • Data deposition
  • Data validation and testing
  • Data visualization¹
  • Workflow automation
  • Citation management and bibliometrics
  • Scientific software wrappers
  • Database interoperability

Domain Specific & Community Partnerships

- [ ] Geospatial
- [x] Education
- [ ] Pangeo

Community Partnerships

If your package is associated with an
existing community please check below:

• Pangeo
  • My package adheres to the Pangeo standards listed in the pyOpenSci peer review 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?

This package is suitable for both researchers wishing to manipulate automata and for instructors teaching courses on theoretical computer science. Automata (especially finite automata) are important models in computing that appear in a variety of educational and research contexts, and the ability to manipulate them with this package is valuable to this effort.

• Are there other Python packages that accomplish the same thing? If so, how does yours differ?

There are some smaller packages with similar scope (for example here), but automata is the most popular, best maintained, and most feature-rich.

• 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:

#135

• Any other questions or issues we should be aware of:

Although I am not the primary repository owner (that is @caleb531), he has given me permission to make this submission and be a long-term point of contact as-needed. Additionally, our documentation page is brand-new, so we anticipate some rough edges, and hope that feedback from this review can be used to improve the usability and add examples. Automata also already appeared in JOSS, so that is why those items have been left blank here even though the writeup is present in the repository.

Technical checks

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

• does not violate the Terms of Service of any service it interacts with.
• uses an OSI approved license.
• contains a README with instructions for installing the development version.
• includes documentation with examples for all functions.
• contains a tutorial with examples of its essential functions and uses.
• has a test suite.
• has continuous integration setup, such as GitHub Actions 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. 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: "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 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: JOSS accepts our review as theirs. You will NOT need to go through another full review. JOSS will only review your paper.md file. Be sure to link to this pyOpenSci issue when a JOSS issue is opened for your package. Also be sure to tell the JOSS editor that this is a pyOpenSci reviewed package once you reach this step.

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.

• 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.

Confirm each of the following by checking the box.

• I have read the author guide.
• I expect to maintain this package for at least 2 years and can help find a replacement for the maintainer (team) if needed.

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.

Footnotes

1. Please fill out a pre-submission inquiry before submitting a data visualization package. ↩

[lwasser]

hey there @eliotwrobson 👋 Welcome to pyOpenSci!! I just wanted to let you know that we have seen this submission and will be following up in the next week about moving forward with it! Have a wonderful weekend. ✨

[lwasser]

hi again @eliotwrobson @caleb531 👋 my apologies for the delay! we are making a few changes to our editorial process and that took a bit of time to sort out!

Our Editor in Chief for the next quarter, @isabelizimm will be running initial checks on this package in the upcoming week. After that @sneakers-the-rat will lead the review as editor! You will hear from our editorial team sometime in the next week to kick off the review. ✨ Thank you for your patience!

[isabelizimm]

Thank you so much for this submission! I've done some preliminary checks below, which all look great 🎉 your editor will be @sneakers-the-rat, who will take it from here with finding reviewers.

Editor in Chief checks

Hi there! Thank you for submitting your package for pyOpenSci
review. Below are the basic checks that your package needs to pass
to begin our review. If some of these are missing, we will ask you
to work on them before the review process begins.

Please check our Python packaging guide for more information on the elements
below.

• Installation The package can be installed from a community repository such as PyPI (preferred), and/or a community channel on conda (e.g. conda-forge, bioconda).
  • The package imports properly into a standard Python environment import package.
• Fit The package meets criteria for fit and overlap.
• Documentation The package has sufficient online documentation to allow us to evaluate package function and scope without installing the package. This includes:
  • User-facing documentation that overviews how to install and start using the package.
  • Short tutorials that help a user understand how to use the package and what it can do for them.
  • API documentation (documentation for your code's functions, classes, methods and attributes): this includes clearly written docstrings with variables defined using a standard docstring format.
• Core GitHub repository Files
  • README The package has a README.md file with clear explanation of what the package does, instructions on how to install it, and a link to development instructions.
  • Contributing File The package has a CONTRIBUTING.md file that details how to install and contribute to the package.
  • Code of Conduct The package has a CODE_OF_CONDUCT.md file.
  • License The package has an OSI approved license.
    NOTE: We prefer that you have development instructions in your documentation too.
• Issue Submission Documentation All of the information is filled out in the YAML header of the issue (located at the top of the issue template).
• Automated tests Package has a testing suite and is tested via a Continuous Integration service.
• Repository The repository link resolves correctly.
• Package overlap The package doesn't entirely overlap with the functionality of other packages that have already been submitted to pyOpenSci.
• Archive (JOSS only, may be post-review): The repository DOI resolves correctly.
• Version (JOSS only, may be post-review): Does the release version given match the GitHub release (v1.0.0)?

---

• Initial onboarding survey was filled out
  We appreciate each maintainer of the package filling out this survey individually. 🙌
  Thank you authors in advance for setting aside five to ten minutes to do this. It truly helps our organization. 🙌

---

[lwasser]

hi there @eliotwrobson 👋 i wanted to point out two small items that you could address associated with your package's structure!

1. you have a shell setup.py file here that you don't need! It did used to be the case that the setup.py file was needed for editable installs. HOwever that is no longer the case. You can remove it and all should be fine.
2. Setuptools also installs wheel at runtime as a requirement. so you can remove wheel from your pyproject.toml build declaration

These are small changes but will modernize / clean up your package just a bit! :)

[eliotwrobson]

@sneakers-the-rat are there any more action items we can handle before reviews start? Just wanted to check in, thanks!

[sneakers-the-rat]

Hello! sorry for the delay, i've been prepping for/at a workshop the last few weeks, but let's get this rolling. I have one reviewer that has previously agreed to review this, and am putting the call out for more.

[phildong]

Hello this is the "one reviewer" popping in and saying Hi. Very excited for this and ready to jump in whenever you're ready!

[sneakers-the-rat]

Hello and thank you for agreeing to review @phildong !!!!!

Still casting about for reviewers, I see @nathanael-fijalkow and @rohaquinlop as having worked on similar projects in the past by searching through github a bit, although they have not agreed to review for pyopensci, will ask again on masto and in reviewer channels :)

[sneakers-the-rat]

Checking in again, I'll make another call for a second reviewer, but @eliotwrobson if you could recommend anyone that might be suitable as a reviewer that would be great!

[eliotwrobson]

@sneakers-the-rat thanks for checking in! I don't have anyone specific in mind (I'm honestly not sure what the qualifications are for review). If you wanted to, you could ask people that did the previous JOSS review? That might make things easier since they already know their way around.

[sneakers-the-rat]

We have located a second reviewer! Thank you to @irisdyoung for volunteering, and thanks @phildong for your patience :)

Now that we have two reviewers, let's get started!

pyOpenSci is a young-ish organization and doesn't have some of the fancier review bot features set up like JOSS yet (we're working on it!), but the reviews work similarly if you've done that before:

First, check out the reviewer guide here - https://www.pyopensci.org/software-peer-review/how-to/reviewer-guide.html (and you can raise issues if anything is unclear here: https://github.com/pyOpenSci/software-peer-review ). There are example reviews linked from there, and you can also see previous reviews i have done for pyopensci (pygraphblas) or joss (reorient)

My role here is to make sure the reviewers have everything needed to complete the review, and make sure the vibes stay close to a supportive, collaborative discussion. So I don't end up typing this 50 times: if you need anything at all, don't hesitate to ask. If you would prefer speaking privately, you can reach me on the fediverse or via email.

As an overview, you are going to do three things

• Checklist - the review checklist serves as a set of minimal requirements for a package. The checklist is constructed by the editorial team, with input from lots of parts of the Python world, but if any parts of it are unclear (or you have any other thoughts on them) that can be up for discussion as well.
• Discussion - As you go, you should raise issues or make pull requests with questions, comments, and suggestions. Since github issues don't have threading, we use issues/PRs as threads to keep discussions somewhat tidy. When you do so, please link back to this issue so that we can keep track of all the threads related to this review. Beyond that it is up to y'all if you want to have any sort of naming conventions, etc. for issues/PRs. Discussion happens throughout the review process, rather than only at the end! The authors are welcome to address and improve the package throughout the review as well.
• Summary - At the end, you will write a summary of your thoughts on the package - its strengths, applicability, and potential points of future improvement.

As reviewers, you are taking the role of an interested and critical potential user - it should be possible for you to (non-exhaustively) a) understand what the package is supposed to be able to do, b) know how to do it, c) be able to do it, and d) be confident that functionality won't break. All that should require no special information from the authors - you are reviewing both for technical correctness as well as quality of documentation and technical infrastructure like CI. A decent heuristic is, by the end of the review, the package should be one that you would want to add as a dependency in your work.

The checklist is a minimum bar, but you are welcome to review anything beyond that - as reviewers you can coordinate amongst yourselves if one or the other of you has a preferred focus, eg. someone prefers reviewing for docs and the other wants to review for performance, etc. You can signal if a particular issue is a blocker for you or not, and we can resolve those as they come up - optional suggestions, comments, questions, etc. are also in bounds.

This is an open, collaborative review process - the checklist is about bringing packages in python world up to a minimal standard of maintainability and functionality, but it is not a gate to keep. There is no concept of "rejection" here, instead we are trying to help the authors reach that standard. Be the code reviewer you always wished you had <3.

And with that lengthy explanation... let's get started. the first thing you'll both want to do is copy and paste the review template (also added in the collapsible below) into a new comment that you can then edit as you do your review :) glhf <3

Let's set a tentative date to expect reviews 3 weeks from now - March 28th

Expand/collapse 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*

- [ ] 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:

- [ ] **A statement of need** clearly stating problems the software is designed to solve and its target audience in README.
- [ ] **Installation instructions:** for the development version of the package and any non-standard dependencies in README.
- [ ] **Vignette(s)** demonstrating major functionality that runs successfully locally.
- [ ] **Function Documentation:** for all user-facing functions.
- [ ] **Examples** for all user-facing functions.
- [ ] **Community guidelines** including contribution guidelines in the README or CONTRIBUTING.
- [ ] **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:

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

The README should include, from top to bottom:

- [ ] The package name
- [ ] Badges for:
    - [ ] Continuous integration and test coverage,
    - [ ] Docs building (if you have a documentation website),
    - [ ] A [repostatus.org](https://www.repostatus.org/) badge,
    - [ ] Python versions supported,
    - [ ] 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](https://github.com/ropensci/drake). Such a table should be more wide than high. (Note that the a badge for pyOpenSci peer-review will be provided upon acceptance.)*

- [ ] Short description of package goals.
- [ ] Package installation instructions
- [ ] Any additional setup required to use the package (authentication tokens, etc.)
- [ ] 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.
    - [ ] Brief demonstration of package usage (as it makes sense - links to vignettes could also suffice here if package description is clear)
- [ ] Link to your documentation website.
- [ ] If applicable, how the package compares to other similar packages and/or how it relates to other packages in the scientific ecosystem.
- [ ] 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:

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


#### Functionality

- [ ] **Installation:** Installation succeeds as documented.
- [ ] **Functionality:** Any functional claims of the software been confirmed.
- [ ] **Performance:** Any performance claims of the software been confirmed.
- [ ] **Automated tests:**
  - [ ] All tests pass on the reviewer's local machine for the package version submitted by the author. Ideally this should be a tagged version making it easy for reviewers to install.
  - [ ] Tests cover essential functions of the package and a reasonable range of inputs and conditions.
- [ ] **Continuous Integration:** Has continuous integration setup (We suggest using Github actions but any CI platform is acceptable for review)
- [ ] **Packaging guidelines**: The package conforms to the pyOpenSci [packaging guidelines](https://www.pyopensci.org/python-package-guide).
    A few notable highlights to look at:
    - [ ] Package supports modern versions of Python and not [End of life versions](https://endoflife.date/python).
    - [ ] 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](http://joss.theoj.org/about#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](http://joss.theoj.org/about#paper_structure) 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:

---

#### Review Comments

[sneakers-the-rat]

Checking in with reviewers, @phildong @irisdyoung - do we think we'll need more time?

[phildong]

@sneakers-the-rat sorry I was traveling last week. I aim to finish the review this week/weekend!

[phildong]

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

• 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:

• A statement of need clearly stating problems the software is designed to solve and its target audience in README.
• Installation instructions: for the development version of the package and any non-standard dependencies in README.
• Vignette(s) demonstrating major functionality that runs successfully locally.
• Function Documentation: for all user-facing functions.
• Examples for all user-facing functions.
• Community guidelines including contribution guidelines in the README or CONTRIBUTING.
• 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:

• Package has a README.md file in the root directory.

The README should include, from top to bottom:

• The package name
• Badges for:
  • Continuous integration and test coverage,
  • Docs building (if you have a documentation website),
  • A repostatus.org badge,
  • Python versions supported,
  • 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.)

• Short description of package goals.
• Package installation instructions
• Any additional setup required to use the package (authentication tokens, etc.)
• 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.
  • Brief demonstration of package usage (as it makes sense - links to vignettes could also suffice here if package description is clear)
• Link to your documentation website.
• If applicable, how the package compares to other similar packages and/or how it relates to other packages in the scientific ecosystem.
• 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:

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

Functionality

• Installation: Installation succeeds as documented.
• Functionality: Any functional claims of the software been confirmed.
• Performance: Any performance claims of the software been confirmed.
• Automated tests:
  • All tests pass on the reviewer's local machine for the package version submitted by the author. Ideally this should be a tagged version making it easy for reviewers to install.
  • Tests cover essential functions of the package and a reasonable range of inputs and conditions.
• Continuous Integration: Has continuous integration setup (We suggest using Github actions but any CI platform is acceptable for review)
• 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.
  • Code format is standard throughout package and follows PEP 8 guidelines (CI tests for linting pass)

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:

10hr

---

Review Comments

The automata package allow the users to easily build and manipulate finite automata, pushdown automata, and Turing machines. It's an invaluable tool for teaching and demonstration of this topic. The algorithm is also optimized for large inputs so it can be useful in theoretical research. The code is well-packaged with detailed documentation and CI setup. I was able to easily install and use the package.

Specific comments:

• statement of python 3.12 support caleb531/automata#211
• docs: add teaching example caleb531/automata#212
• demonstration of processing of large input caleb531/automata#213

[phildong]

ok finished my first pass of review. @sneakers-the-rat since it's first time I do this please let me know if I'm on the right track and if there's any major stuff I'm missing!

Meanwhile I got some questions:

• Am I supposed evaluate the novelty/impact the package? I can certainly see the package being a very nice resource to the community exactly as described, but it's a bit hard for me to compare it to any other potentially similar packages since I'm not expert in this field.
• I see the "JOSS publication" section was not checked in the original submission, so do I still need to worry about the corresponding section in the review template?
• The package has nice API documentation for all user-facing functions, and as someone who had to google "what's DFA" in the beginning, I could fairly easily figure out how to actually use the basic functions. That said, certainly not every function has usage example in the documentation. So I'm wondering what's the criteria for examples and what's the best way to proceed?

[NimaSarajpoor]

@eliotwrobson
I noticed an issue was already opened to enhance the examples. I checked the changes made to docs/examples/fa-examples.md. Great improvement! I am going to provide my comments just to make sure we have all things in one place. Btw, your package might be useful for engineers as well as they can better understand the concept of state / transition.

Please feel free to ignore if a similar comment was made by someone else before, and was already addressed / discussed. Also, these are just my perspective. So, feel free to let me know when you think a comment is not a good fit.

(1) Maybe add a link to examples on README page (Or maybe just provide one example on the README page)
(2) If interested in getting more citations, you may want to add a citing part on README
(3) Adding diagram (which I can see that it is addressed by calling the method show_diagram() in this opened issue)
(4) Adding (printing) the output of read_user_input(my_dfa) can help user connect the dots (particularly, if they are trying to learn this concept, seeing the output may give them the "Eureka moment!")
(5) Add the description of non-private methods to the doctoring of class DFA (I haven't checked other classes)

I do not see any other concerns from my end!

[eliotwrobson]

@NimaSarajpoor Thank you for the feedback! I think we should be able to add most of those items on to the open pull request you linked to.

The only one I had questions on was 5. Would this just be listing every public method in the top docstring for the DFA class? I'm not sure how valuable this would be in the scheme of things, since there's a huge number of methods, and these are all listed on the documentation site anyway. However, I'm not sure what common practice is in other libraries.

[lwasser]

Hi there - i'm just checking in to see how things are going 👋🏻 it looks like there are a few wrapup documentation elements to complete and then we can move this forward. @NimaSarajpoor THANK YOU for pitching in here!! i'll also add you as a reviewer to the header.

finally i am curious about the description being requested - i do see this

https://caleb531.github.io/automata/api/fa/class-dfa/

in the api docs and it looks like methods are generally documented. We can discuss more however as there might be a documentation piece that i'm missing as well!

Have a great weekend y'all. i'll check back in next week and we can work together to wrap this review up!

[NimaSarajpoor]

TL;DR
Probably better to ignore (5)

---

@lwasser

finally i am curious about the description being requested - i do see this

You are absolutely right that the description was provided in the API docs. My comment was mainly about having the methods in the doctoring of the class

https://github.com/caleb531/automata/blob/530016a03703e071b72f1665769770039018536d/automata/fa/dfa.py#L54

@eliotwrobson

The only one I had questions on was 5. Would this just be listing every public method in the top docstring for the DFA class?

However, I'm not sure what common practice is in other libraries.

After you ask the question, I realized I was not sure myself! 😅 I did some research and found this stackoverflow post in which the answer quotes the following sentence from PEP 257:

The docstring for a class should summarize its behaviour and list the public methods and instance variables.

Still, the author of the answer mentioned that they prefer to avoid doing this because it can become out of date in the future.

[eliotwrobson]

@lwasser thanks for checking in! We just merged caleb531/automata#227, which finishes addressing @/NimaSarajpoor's comments and the last open PR from this review (closing because our examples are now more extensive, and more comprehensive tutorials will be coming later). So I think we've addressed every open issue that's been raised thus far.

[lwasser]

ok y'all. It seems to me that in the latest PR all of the documentation issues have been addressed. We have one review formally submitted to this review from @phildong - thank you!! @phildong do you have content with the state of the package now after your review? Please just reply here if you have a moment.

@NimaSarajpoor i think from your statement above that you are ok with the state of the package docs (which was your focus here).
can you please confirm by responding here?

NOTE: I did start a conversation on slack around that PEP. That seems fairly extensive - especially given we have tools to generate API docs and that pep was from 2001. BUT there could be other reasons for it too that I am missing (such as for those running help()). regardless if you can confirm that the changes made seem adequate that would be great.

@irisdyoung i just hope things are ok with you. I certainly understand hectic lives. I hope you are well! Please know that we never want to pressure / stress reviewers and volunteers at pyOpenSci and only wish for the best for everyone! Sometimes life gets busy and that is ok / (in fact recommended!!) to take care of yourself first!

[NimaSarajpoor]

@lwasser
Yes. The docs look good to me. I confirm that there is no further concern from my end.

[lwasser]

thank you @NimaSarajpoor ok all we need is the ok from @phildong !!

[phildong]

oops sorry for the holdup on my side.
I looked over the PR/conversations and everything looks nice! I've updated my original comment and I confirm there is no further concern from my side.
One small thing: when I go to https://caleb531.github.io/automata/examples/fa-examples/ The updates in the examples doesn't seem to appear yet.
But I'm assuming it will fix itself once the dev branch made to main/release, so everything is good in that case.

[eliotwrobson]

@phildong thanks for following up! This is indeed the case, the new version of the docs site will go up on a new deployment. You can see a preview of the page by looking at the branch: https://github.com/caleb531/automata/blob/develop/docs%2Fexamples%2Ffa-examples.md

[sneakers-the-rat]

Alright, sorry for my absence, am back at work now and Leah has asked me to finish up the review. It looks like we're all set here! we have two reviewers giving their all clear and all requested changes are made.

Here's the final approval checklist: https://www.pyopensci.org/software-peer-review/how-to/editors-guide.html#how-to-accept-a-package-into-the-pyopensci-ecosystem

The last substantive thing is to create an archive on zenodo - for the sake of the review you can just make a single archive of the repo (linked to a tagged commit, ideally), but you can also set up zenodo to automatically archive releases as well (sorry but these are the best docs i can find on zenodo itself, but if you search you'll find a guide). Once you do that, post the DOI, i'll add it to the top of the issue, and that should be that! If you'd like to submit a blog post as well, please let me know and i'll figure out where you should send that :)

Reviewers: you are welcome to join the pyopensci slack as well, I believe you should all either already be in there or you know how to contact me privately and i'll send you an invite!

thank you all again!

---

🎉 automata has been approved by pyOpenSci! Thank you @eliotwrobson for submitting automata and many thanks to @phildong, @NimaSarajpoor, and @irisdyoung for reviewing this package! 😸

Author Wrap Up Tasks

There are a few things left to do to wrap up this submission:

• Activate Zenodo watching the repo if you haven't already done so.
• Tag and create a release to create a Zenodo version and DOI.
• Add the badge for pyOpenSci peer-review to the README.md of . The badge should be [![pyOpenSci](https://tinyurl.com/y22nb8up)](https://github.com/pyOpenSci/software-submission/issues/152).
• Please fill out the post-review survey. All maintainers and reviewers should fill this out.

Editor Final Checks

Please complete the final steps to wrap up this review. Editor, please do the following:

• Make sure that the maintainers filled out the post-review survey
• Invite the maintainers to submit a blog post highlighting their package. Feel free to use / adapt language found in this comment to help guide the author.
• Change the status tag of the issue to 6/pyOS-approved6 🚀🚀🚀.
• Invite the package maintainer(s) and both reviewers to slack if they wish to join.

---

If you have any feedback for us about the review process please feel free to share it here. We are always looking to improve our process and documentation in the peer-review-guide.

[eliotwrobson]

@sneakers-the-rat thank you! We've already set up automatic archiving through zenodo already: https://zenodo.org/records/10864492

I think it would be worthwhile to make a blog post as well, since we can just use examples / material from the JOSS paper or existing examples.

The revisions from items here will be included on Zenodo once we do another release. @caleb531 I've added the pyOpenSci badge to the develop branch along with the other changes, so we should be good to go. Would you like me to write the release notes? (can follow-up on slack if more discussion is needed).

[sneakers-the-rat]

great! added the DOI at the top, let me know when you make that release and that should be all!

[caleb531]

@sneakers-the-rat Perfect! I've just published Automata v8.4.0 with all of the discussed changes and documentation improvements!

https://github.com/caleb531/automata/releases/tag/v8.4.0
https://pypi.org/project/automata-lib/8.4.0/
https://zenodo.org/records/12594180

cc @eliotwrobson

[sneakers-the-rat]

Excellent. Ill finalize whats left to do here and check with EiC for anything else that needs to happen. I am supposed to remind the authors and reviewers complete this post review survey to improve our processes if they would be so kind :)

Thanks and congratulations to everyone!!

[eliotwrobson]

@sneakers-the-rat excellent! May we write a blog post for the package? If so, I'll get to work on that pretty soon.

[sneakers-the-rat]

yes, also asked about that & how to format/submit/etc. I would assume it would be a jekyll-markdown style post like those in https://github.com/pyOpenSci/pyopensci.github.io/tree/main/_posts

when i get further info i'll let you know (and also update our docs, bc they are unclear to authors and editors alike at the moment ;)

[irisdyoung]

hey everybody, sorry for dropping the ball. Glad to see you got the review process wrapped up -- thanks @NimaSarajpoor for stepping in!! And to the authors/maintainers, nice piece of work, glad it's out there!

[eliotwrobson]

@sneakers-the-rat the package is now listed on the site, and the blog post has been merged and is live. Can this issue be closed?

[lwasser]

oh yes. thank you for your patience @eliotwrobson and for being so on top of things. let's close this puppy as completed! i see you filled out the survey - many many thanks for the feedback!! 👐🏻