lingtypology: easy mapping for Lingustic Typology
agricolamz opened this issue · comments
Summary
-
What does this package do? (explain in 50 words or less):
Provides R with the Glottolog database http://glottolog.org and some more abilities for purposes of linguistic mapping. The Glottolog database contains the catalogue of languages of the world. This package helps researchers to make a linguistic maps, using philosophy of the Cross-Linguistic Linked Data project http://clld.org/, which allows for while at the same time facilitating uniform access to the data across publications. A tutorial for this package is available on GitHub pages https://agricolamz.github.io/lingtypology/ and package vignette. -
Paste the full DESCRIPTION file inside a code block below:
Package: lingtypology
Type: Package
Title: Linguistic Typology and Mapping
Version: 1.0.1
Depends: R (>= 2.10)
Imports:
leaflet,
stats,
stringdist,
magrittr,
grDevices,
rowr
Author: George Moroz
Maintainer: George Moroz <agricolamz@gmail.com>
Description: Provides R with the Glottolog database <http://glottolog.org> and some more abilities for purposes of linguistic cartography. The Glottolog database contains the catalogue of languages of the world. This package helps researchers to make a linguistic maps, using philosophy of the Cross-Linguistic Linked Data project <http://clld.org/>, which allows for while at the same time facilitating uniform access to the data across publications. A tutorial for this package is available on GitHub pages <https://agricolamz.github.io/lingtypology/> and package vignette.
License: GPL (>= 2)
URL: https://CRAN.R-project.org/package=lingtypology, https://github.com/agricolamz/lingtypology/
LazyData: TRUE
RoxygenNote: 5.0.1
Suggests:
knitr,
rmarkdown
VignetteBuilder: knitr
-
URL for the package (the development repository, not a stylized html page):
lingtypology -
Who is the target audience?
Linguists, Linguistic typologists -
Are there other R packages that accomplish the same thing? If so, what is different about yours?
No, as far as I know
Requirements
Confirm each of the following by checking the box. This package:
- does not violate the Terms of Service of any service it interacts with.
- has a CRAN and OSI accepted license.
- contains a README with instructions for installing the development version.
- includes documentation with examples for all functions.
- contains a vignette with examples of its essential functions and uses.
- has a test suite.
- has continuous integration with Travis CI and/or another service.
Publication options
- Do you intend for this package to go on CRAN?
Yes - Do you wish to automatically submit to the Journal of Open Source Software? If so:
- The package contains a
paper.mdwith a high-level description in the package root or ininst/. - The package is deposited in a long-term repository with the DOI:
- (Do not submit your package separately to JOSS)
- The package contains a
Detail
-
Does
R CMD check(ordevtools::check()) succeed? Paste and describe any errors or warnings: -
Does the package conform to rOpenSci packaging guidelines? Please describe any exceptions:
- I use not.snake.style function names. Sorry.
- I didn't provide example usage in my README.md, but I added a link to detailed tutorial.
-
If this is a resubmission following rejection, please explain the change in circumstances:
-
If possible, please provide recommendations of reviewers - those with experience with similar packages and/or likely users of your package - and their GitHub user names:
Thank you for your submission @agricolamz
Editor checks:
- Fit: The package meets criteria for fit and overlap
- Automated tests: yes
- License: The package has a CRAN or OSI accepted license
- Repository: The repository link resolves correctly
- Archive (JOSS only, may be post-review): NA
- Version (JOSS only, may be post-review): NA
Editor comments
Currently seeking reviewers. It's a good fit and not overlapping.
- Ran
goodpractice::gp()- here's a few things to think about - we suggest following these suggestions
It is good practice to
✖ add a "BugReports" field to DESCRIPTION, and point it to
a bug tracker. Many online code hosting services provide bug
trackers for free, https://github.com, https://gitlab.com, etc.
✖ 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/aff.lang.R:14:1
R/aff.lang.R:16:1
R/area.lang.R:14:1
R/area.lang.R:16:1
R/country.lang.R:16:1
... and 58 more lines
✖ avoid sapply(), it is not type safe. It might return a
vector, or a list, depending on the input data. Consider using
vapply() instead.
R/aff.lang.R:15:3
R/area.lang.R:15:3
R/country.lang.R:18:10
R/is.glottolog.R:28:5
R/iso.lang.R:15:3
... and 5 more lines
✖ not import packages as a whole, as this can cause name
clashes between the imported packages. Instead, import only the
specific functions you need.
✖ avoid 'T' and 'F', as they are just variables which are
set to the logicals 'TRUE' and 'FALSE' by default, but are not
reserved words and hence can be overwritten by the user. Hence,
one should always use 'TRUE' and 'FALSE' for the logicals.
R/is.glottolog.R:NA:NA
R/map.feature.R:NA:NA
R/map.feature.R:NA:NA
R/map.feature.R:NA:NA
R/map.feature.R:NA:NA
... and 8 more linesReviewers: @timelyportfolio (due: 2017-03-09) @tzakharko (due: 2017-03-13)
Dear @sckott,
Thank you for your comment. I hope it will take me two days to sort it out.
thank you
Dear @sckott ,
I tried testthat multiple times, but all the time it returns
'source_test_helpers' is not an exported object from 'namespace:testthat'
linux mint
RStudio 1.0.136
testthat 0.8.1
Do you know what should I do? Actually it is the third time, when I try to start use testthat...
@agricolamz can you put what you've tried on a different branch from master so I can try to help
Hi, @sckott!
I created the test suit. But I still cannot build a package with my tests since I can't install the last version of testthat. And I cannot make covr work the way I expect. But... It is better than nothing. It is awful that I should remove my tests from the package folder to be able build it with devtools, but I spent a lot of time trying to fix it. It works well on Travis.
Can you help me with that? Can you see tests and tell me that it is what you've expected from me?
What do you mean you can't build it? I'm not sure what that refers to.
Can you show me the errors that happen when trying to install latest testthat?
Also, in your testthat.R file you should use test_check instead of test_package and the devtools::build(quiet = T) should be removed
Dear @sckott ,
here is a long version of my answer.
I changed testthat.R. It still doesn't work on my PC, but travis and codecov make it work correctly!
Sorry for delay @agricolamz - was traveling and back now, having a look over this
@agricolamz Let's move forward with review - you have tests now and at least they run on travis and they run fine for me as well - I'll kick off process looking for reviewers
I'll help with your machine's setup soon
Dear @timelyportfolio,
Thank you for your comments! Since goodpractice depends on some version of testthat I cannot check my package by myself (see the comments above).
- BugReports added
sapplychanged tovapply- in most cases
@importchanged to@importFrom TandFchanged toTRUEandFALSE- I tried to change line length by myself, then I used
formatRpackage, but there are still a lot of long lines...
Thanks @agricolamz
2nd reviewer assigned: @tzakharko - Thanks for reviewing Taras!
Dear @sckott , @tzakharko and @timelyportfolio. I added an additional arguments and rewrote the main function map.feature. So code coverage now is 98%!
just a short message to @timelyportfolio and @tzakharko your reviews are due soon 😸 - thx for reviewing!
@agricolamz working through a full review and very nicely done. First suggestion, add Date in DESCRIPTION. I think it is good practice but will also remove this warning.
## Warning in citation("lingtypology"): no date field in DESCRIPTION file of
## package 'lingtypology'
I felt like the review should go in the lingtypology issues, so I have put it ropensci/lingtypology#9. @agricolamz, really well done, and far smoother than I expected. I appreciate your efforts. Please let me know if I can help in any additional way!
I should also add some context to my tests.
> devtools::session_info()
Session info ------------------------------------------------------------------
setting value
version R version 3.3.1 (2016-06-21)
system x86_64, mingw32
ui RStudio (1.1.68)
language (EN)
collate English_United States.1252
tz America/Chicago
date 2017-03-08
Packages ----------------------------------------------------------------------
package * version date
assertthat 0.1 2013-12-06
bindr 0.1 2016-11-13
bindrcpp * 0.1 2016-12-12
colorspace 1.2-6 2015-03-11
crayon 1.3.2 2016-06-28
crosstalk 1.0.1 2017-01-09
DBI 0.5-1 2016-09-10
devtools 1.12.0 2016-06-24
digest 0.6.9 2016-01-08
dplyr * 0.5.0.9000 2017-01-05
htmltools 0.3.6 2016-10-24
htmlwidgets 0.8 2016-11-10
httpuv 1.3.3 2015-08-04
jsonlite 1.2 2016-12-31
lazyeval 0.2.0.9000 2016-07-04
leaflet 1.0.2.9010 2017-01-26
lingtypology * 1.0.3 2017-03-08
magrittr 1.5 2014-11-22
markdown 0.7.7 2015-04-22
memoise 1.0.0 2016-01-29
mime 0.5 2016-07-07
munsell 0.4.3 2016-02-13
plyr 1.8.4 2016-06-08
R6 2.2.0 2016-10-05
RColorBrewer 1.1-2 2014-12-07
Rcpp 0.12.9.1 2017-01-31
rowr 1.1.3 2016-12-22
scales 0.4.1.9000 2016-11-21
shiny 0.14.2.9001 2017-01-09
stringdist 0.9.4.4 2016-12-16
testthat * 1.0.2 2016-04-23
tibble 1.2-15 2017-01-10
withr 1.0.2 2016-06-20
xtable 1.8-2 2016-02-05
yaml 2.1.14 2016-11-12
source
CRAN (R 3.2.5)
CRAN (R 3.3.2)
Github (krlmlr/bindrcpp@0208bd4)
CRAN (R 3.2.4)
CRAN (R 3.2.5)
Github (rstudio/crosstalk@6a36da1)
CRAN (R 3.3.1)
CRAN (R 3.3.2)
CRAN (R 3.2.4)
Github (hadley/dplyr@03bba6a)
Github (timelyportfolio/htmltools@c7e601a)
local
CRAN (R 3.2.5)
CRAN (R 3.3.2)
Github (hadley/lazyeval@c155c3d)
Github (rstudio/leaflet@cbb3495)
local
CRAN (R 3.3.1)
CRAN (R 3.2.5)
CRAN (R 3.2.4)
CRAN (R 3.3.2)
CRAN (R 3.2.4)
CRAN (R 3.2.5)
CRAN (R 3.3.1)
CRAN (R 3.2.3)
Github (rcppcore/rcpp@d05d9c6)
CRAN (R 3.3.2)
Github (hadley/scales@89c2a2f)
Github (rstudio/shiny@d836c68)
CRAN (R 3.3.3)
CRAN (R 3.2.5)
Github (hadley/tibble@3d6f8b4)
CRAN (R 3.2.5)
CRAN (R 3.2.4)
CRAN (R 3.3.2)
@timelyportfolio please put the review here in a new comment. thanks
linqtypology review
author: "Kenton Russell"
date: "March 8, 2017"
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 (such as being a major contributor to the software).
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
URL,MaintainerandBugReportsfields in DESCRIPTION
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: 4
Review Comments
-
Very thorough and well-written package with some quite nifty usage of
leaflet. -
Add
DateinDESCRIPTIONas suggested in comment -
Add a quick example for
makelink. Can be as simple asmakelink("Adyghe"). Well done adding examples for all documented functions! -
Get 100% coverage :) So close, and to get there might be as simple as adding to
test-lang-country.R. However, I could easily be mistaken.expect_equal(lang.country(list("North Korea", "Lebanon")), c("Korean", "English", "French", "Assyrian Neo-Aramaic", "Northern Kurdish", "Armenian", "North Levantine Arabic", "Turoyo", "Chaldean Neo-Aramaic", "Standard Arabic", "Pidgin Madam")) -
Optional, but style code according to a styleguide (does ROpenSci have one?) to make more readable.
One other question, what is the difference between languoids and linguoids? Should this be consistent? For instance ?lang.iso versus ?map.feature.
thanks for your review @timelyportfolio !!!
Thanks a lot for your review @timelyportfolio !
There is only one problem that I can't satisfy: to get 100% coverage I should provide some testing of length mismatch between tiles and tile names. I wrote these tests but they don't work. Now I put them as a comment here.
I tried to find out some code style sheet. But after all I just used formatR package.
Languoid is appropriate. Changed everywhere I found.
Everything else --- done!
@tzakharko please get your review in, deadline was about 1 week ago
Review of package lingtypology
This review is for the lingtypology version 1.02, as available on CRAN at the moment of the review. The review has been jointly carried out by a geographer and a linguist/programmer.
- As the reviewer we confirm that there are no conflicts of interest for us to review this work (such as being a major contributor to the software).
The package pursues two main goals: on one hand, to offer some basic querying functionality of Glottolog language catalogue, and on the other hand, provide simple CLLD-style interactive mapping functionality leveraging the Leaflet library. In addition to the vanilla Glottolog 2.7 database, the package includes a custom author-edited version of the database (the changes are documented in the package vignette).
The Glottolog querying interface consists of a family of functions specialised in a single task (e.g. a function that maps language names to its genealogical affiliation, a function that maps language ISO-code to language names etc.). We liked the thought the author put into making the names of the functions regular and predictable (they all follow the same RESULT.SOURCE naming schema), even though we are wondering whether this approach can lead to increased namespace pollution as new query functionality is added in the future. A single unified querying function might have been a more elegant solution. A shortcoming of the querying interface is that it only provides one bit of information at a time. If one wants to create a data frame containing, say, both coordinates and the area name, one has to write quite a lot of boilerplate. This also means that the package poorly integrates with existing powerful data transformation tools for R such as dplyr, tidyr and others. Overall, the reviewers feel conflicted about the utility of the querying functionality, as the same can be achieved using a data frame containing Glottolog data with state-of-the-art R tools, with comparable effort and much more flexibility.
We were puzzled by the fact, that the author of the package chose not to expose the languoid codes used by the Glottolog database (glottocodes). What is exposed is language name (which, as noted by the author himself, is often ambiguous) as well as the ISO-code (which have a lot of limitations, furthermore, its not clear which version of ISO is used). This makes it impossible to use the package with many modern typological datasets, which usually include glottocode mappings. Also, it needs mentioning that the way the author uses the term languoid differs from Glottolog's terminology, which can be potentially very confusing to a user. In common linguistic terminology (and explicitly so in Glottolog) languoid refers to any relevant group of linguistic varieties (e.g. dialects, languages, language families and so on). The package, however, appears to restrict this to language level only.
The second important area of functionality of the package is creating interactive maps about languages. Here, the package offers a light wrapper over the Leaflet for R package. This wrapper integrates with the Glottolog database for querying language coordinates, but can be also used separately, with user-provided data. In the package documentation, the author uses both the terms "cartography" and "mapping". At the same time, the package lacks important features associated with full-featured cartographic maps (orientation, projection, etc.). It does not seem possible to visualise continuous or ordered data (ratios, counts etc.). Furthermore, we were not able to find an option to display a Pacific-centered map by default, which is a common task for creating maps in linguistic typology.
In summary, we believe that the strength of the package lies in quick access to Glottolog as well as the ability to quickly create simple maps, which would make it great for teaching and quick illustrations. However, this comes at a great cost of flexibility. In particular, linguists who work with complex databases will most likely find the features of the package to be too limited and are almost always better off using packages such as dplyr and leaflet/ggmap directly.
General recommendations
-
We strongly suggest the author to change the name of the package to better reflect its purpose and functionality. The name
lingtypologysuggests that the package focuses on general issues in typology. This is clearly not the case. -
It would make sense to provide better access to the underlaying Glottolog data: expose glottocodes, allow one to query the list of languages present in the database etc. (note: the development version does expose the Glottolog tables, which is great)
-
The author uses the term "languoid" where he actually means "language". The documentation should be modified accordingly.
-
Consider replacing the family of query functions by a unified interface to avoid namespace pollution.
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
URL,MaintainerandBugReportsfields in DESCRIPTION
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.
Additional comments
- The name
makelink()clashes with the standardstatsfunctionmake.link() makelink()does not do any data validation, creating invalid links for invalid language names without warning- Its a bit awkward that the color assignment in
map.feature()is random by default. Is there any valid use case for that? - The author uses both terms "mapping" and "cartography". This is confusing, especially since the package does not provide any functionality for creating cartographic maps.
- The package description in DESCRIPTION and README are different. One states that the "Provides [...] some [...] abilities for purposes of linguistic cartography" and another "[...] provides additional functionality for linguistic typology". Both are somewhat misleading.
- We were unable to locate the contribution guidelines
@sckott @agricolamz Sorry about the delay, we wanted to take a bit more time to write a proper review and also we were two people which meant more coordination effort!
@timelyportfolio and @tzakharko thanks for your reviews!
@tzakharko we'd love to give your other reviewer credit - do they have a github account?
@sckott Sure, its @languageSpaceLabs, sorry for not mentioning it earlier. Thanks!
thanks @tzakharko !
@tzakharko do you have an estimate of how many hrs the review took?
@tzakharko do you have an estimate of how many hrs the review took?
@agricolamz Both reviews in - let me know if you have any questions
@sckott Thank you. I've made a lot of changes, so I'll write, when all comments from reviews will be satisfied. Now I'm in a fieldwork, so I'll write at the mid of April. Greetings from Daghestan.
thanks @tzakharko
Dear @sckott, @languageSpaceLabs, @tzakharko and @timelyportfolio!
I've made a lot of changes: most of them are on CRAN, some of them are not.
- I decided to keep functions of
Result.Sourcestyle. That is because for that people who is new to R that functions are more intuitive than core R functions. I even added some more functions of that type (for glottolog codes). - I agree that I can leave users with dataframe (or anything else), so they can make any query by themselves using base R functions or
tidyverse. I increased a database and now it contains a lot of information from Glottolog (e. g. information about writing systems, about number of speakers and so on), but I don't think that all that new columns are on every day need for the users. All Glottolog database versions that are used inlingtypologyare available for simple search. - I agree that absence of glottocodes in any version of Glottolog database is something strange. So I added them to the databases used in
lingtypology. And I added some function for searching using glottocodes. - When I started doing that package I had idea that languoid term let me use one word for language and dialect,but for my today purposes I agree with the reviewers: it can be changed to language. So I changed it everywhere in documentation.
- I used "cartography" and "mapping" as synonyms. Now I change all “cartography” to “mapping” in whole documentation.
- In the last version (on CRAN) it is possible to visualise continuous or ordered data.
- Actually there was an option to create a Pacific-centered maps. But it have not been described anywhere. In the last version I made Pacific-centerd maps as a default one and added the argument that makes Atlantic-centered maps.
- The main goal of my package is to create a tool that makes easy to create linguistic maps. I'm agree that for the linguists who work with complex databases it is too limited. Map is really nice visualisation, so there should be a tool that allows you to write one or two lines of code for creating fast linguistic visualisation. I've seen a lot of linguists that don't do this type of visualisation only because of the programming pain. So I'm pretty sure that
lingtypologyis not only “for teaching and quick illustrations”. It can be used in scientific articles on typology, dialectology and contact linguistics. - Unfortunately I'm not convinced that the name of the package should be changed. The main idea of the package: give me a vector of languages, give me a vector of features and I color them for you! I know that linguistic typology is not about dividing languages into types. I think about typology as a program of the investigation linguistic diversity of the world. In that cases linguistic maps is a really nice way to visualise that diversity.
- make.link() is changed to url.lang().
- I added validation for url.lang() and for languages (actually, langouids) that have no coordinates. So all created links should be correct and no unmapped language comes silently.
- map.feature() coloring is fixed now. And I added more options for coloring (see tutorial).
As a conclusion, I would like to thank my reviewers. I'm really appreciate time that you've spent on my package. I really happy that I learn new nice ideas that I partially implemented.
UPD
- 100% coverage, as @timelyportfolio wished.
- added function, that creates density estimation contour.
Thanks for all the changes @agricolamz
On check i see
* checking R code for possible problems ... NOTE
polygon.points: no visible global function definition for ‘sd’
Undefined global functions or variables:
sd
Consider adding
importFrom("stats", "sd")goodpractice highlighted the following
── GP lingtypology ─────────────────
It is good practice to
✖ omit "Date" in DESCRIPTION. It is not required and it
gets invalid quite often. A build date will be added to the package
when you perform `R CMD build` on it.
✖ 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/aff.lang.R:15:1
R/aff.lang.R:18:1
R/aff.lang.R:19:1
R/area.lang.R:15:1
R/area.lang.R:18:1
... and 129 more lines
✖ avoid 1:length(...), 1:nrow(...), 1:ncol(...),
1:NROW(...) and 1:NCOL(...) expressions. They are error prone and
result 1:0 if the expression on the right hand side is zero. Use
seq_len() or seq_along() instead.
R/polygon.points.R:29:19
✖ not import packages as a whole, as this can cause name
clashes between the imported packages. Instead, import only the
specific functions you need.
✖ fix this R CMD check NOTE: polygon.points: no visible
global function definition for ‘sd’ Undefined global functions or
variables: sd Consider adding importFrom("stats", "sd") to your
NAMESPACE file.
✖ fix this R CMD check NOTE: Note: found 132 marked UTF-8
strings
Please do make changes for the following
- Remove the Date field in DESCRIPTION
- namespace your call to
sdlikestats::sdor add to@importFrom - change the
1:lengthhere https://github.com/agricolamz/lingtypology/blob/master/R/polygon.points.R#L29 to probablyseq_along - do tidy code to 80 width, some of it may have to be done manually, but is worth it as the PDF manual on CRAN won't have text over-running the page and others that have a limited screen can read code more easily
@timelyportfolio @tzakharko no need to look over this more, but if you want to chime in on anything else do so soon
Dear @sckott,
I did all corrections. The only problem is 80 width code. I've made a lot off changes, but there are still a lot of long lines.
@agricolamz Do get line width down to 80 eventually.
Approved! Thanks very much for your submission. Remaining steps:
- I've added you to an
lingtypologyteam for the rOpenSci organization, and invited you to our org, you should get a notification. Accept and transfer the repo (under "Settings") to rOpenSci, and then update any links for CI, coverage, and documentation. - Let me know if you are interested in doing a blog post about your package on the rOpenSci blog, either long-form / for more general audience (https://ropensci.org/blog/) or short form / more technical (https://ropensci.org/tech-notes/)
Thank you, @sckott!
I've made last changes with commit is "80 character width Procrustean bed".
I transfered lingtypology to ropensci and changed links everywhere, but I have no access to repository settings, so I can't set GithubPages to \docs subfolder, and can't change a link in package website (on the top of repository page). And I'm not sure that appveyor works correctly.
Yes, I'm interested in doing a long-form post at 16 of May, when I will upload new version to CRAN. Are there any instruction, where I should post my .rmd?
Try again now on the repo
looks like that appveyor build worked
closing now as approved, but can still chat here as needed
Should I fork a repository to my github for creating a GitHub page that everybody used to look?
And I asked earlear
Yes, I'm interested in doing a long-form post at 16 of May, when I will upload new version to CRAN. Are there any instruction, where I should post my .rmd?
@agricolamz for creating a website for your package have a look at pkgdown (although I'm not sure you'll have admin rights to set the Github page source to docs/ yourself? 🤔 )
@maelle I used common html created by vigniette as an GitHub page with an adress https://agricolamz.github.io/lingtypology/. When I transfered the repo to rOpenSci, I did not have such rights (and I couldn't change the repo subtitle and set the Github page), but then @sckott have changed something and I got that rights. So I set the Github page.
The problem is actually about an old page. If I type https://github.com/agricolamz/lingtypology Github automatically redirect me to https://github.com/ropensci/lingtypology. But it doesn't work with Github pages... So the old link is broken. And my question was, should I fork my package back, for setting redirection for that link?
Oh I see and sorry I can't help you :-(
@agricolamz for the redirect problem, yeah, sounds like forking might be a way to fix that
Yes, I'm interested in doing a long-form post at 16 of May, when I will upload new version to CRAN. Are there any instruction, where I should post my .rmd?
Sorry missed this. Instructions here for contributing a post https://github.com/ropensci/roweb/blob/master/.github/CONTRIBUTING.md Let me know if you have any questions.
@agricolamz we'd want to get the post up on May 16th, so get it in day before then at latest