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 Editor: @sneakers-the-rat
Reviewer 1: @phildong Reviewer 2: @irisdyoung Reviews Expected By: March 28th, 2024 Archive: TBD JOSS DOI: TBD Version accepted: TBD Date accepted (month/day/year): TBD

---

Code of Conduct & Commitment to Maintain Package

• [x] I agree to abide by pyOpenSci's Code of Conduct during the review process and in maintaining my package after should it be accepted.
• [x] 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
  • [x] Data processing/munging
  • [ ] Data deposition
  • [ ] Data validation and testing
  • [x] Data visualization[^1]
  • [ ] 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

[^1]: Please fill out a pre-submission inquiry before submitting a data visualization package.

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

https://github.com/pyOpenSci/software-submission/issues/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:

• [x] does not violate the Terms of Service of any service it interacts with.
• [x] uses 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 tutorial with examples of its essential functions and uses.
• [x] has a test suite.
• [x] 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.

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

Confirm each of the following by checking the box.

• [x] I have read the author guide.
• [x] 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

• [x] 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.

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

• [X] 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).
  • [X] The package imports properly into a standard Python environment import package.
• [X] Fit The package meets criteria for fit and overlap.
• [X] Documentation The package has sufficient online documentation to allow us to evaluate package function and scope without installing the package. This includes:
  • [X] User-facing documentation that overviews how to install and start using the package.
  • [X] Short tutorials that help a user understand how to use the package and what it can do for them.
  • [X] 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.
• [X] Core GitHub repository Files
  • [X] 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.
  • [X] Contributing File The package has a CONTRIBUTING.md file that details how to install and contribute to the package.
  • [X] Code of Conduct The package has a CODE_OF_CONDUCT.md file.
  • [X] License The package has an OSI approved license. NOTE: We prefer that you have development instructions in your documentation too.
• [X] 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).
• [X] Automated tests Package has a testing suite and is tested via a Continuous Integration service.
• [X] Repository The repository link resolves correctly.
• [X] 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. :raised_hands: Thank you authors in advance for setting aside five to ten minutes to do this. It truly helps our organization. :raised_hands:

---

[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

• [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,
  • [x] 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.
• [ ] ~~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.
• [x] Performance: Any performance claims of the software been confirmed.
• [x] Automated tests:
  • [x] 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.
  • [x] Tests cover essential functions of the package and a reasonable range of inputs and conditions.
• [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)

Final approval (post-review)

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

• https://github.com/caleb531/automata/issues/211
• https://github.com/caleb531/automata/pull/212
• https://github.com/caleb531/automata/issues/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?

[sneakers-the-rat]

Looks great so far @phildong -

Am I supposed evaluate the novelty/impact the package?

there has been some ongoing discussion about whether this should matter in pyopensci reviews - at the moment the answer is no, don't worry about novelty/impact. The EiC has already cleared the package as in-scope. You are welcome to comment about this in your review, as well as request links to prior work as relevant: putting work in context is an important part of reviewing, and there is one item in the checklist asking about "how the package compares to other similar packages." It is a generally good practice for packages to maintain a "see also" section in their docs if there are other packages that are closely related, along with a note explaining similarities and differences: "Our package is for x, if you are looking for y then consider z package," and so on. You are also welcome to open an issue asking the authors about this if you aren't sure about the relation to prior work!

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?

nope :) you can remove those checkboxes from your review.

So I'm wondering what's the criteria for examples and what's the best way to proceed?

This is a tough judgement call to make. re: API documentation - what counts as a package's public API anyway? A decent heuristic is "the set of functions that one would expect to use to accomplish the stated purpose of the package." So even if they aren't marked private by a leading underscore, you might not require docstrings for every function in a utils module if they would only be used in an edge case, or are mostly used internally within the package. Another heuristic is 'do these functions show up in example notebooks' (aside from, well, utility functions that are explicitly for use in notebooks eg. for pretty printing and the like). Ultimately it's up to you as the reviewer whether the package is documented in a way that allows you to evaluate it, and would allow your average bear to use it.

[eliotwrobson]

@sneakers-the-rat any updates on the review from the second reviewer? We already addressed one open issue from the first review, and it would be helpful to have all issues / comments from this review before we make a pass through everything.

[eliotwrobson]

@sneakers-the-rat (cc @irisdyoung) do you think we might be able to close out reviews soon? The end of the academic year is coming up for me, and it would be awesome to be able to close out the remaining items for this review before the start of the summer.

[sneakers-the-rat]

Apologies, have been afk and traveling for the last few weeks. Back at my desk tomorrow and yes lets scoot this along :)

[sneakers-the-rat]

OK - checking in with @irisdyoung offline, @phildong is finished with first pass of review, so for that we'd be waiting on any final issues to raise and otherwise just a final review statement that summarizes a) outcomes of review checklist, b) overall impressions of package, c) strengths, and d) opportunities for growth :). I'll check in with phil separately monday if he's not checking on his gh notifications.

edit: will follow up with another timeline after making contact with reviewers

[sneakers-the-rat]

Checking in again - @irisdyoung any estimate on review time? and @phildong for some summary statement on the package if you have seen enough of it?

[eliotwrobson]

@sneakers-the-rat just a heads up that I'm going to get started on the existing open issues from this review pretty soon, along with expanding the examples in the documentation (based on the unchecked boxes left in the open review).

[phildong]

Sorry for the silence! I have followed up in the individual issues/PRs to provide some clarification (hopefully). Once they're addressed/closed I'm happy to write up a summary and make that final tick :smile:

[sneakers-the-rat]

@irisdyoung last call for review :) no worries if things are too hectic on your end, just want to know to start looking for another reviewer.

[irisdyoung]

Hello and apologies for the radio silence over here. I've done a first look through and can plan to raise any issues before the weekend. Talk soon!

[eliotwrobson]

Docs PR addressing most of the currently open issues from this review: https://github.com/caleb531/automata/pull/217

Basically adds discussion addressing most of the points of confusion that have come up so far.

Regarding more self-contained tutorials, that's coming up soon 👍👍

[sneakers-the-rat]

Great @irisdyoung thanks for letting us know.

[eliotwrobson]

@irisdyoung any updates? I think we've addressed all the issues you opened.

[lwasser]

hi there team 👋🏻 I wanted to check in on this review. your fearless editor @sneakers-the-rat is focused on other more pressing issues now going on in their professional environment. As such i'm just checking in to see if we can support Jonny in moving this review forward while they focus on bigger more important things.

As such, i'm trying to figure out the state of this review! i see one review submitted from @phildong -- thank you!! @irisdyoung i suspect you submitted some issues around the package but i don't see your format review submission using this template (please excuse me if i missed it!! )

it's important to have a tracebable record of the review so we ask that you both submit a formal review as a comment using that template and if you open issues / pr's (amazing!!) please link them back to this issue for traceability!

in the meantime I am also going to look for a pinch hitter editor to support this review to keep things moving forward.

everyone - please let me know how this sounds / if you have questions, concerns, etc / if i missed something!! ✨

thank you all for supporting our peer review process.

[eliotwrobson]

@lwasser thanks for checking in!! I think your assessment of the state of this review is correct. We've been trying to close all of the issues related to this review in a timely manner. There's one outstanding we may push back on somewhat given the effort involved and how long this review has been open, but otherwise there haven't been a ton of requests made by reviewers. With some support I think this can be pushed to close fairly soon (hopefully).