Closed whedon closed 3 years ago
@mado89 I am inclined to move toward acceptance, unless there are any additional concerns from @UTH-Tuan.
I would move toward acceptance. no concerns
@UTH-Tuan Thanks, this will help me to move toward the next steps. I'll be following up shortly.
Thanks, @mado89 and @UTH-Tuan. First, my apologies for to @arcuri82 for the delay as the past few weeks have been pretty intense leading to the end of semester. Thanks for your incredible patience during this process.
@arcuri82 Please do the following:
@gkthiruvathukal: thanks. I will do it in the next coming days
@gkthiruvathukal: is there any news on this? On Thursday the 7th, it is going to be 1 year since this article was first submitted :(
Hi @arcuri82. Yes, we're definitely heading to acceptance. I hoped to process it before taking a much-needed winter break. I'll finalize it today or tomorrow. Thanks for your patience! (As you know, we lost some reviewers during the review process but everything is done now. It does not normally take this long!)
@whedon commands
Here are some things you can ask me to do:
# List all of Whedon's capabilities
@whedon commands
# Assign a GitHub user as the sole reviewer of this submission
@whedon assign @username as reviewer
# Add a GitHub user to the reviewers of this submission
@whedon add @username as reviewer
# Re-invite a reviewer (if they can't update checklists)
@whedon re-invite @username as reviewer
# Remove a GitHub user from the reviewers of this submission
@whedon remove @username as reviewer
# List of editor GitHub usernames
@whedon list editors
# List of reviewers together with programming language preferences and domain expertise
@whedon list reviewers
# Change editorial assignment
@whedon assign @username as editor
# Set the software archive DOI at the top of the issue e.g.
@whedon set 10.0000/zenodo.00000 as archive
# Set the software version at the top of the issue e.g.
@whedon set v1.0.1 as version
# Open the review issue
@whedon start review
EDITORIAL TASKS
# All commands can be run on a non-default branch, to do this pass a custom
# branch name by following the command with `from branch custom-branch-name`.
# For example:
# Compile the paper
@whedon generate pdf
# Compile the paper from alternative branch
@whedon generate pdf from branch custom-branch-name
# Remind an author or reviewer to return to a review after a
# certain period of time (supported units days and weeks)
@whedon remind @reviewer in 2 weeks
# Ask Whedon to do a dry run of accepting the paper and depositing with Crossref
@whedon accept
# Ask Whedon to check the references for missing DOIs
@whedon check references
# Ask Whedon to check repository statistics for the submitted software
@whedon check repository
EiC TASKS
# Invite an editor to edit a submission (sending them an email)
@whedon invite @editor as editor
# Reject a paper
@whedon reject
# Withdraw a paper
@whedon withdraw
# Ask Whedon to actually accept the paper and deposit with Crossref
@whedon accept deposit=true
@whedon set 10.5281/zenodo.4300745 as archive
OK. 10.5281/zenodo.4300745 is the archive.
@whedon set 1.1.0 as release
I'm sorry human, I don't understand that. You can see what commands I support by typing:
@whedon commands
@whedon set 1.1.0 as version
OK. 1.1.0 is the version.
@whedon generate pdf
:point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:
@whedon accept
Attempting dry run of processing paper acceptance...
Reference check summary (note 'MISSING' DOIs are suggestions that need verification):
OK DOIs
- 10.1109/icst.2018.00046 is OK
- 10.1007/978-3-319-66299-2_1 is OK
- 10.1016/j.infsof.2018.05.003 is OK
- 10.1109/qrs.2017.11 is OK
- 10.1145/3293455 is OK
- 10.1145/3321707.3321815 is OK
- 10.1145/3321707.3321732 is OK
- 10.1109/ICST46399.2020.00025 is OK
- 10.1145/2379776.2379787 is OK
- 10.1109/ICSE.2019.00083 is OK
- 10.1109/ICST46399.2020.00023 is OK
- 10.1109/ICST46399.2020.00024 is OK
- 10.1109/EDOC.2018.00031 is OK
MISSING DOIs
- None
INVALID DOIs
- None
:wave: @openjournals/joss-eics, this paper is ready to be accepted and published.
Check final proof :point_right: https://github.com/openjournals/joss-papers/pull/2010
If the paper PDF and Crossref deposit XML look good in https://github.com/openjournals/joss-papers/pull/2010, then you can now move forward with accepting the submission by compiling again with the flag deposit=true
e.g.
@whedon accept deposit=true
Hi @arcuri82, I'm just doing some final checks on your submission before publishing.
I noticed some issues with in-text citations in your article (not using a single command when citing multiple things), and made a small PR to fix this: https://github.com/EMResearch/EvoMaster/pull/232
Can you merge this? I will then publish the article. There is no need to create a new Zenodo archive. Thanks!
@gkthiruvathukal: thanks @kyleniemeyer: thanks for PR. it is merged now
@whedon generate pdf
:point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:
@whedon accept deposit=true
Doing it live! Attempting automated processing of paper acceptance...
π¦π¦π¦ π Tweet for this paper π π¦π¦π¦
π¨π¨π¨ THIS IS NOT A DRILL, YOU HAVE JUST ACCEPTED A PAPER INTO JOSS! π¨π¨π¨
Here's what you must now do:
Party like you just published a paper! πππ¦ππ»π€
Any issues? Notify your editorial technical team...
thanks. generated PDF seems fine
Congrats @arcuri82 on your article's publication in JOSS!
Many thanks to @mado89, @s0nata, and @UTH-Tuan for reviewing this, and @gkthiruvathukal for editing.
:tada::tada::tada: Congratulations on your paper acceptance! :tada::tada::tada:
If you would like to include a link to your paper from your README use the following code snippets:
Markdown:
[![DOI](https://joss.theoj.org/papers/10.21105/joss.02153/status.svg)](https://doi.org/10.21105/joss.02153)
HTML:
<a style="border-width:0" href="https://doi.org/10.21105/joss.02153">
<img src="https://joss.theoj.org/papers/10.21105/joss.02153/status.svg" alt="DOI badge" >
</a>
reStructuredText:
.. image:: https://joss.theoj.org/papers/10.21105/joss.02153/status.svg
:target: https://doi.org/10.21105/joss.02153
This is how it will look in your documentation:
We need your help!
Journal of Open Source Software is a community-run journal and relies upon volunteer effort. If you'd like to support us please consider doing either one (or both) of the the following:
Submitting author: @arcuri82 (Andrea Arcuri) Repository: https://github.com/EMResearch/EvoMaster Version: 1.1.0 Editor: @gkthiruvathukal Reviewers: @mado89, @s0nata, @UTH-Tuan Archive: 10.5281/zenodo.4300745
Status
Status badge code:
Reviewers and authors:
Please avoid lengthy details of difficulties in the review thread. Instead, please create a new issue in the target repository and link to those issues (especially acceptance-blockers) by leaving comments in the review thread below. (For completists: if the target issue tracker is also on GitHub, linking the review thread in the issue or vice versa will create corresponding breadcrumb trails in the link target.)
Reviewer instructions & questions
@mado89, @UTH-Tuan, @s0nata, please carry out your review in this issue by updating the checklist below. If you cannot edit the checklist please:
The reviewer guidelines are available here: https://joss.readthedocs.io/en/latest/reviewer_guidelines.html. Any questions/concerns please let @gkthiruvathukal know.
β¨ Please try and complete your review in the next two weeks β¨
Review checklist for @mado89
Conflict of interest
Code of Conduct
General checks
Functionality
Documentation
Software paper
Review checklist for @UTH-Tuan
Conflict of interest
Code of Conduct
General checks
Functionality
Documentation
Software paper
Review checklist for @s0nata
Conflict of interest
Code of Conduct
General checks
Functionality
Documentation
Software paper