Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Submission: gitignore #303

Open
PMassicotte opened this issue May 21, 2019 · 51 comments

Comments

@PMassicotte
Copy link

commented May 21, 2019

Submitting Author: Philippe Massicotte (@PMassicotte)
Repository: https://github.com/PMassicotte/gitignore
Version submitted: 0.1.0
Editor: @melvidoni
Reviewer 1: @maurolepore
Reviewer 2: @aedobbyn
Archive: TBD
Version accepted: TBD


  • Paste the full DESCRIPTION file inside a code block below:
Package: gitignore
Type: Package
Title: Create useful .gitignore files for your project
Version: 0.1.0.9000
Authors@R: c(person("Philippe", 
         "Massicotte", 
         email = "pmassicotte@hotmail.com",
         role = c("aut", "cre")))
Description: Simple interface to query gitignore.io to fetch gitignore templates that can be included in the .gitignore file. More than 450 templates are currently available.
URL: https://github.com/PMassicotte/gitignore
BugReports: https://github.com/PMassicotte/gitignore/issues
License: GPL-3
Encoding: UTF-8
LazyData: true
Imports: 
    purrr,
    curl,
    glue,
    jsonlite,
    crayon,
    clipr,
    clisymbols,
    here,
    xfun
RoxygenNote: 6.1.1
Suggests: 
    spelling,
    knitr,
    rmarkdown,
    testthat (>= 2.1.0),
    covr
Language: en-US
VignetteBuilder: knitr

Scope

  • Please indicate which category or categories from our package fit policies this package falls under: (Please check an appropriate box below. If you are unsure, we suggest you make a pre-submission inquiry.):

    • data retrieval
    • data extraction
    • database access
    • data munging
    • data deposition
    • reproducibility
    • geospatial data
    • text analysis
  • Explain how and why the package falls under these categories (briefly, 1-2 sentences):

Because it helps facilitate use of version control.

  • Who is the target audience and what are scientific applications of this package?

Anyone working with the git technology can use the package to automatically generate the .gitignore file.

None that I could find.

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

Yes. See #299 (comment)

Technical checks

Confirm each of the following by checking the box. This package:

Publication options

JOSS Options
  • The package has an obvious research application according to JOSS's definition.
    • 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:
    • (Do not submit your package separately to JOSS)
MEE Options
  • The package is novel and will be of interest to the broad readership of the journal.
  • The manuscript describing the package is no longer than 3000 words.
  • You intend to archive the code for the package in a long-term repository which meets the requirements of the journal (see MEE's Policy on Publishing Code)
  • (Scope: Do consider MEE's Aims and Scope for your manuscript. We make no guarantee that your manuscript will be within MEE scope.)
  • (Although not required, we strongly recommend having a full manuscript prepared when you submit here.)
  • (Please do not submit your package separately to Methods in Ecology and Evolution)

Code of conduct

@melvidoni

This comment has been minimized.

Copy link
Collaborator

commented May 22, 2019

Editor checks:

  • Fit: The package meets criteria for fit and overlap
  • Automated tests: Package has a testing suite and is tested via Travis-CI or another CI service.
  • License: The package has a CRAN or OSI accepted license
  • Repository: The repository link resolves correctly
  • 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)?

Editor comments

Hello @PMassicotte! Thanks for submitting your package. These are the editor checks performed with goodpractice. Please take care of them. Please, address these before I can search for reviewers, or write a justification. Tag me when you are done, please!

── GP gitignore ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

It is good practice to

  ✖ write unit tests for all functions, and all package code in general. 84% of code lines are covered by test
    cases.

    R/gitignore_fetch_available_templates.R:17:NA
    R/gitignore_fetch_ignore_templates.R:50:NA
    R/gitignore_fetch_ignore_templates.R:51:NA
    R/gitignore_fetch_ignore_templates.R:55:NA
    R/gitignore_write_gitignore.R:10:NA
    ... and 1 more lines

  ✖ avoid long code lines, it is bad for readability. Also, many people prefer editor windows that are about 80
    characters wide. Try make your lines shorter than 80 characters

    R\gitignore_fetch_available_templates.R:13:1
    R\gitignore_fetch_ignore_templates.R:19:1
    R\gitignore_fetch_ignore_templates.R:40:1
    R\gitignore_fetch_ignore_templates.R:46:1
    R\gitignore_fetch_ignore_templates.R:51:1
    ... and 5 more lines

Reviewers: @maurolepore and @aedobbyn.
Due date: June 17th

@melvidoni

This comment has been minimized.

Copy link
Collaborator

commented May 23, 2019

Reviewers have been assigned: @maurolepore and @aedobbyn.
The reviews due date is June 17th.

@PMassicotte

This comment has been minimized.

Copy link
Author

commented May 23, 2019

Thank you @melvidoni. I have fixed long lines and added more tests.

@aedobbyn

This comment has been minimized.

Copy link

commented May 23, 2019

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 package and any non-standard dependencies in README
  • Vignette(s) demonstrating major functionality that runs successfully locally
  • Function Documentation: for all exported functions in R help
  • Examples for all exported functions in R Help that run successfully locally
  • Community guidelines including contribution guidelines in the README or CONTRIBUTING, and DESCRIPTION with URL, BugReports and Maintainer (which may be autogenerated via Authors@R).
For packages co-submitting to JOSS

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

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: Unit tests cover essential functions of the package
    and a reasonable range of inputs and conditions. All tests pass on the local machine.
  • Packaging guidelines: The package conforms to the rOpenSci packaging guidelines

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:

  • Should the author(s) deem it appropriate, I agree to be acknowledged as a package reviewer ("rev" role) in the package DESCRIPTION file.

Review Comments

Great idea for a package @PMassicotte and looks good to me so far! Code is succinct and readable.

A few initial thoughts:


Things to look into

  • You've got a couple of checks that overlap with each other: here and here. Seems to work fine if a list of template names is supplied as long as you check that each individually is of type character (the whole template_name will of course be of type list).

  • If copy_to_clipboard is false, gitignore is not returned to the console as it should be (according to the docs)

  • I think you need an argument for .gitignore_file in gi_fetch_ignore_templates if you want people to be able to modify a .gitignore file that doesn't live at here::here() (and then pass that path to the gi_write_gitignore line). Also on this, I might change that argument to gitignore_file instead of .gitignore_file but either way is fine.

  • The test for gi_fetch_available_templates is currently commented out. This function is used inside gi_fetch_ignore_templates so it's tested every time gi_fetch_ignore_templates is run, but an isolated test for just that function would also be good to have.


Good things

  • Tested in R GUI, also works fine (sans the crayon coloring, as expected)

  • Love the use of here, glue, and crayon; makes code very readable!


Things to consider

  • The API returns gitignore results in alphabetical order. You may want to sort these based on the order supplied by the user.

  • If the user's .gitignore file doesn't exist and append_gitignore is true, you might consider creating a .gitignore at here::here() and writing to it, possibly by prompting the user at the console to make sure they want to create and write a .gitignore

  • You might consider shortening the function names to just list_available and fetch_template, or something to that effect


Random

  • For @maurolepore: just a note that you'll need latest version of testthat for expect_invisible (line 10) in test-gitignore_fetch_ignore_templates.R (earlier versions of testthat don't have that function)
@PMassicotte

This comment has been minimized.

Copy link
Author

commented May 24, 2019

Thank you very much! I will work on that.

@PMassicotte

This comment has been minimized.

Copy link
Author

commented May 24, 2019

Dear @aedobbyn I have made all the changes you suggested except the one about the order supplied by the user. I am currently just using the API as is. The other option if so make 1 call for each template (using lapply) and then combine the results. However, this will create many calls to the API instead of just one. Happy to hear your recommendations!

@aedobbyn

This comment has been minimized.

Copy link

commented May 25, 2019

Looks good!

I agree it's best to make one call to the API instead of multiple. What you could do if you want to sort the results is to do a regex search for the language in between three ###s since those always signal the beginning of a new language template and sort based on that. You could even separate each language into an element of a list and return the list. But this is all super optional :)

Small thing I just noticed is that this line in the docs references an old, longer function name and doesn't include a link (\link{}) to that function's documentation, which I think is always useful.

@PMassicotte

This comment has been minimized.

Copy link
Author

commented May 26, 2019

Thank you @aedobbyn. I like your idea, I will work on it. Also, good catch with the old function name! I will change it!

@maurolepore

This comment has been minimized.

Copy link

commented May 28, 2019

@PMassicotte, thanks for submitting your great work. Here is my review. With it, I intend to help you make it even more awesome. Some of my comments may no longer be relevant, as you seem to have already incorporated @aedobbyn's comments. Please let me know what questions you have.

Thanks @melvidoni, @aedobbyn, and @noamross for following this
discussion. I value your experience. Please do let me know anything you
think could better serve @PMassicotte, you, or rOpenSci. For your
record, so far I invested about 5.5 hours.

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
    package and any non-standard dependencies in README
  • Vignette(s) demonstrating major functionality that runs
    successfully locally
  • Function Documentation: for all exported functions in R help
  • Examples for all exported functions in R Help that run
    successfully locally
  • Community guidelines including contribution guidelines in
    the README or CONTRIBUTING, and DESCRIPTION with URL, BugReports
    and Maintainer (which may be autogenerated via Authors@R).
For packages co-submitting to JOSS

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

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: Unit tests cover essential functions of the
    package and a reasonable range of inputs and conditions. All tests
    pass on the local machine.
  • Packaging guidelines: The package conforms to the rOpenSci
    packaging guidelines

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

  • Should the author(s) deem it appropriate, I agree to be
    acknowledged as a package reviewer (“rev” role) in the package
    DESCRIPTION file.

General comments

  • Does the code comply with general principles in the Mozilla
    reviewing guide?

Mostly yes. I fail to see is whether or not this package reinvents the
wheels. It will help to document why this packages is useful and who is
the target audience.

  • Does the package comply with the rOpenSci packaging guide?

Mostly yes, but see Review Comments.

  • Are there improvements that could be made to the code style?

Yes, see Review Comments.

  • Is there code duplication in the package that should be reduced?

I don’t think so.

  • Are there user interface improvements that could be made?

    • In gi_fetch_ignore_templates(), is the argument
      copy_to_clipboard useful enough to justify itself?

    • In the signature of gitignore::gi_write_gitignore(), I see
      .gitignore_file = here::here(".gitignore"). This feels like a
      low level detail that might be better to hide from users. Have
      you considered using .gitignore_file = NULL and handling the
      details in the function’s body?

  • Are there performance improvements that could be made?

No – as far as I can tell.

  • Is the documentation (installation
    instructions/vignettes/examples/demos) clear and sufficient? Does it
    use the principle of multiple points of entry i.e. takes into
    account the fact that any piece of documentation may be the first
    encounter the user has with the package and/or the tool/data it
    wraps?

Mostly yes, but see Review Comments.

  • Were functions and arguments named to work together to form a
    common, logical programming API that is easy to read, and
    autocomplete?

Yes, although the naming could be improved to better reflect intent. See
Review Comments.

  • If you have your own relevant data/problem, work through it with the
    package. You may find rough edges and use-cases the author didn’t
    think about.

Review Comments

Documentation

  • Statement of need … target audience in README. In README I see
    what I can do with the gitignore package but not why. Neither I
    clearly see if it is for me. Can you please state explicitly the
    problem gitignore solves and the target audience?

  • Installation instructions. Are the instructions to install from
    CRAN useful right now?

  • Vignette(s) … that runs successfully locally. Please help me. I
    can’t access the vignette locally. What am I missing?

browseVignettes("gitignore")
#> No vignettes found by browseVignettes("gitignore")
  • Community guidelines including contribution guidelines in the
    README or CONTRIBUTING
    . In README I see a link to
    CODE_OF_CONDUCT.md but no details on how to contribute. Do you
    need something like usethis::use_tidy_contributing()

Functionality

  • Installation succeeds as documented.
    install.packages("gitignore") will fail until published on CRAN.
    Do you need this right now?
install.packages("gitignore")
#> Installing package into 'C:/Users/LeporeM/Documents/R/win-library/3.6'
#> (as 'lib' is unspecified)
#> Warning: package 'gitignore' is not available (for R version 3.6.0)
  • Automated tests … cover … conditions.

Can your tests cover all if() statements? For example:

Can you handle error messages with dedicated functions such as stop(),
rlang::abort(), and usethis::ui_stop()?

# Good
expect_error(usethis::ui_stop("oh nooo!"))
#> Error in expect_error(usethis::ui_stop("oh nooo!")): could not find function "expect_error"
# Bad
expect_error(cat(crayon::red(clisymbols::symbol$bullet), "oh nooo!"))
#> Error in expect_error(cat(crayon::red(clisymbols::symbol$bullet), "oh nooo!")): could not find function "expect_error"
  • The package conforms to the rOpenSci packaging guidelines. Based
    on my understanding of the Packaging
    guide
    I make
    some suggestions under Details.

Details

Function and argument naming
  • In gi_fetch_available_templates() I see

Description
This return list of all operating systems, IDE or programming
languages supported by gitignore.io.

The function name does not reflect its description.
(fetch_available_operating_systems(), for example, reflects the
description more accurately–but of course it doesn’t capture the case
when the output refers to an IDE or programming language.)

  • In gi_write_gitignore() I see

new_lines Template returned by ‘gi_fetch_ignore_templates()’.

Why not template or fetched_template?

gitignore_file Path of the .gitignore file to modify.

Why not path?

Console messages

gi_fetch_ignore_templates("R") Prints messages via cat(). Can you
use dedicated functions to handle conditions?

Style
  • When styling code, consider using this style instead of ‘this
    style’, for example, not ‘gi_fetch_ignore_templates()’ but
    gi_fetch_ignore_templates().)

  • Try to keep lines to a maximum of 80 characters, including in
    DESCRIPTION (see usethis::use_tidy_description()).

  • Can you rename files in R/ and thestthat/tests/ to match the name of
    each main function? (I see that
    R/gitignore_fetch_available_templates.R and
    testthat/tests/test-gitignore_fetch_available_templates.R contain
    the source and tests for the function
    gi_fetch_available_templates().)

REAMDE
  • Can you please add links to vignettes?
  • For package development, the usethis package populates .gitignore as
    needed. Is this close enough to what the gitignore package does to
    mention usethis in README?
  • The examples show no output. Can you show what the user should
    expect to happen?
Documentation
  • Can you please add an example for gi_write_gitignore()?

  • Can you clarify #' @return values?

All functions should document the type of object returned under
the @return heading.
https://ropensci.github.io/dev_guide/building.html#building

In gi_fetch_available_templates() I see:

Value
A character vector with all operating systems, IDE or programming
languages supported by gitignore.io.

But the returned value is of type character. Referring to it as a list
may be confusing.

# Returns a character string
typeof(gi_fetch_available_templates())
#> [1] "character"
  • Can you please add top-level documentation?

The package should contain top-level documentation for ?foobar, (or
?foobar-package if there is a naming conflict) …
usethis::use_package_doc() adds the template for the top-level
documentation.
https://ropensci.github.io/dev_guide/building.html#building

  • The vignettes does explain how to use the package but not why. It
    lacks motivation. What is the use case?

The package should contain at least one vignette (…) illustrating
realistic use cases.
https://ropensci.github.io/dev_guide/building.html#building

If your package connects to a … online service … it should provide
enough information for users to understand the nature of the …
service. (…). Any vignette should outline prerequisite knowledge to be
able to understand the vignette upfront.
https://ropensci.github.io/dev_guide/building.html#building

Documentation website
  • Will buildignore have a website? (see
    ?pkgdown::deploy_site_github()).
Package dependencies

The number of dependencies seems high relative to the number of
features. Have you considered the trade-offs explained
here?

Miscellaneous CRAN gotchas

In DESCRIPTION:

  • Please ensure Title: uses title case.
  • Please enclose links in <angle brackets>.
  • Please ensure lines are 80 characters or shorter.
@PMassicotte

This comment has been minimized.

Copy link
Author

commented May 28, 2019

Thank you @maurolepore I started to address your comments.

@PMassicotte

This comment has been minimized.

Copy link
Author

commented May 30, 2019

@maurolepore @aedobbyn Can I add you as "rev" in the DESCRIPTION file?

@aedobbyn

This comment has been minimized.

Copy link

commented May 30, 2019

Of course!

@maurolepore

This comment has been minimized.

Copy link

commented May 31, 2019

@PMassicotte

This comment has been minimized.

Copy link
Author

commented May 31, 2019

Hi @melvidoni! I just finished my corrections based on @maurolepore suggestions. The only thing I was not able to address is the test to cover the line he highlighted. This is because, based on the first suggestion of @maurolepore, the package is now asking the user if he/she wants to create the missing .gitignore file. This is done with the menu() function for which I could not find a solution to test it automatically. I am open to any suggestions!

@aedobbyn

This comment has been minimized.

Copy link

commented May 31, 2019

Since it's interactive and tough to test in a non-interactive way, I think you'd be fine wrapping it in nocov comments. If anyone has an idea about how to construct a test for it, of course that is even better.

@PMassicotte

This comment has been minimized.

Copy link
Author

commented May 31, 2019

Thank you for the tip @aedobbyn. I have reached 100% coverage!

@melvidoni

This comment has been minimized.

Copy link
Collaborator

commented Jun 2, 2019

Great @PMassicotte! What do you think, @maurolepore and @aedobbyn?

@maurolepore

This comment has been minimized.

Copy link

commented Jun 3, 2019

@melvidoni,

@PMassicotte, has responded to my review and made changes to my satisfaction. I recommend approving this package.

--

Although I don't need to see it again, I still have the following recommendations:

  • Provide the website's link (http://www.pmassicotte.com/gitignore/) in the GitHub repo.
  • Link .github/CONTRIBUTING.md from README.
  • Reflow documentation lines to 80 characters or less.
  • Rename files to reflect the name of the main function they contain.
@aedobbyn

This comment has been minimized.

Copy link

commented Jun 17, 2019

Things are looking good @PMassicotte! Question -- is there a reason you're no longer exporting gi_write_gitignore?

@PMassicotte

This comment has been minimized.

Copy link
Author

commented Jun 17, 2019

Oups, good call @aedobbyn. Fixed it!

@aedobbyn

This comment has been minimized.

Copy link

commented Jun 17, 2019

Don't you need

stopifnot(basename(gitignore_file) == ".gitignore") instead of !=

here? This seems to error when the basename of the file is .gitignore.

@melvidoni

This comment has been minimized.

Copy link
Collaborator

commented Jun 17, 2019

@PMassicotte Can you address @aedobbyn's question?
Please, @aedobbyn let us know when you think the package is ready.

@PMassicotte

This comment has been minimized.

Copy link
Author

commented Jun 18, 2019

Good catch again @aedobbyn! Just fixed it.

@aedobbyn

This comment has been minimized.

Copy link

commented Jun 18, 2019

Nice, looks good! I think once you include some examples in your readme and pkgdown this will be good to go.

@PMassicotte

This comment has been minimized.

Copy link
Author

commented Jun 18, 2019

Hi @aedobbyn You would like more examples?

https://github.com/PMassicotte/gitignore

@aedobbyn

This comment has been minimized.

Copy link

commented Jun 18, 2019

Sorry I should have been more specific -- more examples of gi_write_gitignore now that's it's been exported.

@PMassicotte

This comment has been minimized.

Copy link
Author

commented Jun 18, 2019

There we go, I have added an example in the REAMDE!

@melvidoni

This comment has been minimized.

Copy link
Collaborator

commented Jun 18, 2019

Thanks for adding them, @PMassicotte! What do you think, @aedobbyn ?

@aedobbyn

This comment has been minimized.

Copy link

commented Jun 19, 2019

Looks good to me!

@melvidoni

This comment has been minimized.

Copy link
Collaborator

commented Jun 19, 2019

Approved! Thanks @PMassicotte for submitting and @aedobbyn and @maurolepore for your reviews!

To-dos:

  • Transfer the repo to rOpenSci's "ropensci" GitHub organization under "Settings" in your repo. I have invited you to a team that should allow you to do so. You'll be made admin once you do.
  • Add the rOpenSci footer to the bottom of your README
[![ropensci_footer](https://ropensci.org/public_images/ropensci_footer.png)](https://ropensci.org)
  • Fix any links in badges for CI and coverage to point to the ropensci URL. We no longer transfer Appveyor projects to ropensci Appveyor account so after transfer of your repo to rOpenSci's "ropensci" GitHub organization the badge should be [![AppVeyor Build Status](https://ci.appveyor.com/api/projects/status/github/ropensci/pkgname?branch=master&svg=true)](https://ci.appveyor.com/project/individualaccount/pkgname).
  • We're starting to roll out software metadata files to all ropensci packages via the Codemeta initiative, see https://github.com/ropensci/codemetar/#codemetar for how to include it in your package, after installing the package - should be easy as running codemetar::write_codemeta() in the root of your package.
  • Activate Zenodo watching the repo
  • Tag and create a release so as to create a Zenodo version and DOI

Should you want to acknowledge your reviewers in your package DESCRIPTION, you can do so by making them "rev"-type contributors in the Authors@R field (with their consent). More info on this here.

Welcome aboard! We'd love to host a blog post about your package - either a short introduction to it with one example or a longer post with some narrative about its development or something you learned, and an example of its use. If you are interested, review the instructions, and tag @stefaniebutland in your reply. She will get in touch about timing and can answer any questions.

We've started putting together a gitbook with our best practice and tips, this chapter starts the 3d section that's about guidance for after onboarding. Please tell us what could be improved, the corresponding repo is here.

@PMassicotte

This comment has been minimized.

Copy link
Author

commented Jun 20, 2019

I transferred it. I am trying to find how to make codecov and appveyor work now :)

@melvidoni

This comment has been minimized.

Copy link
Collaborator

commented Jun 20, 2019

@PMassicotte Just added you to the team. Please, tackle all the To-Dos pointed out on my previous comment.

@PMassicotte

This comment has been minimized.

Copy link
Author

commented Jun 20, 2019

Badges have been added and a release has been done (with Zenodo badge).

@PMassicotte

This comment has been minimized.

Copy link
Author

commented Jun 20, 2019

Codemetar has been used too! Anything else to do on my side?

@melvidoni

This comment has been minimized.

Copy link
Collaborator

commented Jun 20, 2019

It is fine for now @PMassicotte!

@PMassicotte

This comment has been minimized.

Copy link
Author

commented Jun 20, 2019

Thank you very much @melvidoni @aedobbyn and @maurolepore for making the review process smooth and fun!

@maurolepore

This comment has been minimized.

Copy link

commented Jun 20, 2019

Thanks to you @PMassicotte. I look forward to seeing your package out in the wild

@aedobbyn

This comment has been minimized.

Copy link

commented Jun 21, 2019

Congrats @PMassicotte !

@maurolepore

This comment has been minimized.

Copy link

commented Jun 21, 2019

@PMassicotte, next week I'll be volunteering most of my time to work on open source projects. If you need a hand in this project let me know -- maybe it's time to work towards a CRAN submission?

@PMassicotte

This comment has been minimized.

Copy link
Author

commented Jun 21, 2019

Sure, that would be nice! Anything missing at this point for the submission?

@maurolepore

This comment has been minimized.

Copy link

commented Jun 21, 2019

@PMassicotte,
If you mean for the submission to CRAN, then I think a good way to know what might be missing is to walk throught the list produced via usethis::use_release_issue() and devtools::release().

I would also recommend to configure .travis.yml to check on multiple versions of R.

I could help with this next week.

@maurolepore

This comment has been minimized.

Copy link

commented Jun 21, 2019

BTW, this address resonds with error 404: https://www.pmassicotte.com/gitignore/

I guess it will eventually be https://docs.ropensci.org/gitignore/?

image

@stefaniebutland

This comment has been minimized.

Copy link

commented Jun 25, 2019

@PMassicotte Your docs page is up now https://docs.ropensci.org/gitignore/ so you can update the repository URL :-)

@PMassicotte

This comment has been minimized.

Copy link
Author

commented Jun 25, 2019

@stefaniebutland I have updated the URL on the github page and also in the README. I also provided instruction to install it from ropensci devtools::install_github("ropensci/gitignore").

@PMassicotte

This comment has been minimized.

Copy link
Author

commented Jun 28, 2019

Accepted on CRAN!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.