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

Aprendiendo programación en R con la robot Karel #620

Closed
11 of 29 tasks
mpru opened this issue Dec 28, 2023 · 55 comments
Closed
11 of 29 tasks

Aprendiendo programación en R con la robot Karel #620

mpru opened this issue Dec 28, 2023 · 55 comments
Assignees

Comments

@mpru
Copy link

mpru commented Dec 28, 2023

Date accepted: 2024-06-19
Nombre de la Persona Encargada: Marcos Prunello
Usuario GitHub de la Persona Encargada: @mpru
Repositorio: https://github.com/mpru/karel
Versión Enviada: 0.1.1.9000
Tipo de Envio: Estándar
Editora: @maurolepore
Revisores: @vjimenez9, @joelnitta

Archivo: TBD
Versión Aceptada: TBD
Idioma: es

  • Pega el archivo DESCRIPTION completo dentro del siguiente bloque de código.
Package: karel
Title: Learning programming with Karel the robot
Version: 0.1.1.9000
Authors@R: 
    person(given = "Marcos",
           family = "Prunello",
           role = c("aut", "cre", "cph"),
           email = "marcosprunello@gmail.com",
           comment = c(ORCID = "0000-0002-9611-527X"))
Description: This is the R implementation of Karel the robot, a programming 
  language created by Dr. R. E. Pattis at Stanford University in 1981. Karel is 
  an useful tool to teach introductory concepts about general programming, such 
  as algorithmic decomposition, conditional statements, loops, etc., in an 
  interactive and fun way, by writing programs to make Karel the robot achieve 
  certain tasks in the world she lives in. Originally based on Pascal, Karel 
  was implemented in many languages through these decades, including 'Java', 'C++', 
  'Ruby' and 'Python'. This is the first package implementing Karel in R.
Depends: R (>= 3.6.0)
Imports:
    purrr,
    dplyr,
    tidyr,
    ggplot2,
    magrittr,
    gganimate,
    cli
License: GPL-2
Encoding: UTF-8
LazyData: true
Language:
  en,
  es
RoxygenNote: 7.2.3
Suggests: 
    testthat (>= 3.0.0),
    knitr,
    rmarkdown
VignetteBuilder: knitr
URL: https://mpru.github.io/karel/
BugReports: https://github.com/mpru/karel/issues/
Config/testthat/edition: 3

Alcance

  • Por favor, indica qué categoría(s) aplican a este paquete. Las puedes encontrar en nuestras políticas de inclusión de paquetes (Inglés). Por favor, tilda todas las apropiadas. Si no estás seguro, te sugerimos que comiences un pre-envío.

    • recuperación de datos (data retrieval)
    • extracción de datos (data extraction)
    • munging de datos (data munging)
    • disposición o declaración de datos (data deposition)
    • validación y prueba de datos (data validation and testing)
    • automatización de flujos de trabajo (workflow automation)
    • control de versiones (version control)
    • manejo de citas y bibliometría (citation management and bibliometrics)
    • envoltorios de software científico (scientific software wrappers)
    • herramientas para trabajo de campo y reproducibilidad (field and lab reproducibility tools)
    • ligamientos con software de base de datos (database software bindings)
    • datos geoespaciales (geospatial data)
    • análisis de texto (text analysis)
  • Explica cómo y por qué el paquete encaja dentro de estas categorías (1 a 3 oraciones):

    Este paquete no entra en ninguna categoría, ya que está relacionado con Educación. Fue aceptado para el Programa Campeones, bajo la supervisión de @yabellini.

  • ¿Cuál es la audiencia esperada y las aplicaciones científicas de este paquete?

    Este paquete es utilizado por docentes para enseñar conceptos introductorios sobre programación, como descomposición algorítmica, declaraciones condicionales, bucles, etc., a estudiantes que posteriormente utilicen R como lenguaje de programación para otras tareas. Ha sido creado con un enfoque multilingüe que actualmente incluye los idiomas español e inglés, pero que puede ser expandido a otros de forma sencilla.

  • ¿Hay otros paquetes de R que logren el mismo objetivo? Si los hay, ¿cómo se diferencian del tuyo, o alcanzan nuestro criterio del mejor de su categoría (documento en Inglés)?

    No actualmente, según mi conocimiento.

  • (Si aplica) ¿Tu paquete cumple con nuestras guías de Ética, Privacidad de Datos e Investigación de Sujetos Humanos (documento en Inglés)?

    No aplica.

  • Si ya has hecho una consulta de pre-envío, por favor pega el enlace al issue correspondiente, una publicación del foro, u otra discusión. Alternativamente, etiqueta al editor (con @tag) con el que te contactaste.

    No realicé consulta de pre-envío.

  • (Si aplica) Explique las razones de los elementos pkgcheck que su paquete no puede pasar.

    pkgcheck pasa cuando lo ejecuto localmente. He observado dos advertencias en el CI, pero creo que están relacionadas con pkgcheck y GitHub Actions, y no relacionadas directamente con mi paquete. En cuanto al estilo, obtengo la sugerencia de evitar largas líneas de código. Sin embargo, las únicas líneas de código que superan los 80 caracteres de ancho corresponden a cadenas de texto con mensajes en diferentes idiomas para los usuarios, dentro de las cuales prefiero no incluir saltos de línea.

Revisiones Técnicas

Tilda los siguientes items para confirmar que los has completado:

Este paquete:

Opciones de Publicación

Opciones para MEE
  • Este paquete es novedoso y será de interés para la mayoría de lectores de la revista.
  • El manuscrito que describe el paquete no tiene más de 3000 palabras y está escrito en Inglés.
  • Tienes intenciones de archivar el código del paquete en un repositorio a largo plazo, que cumple los requerimientos de la revista (mira las Políticas de Publicación de MEE (documento en Inglés))
  • (Alcance: Considera los Objetivos y Alcance de MEE (documento en Inglés) para tu manuscrito. No otorgamos garatías de que tu manuscrito esté en el ámbito de MEE.)
  • (Aunque no es requerido, recomendamos tener un manuscrito completamente preparado y en Inglés, al momento de enviar.)
  • (Por favor, no envíes tu paquete de forma separada a Methods in Ecology and Evolution)

Código de Conducta

@ropensci-review-bot
Copy link
Collaborator

Thanks for submitting to rOpenSci, our editors and @ropensci-review-bot will reply soon. Type @ropensci-review-bot help for help.

@ropensci-review-bot
Copy link
Collaborator

🚀

Editor check started

👋

@ropensci-review-bot
Copy link
Collaborator

Checks for karel (v0.1.1.9000)

git hash: 4b057e67

  • ✔️ Package is already on CRAN.
  • ✔️ has a 'codemeta.json' file.
  • ✔️ has a 'contributing' file.
  • ✔️ uses 'roxygen2'.
  • ✔️ 'DESCRIPTION' has a URL field.
  • ✔️ 'DESCRIPTION' has a BugReports field.
  • ✔️ Package has at least one HTML vignette
  • ✔️ All functions have examples.
  • ✔️ Package has continuous integration checks.
  • ✔️ Package coverage is 87%.
  • ✔️ R CMD check found no errors.
  • ✔️ R CMD check found no warnings.
  • 👀 Function names are duplicated in other packages

(Checks marked with 👀 may be optionally addressed.)

Package License: GPL-2


1. Package Dependencies

Details of Package Dependency Usage (click to open)

The table below tallies all function calls to all packages ('ncalls'), both internal (r-base + recommended, along with the package itself), and external (imported and suggested packages). 'NA' values indicate packages to which no identified calls to R functions could be found. Note that these results are generated by an automated code-tagging system which may not be entirely accurate.

type package ncalls
internal base 104
internal karel 44
internal utils 9
internal methods 5
internal stats 3
imports cli 21
imports dplyr 10
imports ggplot2 6
imports magrittr 6
imports tidyr 4
imports purrr 2
imports gganimate 1
suggests testthat NA
suggests knitr NA
suggests rmarkdown NA
linking_to NA NA

Click below for tallies of functions used in each package. Locations of each call within this package may be generated locally by running 's <- pkgstats::pkgstats(<path/to/repo>)', and examining the 'external_calls' table.

base

c (33), message (22), call (17), paste (10), for (4), all (3), list (3), nrow (2), apply (1), array (1), dim (1), emptyenv (1), if (1), integer (1), new.env (1), numeric (1), seq_len (1), which (1)

karel

beepers_present (3), get_beepers_df_row (2), get_pkg_env (2), load_super_karel (2), move (2), right_is_clear (2), turn_around (2), avanzar (1), cargar_super_karel (1), check_user_world (1), check_walls (1), conseguir_amb (1), create_beepers (1), darse_vuelta (1), derecha_abierto (1), draw_karel_df (1), facing_east (1), facing_north (1), facing_south (1), facing_west (1), front_is_blocked (1), front_is_clear (1), generate_world (1), karel_has_beepers (1), karel_has_no_beepers (1), left_is_blocked (1), left_is_clear (1), no_beepers_present (1), pick_beeper (1), plot_static_world (1), put_beeper (1), put_hor_walls (1), right_is_blocked (1), run_actions (1), turn_left (1), turn_right (1)

cli

cli_abort (21)

dplyr

n (4), tibble (3), filter (2), case_when (1)

utils

de (7), data (2)

ggplot2

geom_point (2), scale_x_continuous (2), scale_y_continuous (2)

magrittr

%>% (6)

methods

el (5)

tidyr

expand_grid (4)

stats

time (3)

purrr

pmap_dfr (2)

gganimate

gifski_renderer (1)


2. Statistical Properties

This package features some noteworthy statistical properties which may need to be clarified by a handling editor prior to progressing.

Details of statistical properties (click to open)

The package has:

  • code in R (100% in 9 files) and
  • 1 authors
  • 12 vignettes
  • no internal data file
  • 7 imported packages
  • 63 exported functions (median 1 lines of code)
  • 111 non-exported functions in R (median 3 lines of code)

Statistical properties of package structure as distributional percentiles in relation to all current CRAN packages
The following terminology is used:

  • loc = "Lines of Code"
  • fn = "function"
  • exp/not_exp = exported / not exported

All parameters are explained as tooltips in the locally-rendered HTML version of this report generated by the checks_to_markdown() function

The final measure (fn_call_network_size) is the total number of calls between functions (in R), or more abstract relationships between code objects in other languages. Values are flagged as "noteworthy" when they lie in the upper or lower 5th percentile.

measure value percentile noteworthy
files_R 9 55.2
files_vignettes 12 99.6
files_tests 5 81.7
loc_R 912 65.7
loc_vignettes 1844 96.8 TRUE
loc_tests 310 64.9
num_vignettes 12 99.9 TRUE
n_fns_r 174 87.6
n_fns_r_exported 63 91.0
n_fns_r_not_exported 111 85.7
n_fns_per_file_r 10 86.7
num_params_per_fn 2 11.9
loc_per_fn_r 1 0.0 TRUE
loc_per_fn_r_exp 1 0.0 TRUE
loc_per_fn_r_not_exp 3 1.5 TRUE
rel_whitespace_R 21 69.7
rel_whitespace_vignettes 38 98.6 TRUE
rel_whitespace_tests 17 57.6
doclines_per_fn_exp 66 77.1
doclines_per_fn_not_exp 0 0.0 TRUE
fn_call_network_size 66 71.8

2a. Network visualisation

Click to see the interactive network visualisation of calls between objects in package


3. goodpractice and other checks

Details of goodpractice checks (click to open)

3a. Continuous Integration Badges

pkgcheck
R-CMD-check

GitHub Workflow Results

id name conclusion sha run_number date
7347999524 pages build and deployment success 1367b6 20 2023-12-28
7347980615 pkgcheck success 4b057e 13 2023-12-28
7347980611 pkgdown success 4b057e 23 2023-12-28
7347980603 R-CMD-check success 4b057e 5 2023-12-28

3b. goodpractice results

R CMD check with rcmdcheck

rcmdcheck found no errors, warnings, or notes

Test coverage with covr

Package coverage: 87.04

Cyclocomplexity with cyclocomp

The following functions have cyclocomplexity >= 15:

function cyclocomplexity
check_user_world 28
check_walls 16

Static code analyses with lintr

lintr found the following 53 potential issues:

message number of times
Avoid library() and require() calls in packages 4
Lines should not be more than 80 characters. 45
unexpected symbol 4


4. Other Checks

Details of other checks (click to open)

✖️ The following function name is duplicated in other packages:

    • move from BacArena, chess, cubing, red, rugarch, seqinr, SpaDES.tools


Package Versions

package version
pkgstats 0.1.3.9
pkgcheck 0.1.2.11


Editor-in-Chief Instructions:

This package is in top shape and may be passed on to a handling editor

@jhollist
Copy link
Member

jhollist commented Jan 2, 2024

@mpru Thank you for the submission. I am working on finding a handling editor.

@maurolepore
Copy link
Member

@ropensci-review-bot assign @maurolepore as editor

@ropensci-review-bot
Copy link
Collaborator

Assigned! @maurolepore is now the editor

@maurolepore
Copy link
Member

maurolepore commented Jan 3, 2024

@mpru, es un placer editar tu paquete.

Pronto empezaré a trabajar en la lista de verificación.

Mientras tanto:

  • ¿Confirmas que la revisión debe ser en Castellano?
  • Por favor, sugiere 3 revisores/as. En rOpenSci, generalmente convocamos a no más de 1 de las personas sugeridas, pero utilizamos el resto para comprender mejor el perfil que crees que añadiría valor a tu paquete. Por favor evita conflictos de interés.

@maurolepore
Copy link
Member

@mpru, perdón por la confusión.

Dado que el paquete es multilingüe, el equipo editorial considera que la mejor opción es nominar un/a revisor/a en español y otro/a en inglés.

@mpru
Copy link
Author

mpru commented Jan 6, 2024

Hola, @maurolepore, gracias por involucrarte en este envío. Ambos idiomas están bien para mí y me parece genial la idea del equipo editorial. No estoy familiarizado con los nombres de la lista de revisores como para nominar candidatos. ¿Tal vez vos puedas ayudarme con eso?

@maurolepore
Copy link
Member

maurolepore commented Jan 7, 2024

@mpru,

Seguro ayudo con eso. Nuestra guia ofrece varias ideas sobre donde buscar revisore/as:

https://devdevguide.netlify.app/es/softwarereview_editor.es#where-to-look-for-reviewers

Yo usare esa misma guia pero en rOpenSci nos interesa tu opinion.

Cuando encuentres algun/a candidato/a por favor consiera evitar conflictos de interes.

@maurolepore maurolepore pinned this issue Jan 7, 2024
@maurolepore
Copy link
Member

maurolepore commented Jan 7, 2024

Dear @mpru,thanks for your work. Editor checks were super smooth.

You'll see some comments that require your attention. They are labeled ml01, ml02, and so on. The one(s) starting with a checkbox are required. The one(s) starting with a bullet are just for your consideration.

Editor checks:

  • Documentation: The package has sufficient documentation available online (README, pkgdown docs) to allow for an assessment of functionality and scope without installing the package. In particular,
    • Is the case for the package well made?
    • Is the reference index page clear (grouped by topic if necessary)?
    • Are vignettes readable, sufficiently detailed and not just perfunctory?
  • Fit: The package meets criteria for fit and overlap.
  • Installation instructions: Are installation instructions clear enough for human users?
  • Tests: If the package has some interactivity / HTTP / plot production etc. are the tests using state-of-the-art tooling?
  • Contributing information: Is the documentation for contribution clear enough e.g. tokens for tests, playgrounds?
  • License: The package has a CRAN or OSI accepted license.
  • Project management: Are the issue and PR trackers in a good shape, e.g. are there outstanding bugs, is it clear when feature requests are meant to be tackled?

Editor comments

FIT

rOpenSci accepts this package as part of the Champions program.

VIGNETTES

  • ml01. In the article "Getting started" consider removing "new" so that this sentence is still valid many years from now:

karel is a new R package ...

TESTS

  • ml02. Please explain if and how the package tests interactivity.
  • ml03. I see few general tests. Consider spliting them in to more, smaller, specific tests so that it's easier
    to detect the problem when a test fails.

A search for "test_that(" shows that the test titles seem too general -- https://github.com/search?q=repo%3Ampru%2Fkarel%20test_that(&type=code

And I see many expectations per tests, e.g.:

https://github.com/mpru/karel/blob/master/tests/testthat/test-actions.R

You want to arrange things such that, when a test fails, you’ll know what’s wrong and where in your code to look for the problem. This motivates all our recommendations regarding file organisation, file naming, and the test description. Finally, try to avoid putting too many expectations in one test - it’s better to have more smaller tests than fewer larger tests.

-- https://r-pkgs.org/testing-basics.html#test-organisation

  • ml04. I see the expected error is not specific.

Usually you care about two things when testing an error:

  • Does the code fail? Specifically, does it fail for the right reason?
  • Does the accompanying message make sense to the human who needs to deal with the error?

-- https://r-pkgs.org/testing-basics.html#expectations

For example see https://github.com/search?q=path%3Atests%2Ftestthat+repo%3Ampru%2Fkarel+library%28karel%29&type=code

@mpru
Copy link
Author

mpru commented Jan 13, 2024

Thanks Mauro! I already started working in your comments, I'm reviewing and changing my unit tests. I'll suggest reviewers as well.

@maurolepore maurolepore unpinned this issue Jan 17, 2024
@maurolepore
Copy link
Member

@ropensci-review-bot seeking reviewers

@ropensci-review-bot
Copy link
Collaborator

Please add this badge to the README of your package repository:

[![Status at rOpenSci Software Peer Review](https://badges.ropensci.org/620_status.svg)](https://github.com/ropensci/software-review/issues/620)

Furthermore, if your package does not have a NEWS.md file yet, please create one to capture the changes made during the review process. See https://devguide.ropensci.org/releasing.html#news

@mpru
Copy link
Author

mpru commented Feb 15, 2024

Hi @maurolepore. I'm sorry I couldn't do it sooner but I wanted to let you know that I worked on your comments and think it might be ready to give it another try.

Vignettes

  • The "Getting started" article was updated with your suggestion.

Tests

  • Unit tests were rewritten to make them more specific:

    • I think it's easier now to detect the problem when a test fails, as the titles are more descriptive of what is being evaluated. Large tests with lots of expectations were replaced by smaller ones.

    • Most of the test files were separated, creating a version for each implemented language. It is important to evaluate the external functions available in each language, to ensure that they are calling the correct internal functions.

  • Unit tests based on the vdiffr package were added to test for interactivity with snapshots:

    • Before your comment, the package did not test interactivity or use any state-of-the-art tooling for something like that. Following your observation, I added test units that are based on the vdiffr package, which allows monitoring the appearance of graphics by generating SVG files and saving them as testthat snapshots.

    • When a person using this package writes code to make Karel solve a problem, the result will be, provided everything goes well, a gif that shows Karel executing the programmed actions. The gif is created internally with gganimate from many ggplot2 plots. The package offers a function to access any of these graphs (plot_static_world), which I use to create examples and statements for new exercises, as well for debugging (it's not ment for students). The new units for testing interactivity execute pieces of code (simple or long) for Karel to solve various problems (taken from tutorials on the web) and use plot_static_world() to capture the graph that shows what Karel's world should be like at the end of each process. If the package works correctly and nothing has broken, these tests should indicate agreement between the captured image and the snapshot saved as reference. These tests are located in the file test-snapshots.R

  • Removed the library() calls in the tests files.

Others

  • Upgraded the version number from 0.1.1.9000 to 0.1.1.9001 (not sure if this is ok).
  • Added the rOpenSci badge required by the bot to the README file.
  • The NEWS file was modified to comply with rOpenSci suggestiones.
  • A wrong error message was discovered while writing new unit tests and was fixed.

Suggested reviewers

  • I saw that Maëlle Salmon was recently working on a package called babelquarto to create multilingual websites or books (like the one in the new version of the rOpenSci developer guide). Johannes Ranke and Joel Nitta appear as contributors in the babelquarto repo. Maybe one of these three people could be?

  • I also thought that we could call on the person who was my mentor during the Champions program, who already knows the project, Lukas Walrich, although I don't know if that could imply a conflict of interest.

  • Following the suggestion of searching among authors of rOpenSci packages is not easy since this submission does not fall into any of the categories (an exception has been made within the framework of the Champions program).

  • I didn't understand how to use Airtable to search for potential reviewers, could it be that the general public doesn't have access to the database and only editors?

That's all for now, thanks.

@maurolepore
Copy link
Member

@mpru thanks a lot for this! It will make the reviewers's job easier.

Upgraded the version number from 0.1.1.9000 to 0.1.1.9001 (not sure if this is ok).

I think it's OK. That's the kind of increment I see with fledge::bum_version() in my own packages.

I didn't understand how to use Airtable to search for potential reviewers, could it be that the general public doesn't have access to the database and only editors?

I think you're right, and Airtable is only useful to editors with the right access permission.

I'll resume the search for reviewers.

@maurolepore
Copy link
Member

@ropensci-review-bot assign @vjimenez9 as reviewer

@ropensci-review-bot
Copy link
Collaborator

@vjimenez9 added to the reviewers list. Review due date is 2024-03-14. Thanks @vjimenez9 for accepting to review! Please refer to our reviewer guide.

rOpenSci’s community is our best asset. We aim for reviews to be open, non-adversarial, and focused on improving software quality. Be respectful and kind! See our reviewers guide and code of conduct for more.

@ropensci-review-bot
Copy link
Collaborator

@vjimenez9: If you haven't done so, please fill this form for us to update our reviewers records.

@maurolepore
Copy link
Member

@vjimenez9, dado que el paquete es multilingüe, el equipo editorial considera que la mejor opción es nominar un/a revisor/a en español y otro/a en inglés. Podias revisarlo en español?

@maurolepore
Copy link
Member

@ropensci-review-bot assign @joelnitta as reviewer

@ropensci-review-bot
Copy link
Collaborator

@joelnitta added to the reviewers list. Review due date is 2024-03-24. Thanks @joelnitta for accepting to review! Please refer to our reviewer guide.

rOpenSci’s community is our best asset. We aim for reviews to be open, non-adversarial, and focused on improving software quality. Be respectful and kind! See our reviewers guide and code of conduct for more.

@maurolepore
Copy link
Member

@joelnitta just a friendly reminder that we're looking forward to your review :-)

@joelnitta
Copy link

joelnitta commented Apr 2, 2024

Package Review

  • Briefly describe any working relationship you have (had) with the package authors.
  • 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
  • Examples: (that run successfully locally) for all exported functions
  • Community guidelines: including contribution guidelines in the README or CONTRIBUTING, and DESCRIPTION with URL, BugReports and Maintainer (which may be autogenerated via Authors@R).

Functionality

  • Installation: Installation succeeds as documented.
  • Functionality: Any functional claims of the software have been confirmed.
  • Performance: Any performance claims of the software have 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.

Estimated hours spent reviewing: 5

  • 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

To-do list

  • Add statement of need. The Who is Karel? section of the README hints at the need but does not describe it explicitly.

UI

Many of the error messages are preceded by cli::cli_rule(). While of course informative error messages are important, care should be taken that the package is not overly chatty. I don't see why the cli::cli_rule() is needed.

Tests

For expect_error(), it is a good idea to indicate the expected error message using the regexp argument so that you know the error is actually the expected one and not another error. This also makes the intention of the test clearer, for example the first test of test-set_up.R.

There is a lot of repeated code in test-set_up.R where each list of world elements (world_test) is being defined slightly differently. I think this could be simplified by starting with a single world_test_template list, then modifying it for each test to check that the correct error message is generated. For example:

world_test_template <- list(
  nx = 6, ny = 4,
  hor_walls = dplyr::tibble(x = 3, y = 1, lgth = 3),
  ver_walls = dplyr::tibble(x = 3, y = 0, lgth = 1),
  karel_x = 1, karel_y = 1,
  karel_dir = 1,
  beepers_x = 2, beepers_y = 1, beepers_n = 1,
  beepers_bag = Inf)

test_that("The generic world template works correctly before modifying it
           in subsequent tests", {
  expect_no_error(generar_mundo(world_test_template))
  expect_no_error(generate_world(world_test_template))
})

test_that("Karel's initial direction is required when creating a new world
           provided as a list by the user.", {
  world_test <- world_test_template
  world_test$karel_x <- NULL
  expect_error(generate_world(world_test), "karel_x is missing")
})

test_that("The correct number of avenues (nx) is required when creating a newa
           world provided as a list by the user.", {
  world_test <- world_test_template
  world_test$nx <- 6.4
  expect_error(
    generate_world(world_test),
    "nx, the number of avenues, must be numeric of length 1")
})

It would be good to add a test coverage badge so we can verify what percentage of functions are included in tests.

Examples

I recommend use of if (interactive()) instead of if(FALSE) for skipping example code like run_actions() that should not be run during checks. if (interactive()) is more explicit in its intent than if(FALSE), and will work when users copy-paste the example code. Sometimes CRAN checks can be picky about how you specify which code to skip in examples.

Multilingual documentation

As far as I know, this package is unique in its approach to multilingual functionality and documentation. I applaud the author for this commitment to breaking down linguistic barriers. However, there are several aspects to consider carefully here.

I am a little concerned about the multilingual aliases for function names. First, I think ultimately it could be counter-productive for the learners. For better or worse, English is the standard language used in programming. If the goal is to teach students programming, at some point they will have to deal with words that are in English. We can even see this in karel lessons: although the karel functions have names in Spanish, the learners still need to use base R code with syntax like if(), else(), function(), etc. It may be better to get them used to writing R syntax in English from the start instead of mixing English and Spanish (or another language). Furthermore, CRAN does not allow non-ASCII characters in R code, so it will be difficult or impossible to display function names in some non-English languages. Finally, using only one name per function makes the package easier to maintain. Currently, entire test files are duplicated and must be maintained due to having function aliases. However, as I mention below, one argument in favor of function aliases is that it allows you to maintain help files in a different languages... this is a complicated topic!

Apart from function names, I think localization of function UI and documentation is absolutely a plus and should be done. I see this as falling into three main categories: localization of UI, documentation of functions in the package (help files), and the package website. This package is pushing the limits of what R can do in terms of multilingual functionality, and as I describe below, mature solutions for each of these are not yet available in some cases.

For localizing the UI (function messages), I recommend the potools package (and PO files). This provides a very clean way to localize a package. Once it is set up, the user should have a seamless linguistic experience: if they are using a computer with a Spanish locale, all of the package messages will be in Spanish; same for English, etc. To get started with potools, I recommend this blog post by Maëlle Salmon. This is the localization aspect that has the most mature solution available.

@eliocamp is working on a package to localize help file contents, rhelpi18n. It should eventually provide a similar seamless experience as UI localization with PO tools, but unfortunately does not seem ready for production use yet. So honestly I am not sure what to do here. I wish there was a way to provide a help file in an alternate language that did not require a different function name. Actually, this may be a point in favor of keeping function aliases: it actually allows you to provide help files in different languages.

For the website, it would be ideal if there was a "language button" that could be clicked to switch between languages on a given page. With the current setup, both languages (Spanish and English) are displayed in a single webpage, but a given user probably only needs to see one or the other. Also, while this approach works OK for two languages, it would likely become unusable if any more were added. It would be great if pkgdown fully supported multilingual websites, but unfortunately this does not seem to be the case. Although pkgdown can provide website elements in different languages by setting a YAML parameter, it is limited to making a single webpage in one language. Since this is currently set to Spanish, various website elements appear in Spanish even though some of the content is in English. So, in absence of a genuine solution from pkgdown, I wonder if a work-around via forking the package and maintaining a website in a different language from there could be an option. This is not ideal, but it would scale better if multiple languages were to be implemented.

Vignettes

This package is also unique in that much of the vignette contents are actually lessons teaching programming in R with karel, rather just than how to use the karel functions. I think it may be preferable to split out the lessons teaching R into their own website. This would make maintaining the package easier. I am not sure of the optimal format, but one that I can recommend is the Carpentries lesson template (known as "the Workbench"). I could easily see the vignette contents being converted into a Carpentries lesson and hosted on the Carpentries Incubator. Please consider this.

I also noticed that much of the lesson content is focused on control flow. While this makes sense as a general feature of programming languages, R these days is often used for data analysis, which may not necessarily put as much emphasis on control flow. I personally almost never use while(), and try to use apply or purrr::map_() family functions instead of for loops. I wonder if there may be someway to use karel to help teach data analysis, as it is in relatively high demand.

Other random comments

  • When the gif plays, it is automatically looped. This makes it a bit hard to tell where the commands start and end, especially if Karel ends up in the same place she started. You may want to add "start" and "end" text to make this clearer. Another idea is to make the looping optional, since it is a bit confusing to the learner that Karel repeats her actions even though we have not explicitly used a for() loop etc.

  • Why do the beepers have the number "1" on them?

  • Under the Available actions for Karel section in English, there are two functions in Spanish, poner_coso() and juntar_coso().

  • The examples for the internal functions should use karel:::, not karel::. Because of this, the examples for get_pkg_env() and plot_static_world() fail.

  • Please note I submitted a PR correcting some typos

@maurolepore
Copy link
Member

@ropensci-review-bot submit review #620 (comment) time 5

@ropensci-review-bot
Copy link
Collaborator

Logged review for joelnitta (hours: 5)

@maurolepore
Copy link
Member

Thanks @vjimenez9 and @joelnitta for your reviews!

@mpru I see you already responded to @vjimenez9's reivew (in #620 (comment)). If that's your final response to that review, then please simply acknowledge it; else please add whatever you feel necessary and/or refer to #620 (comment) when appropriate.

Also please respond to @joelnitta's review.

We recommend responding within the next 2 weeks.

In general aim for 3 weeks for review, 2 weeks for subsequent changes, and 1 week for reviewer approval of changes.
--https://devdevguide.netlify.app/softwarereview_editor#during-review

@ropensci-review-bot
Copy link
Collaborator

@mpru: please post your response with @ropensci-review-bot submit response <url to issue comment> if you haven't done so already (this is an automatic reminder).

Here's the author guide for response. https://devguide.ropensci.org/authors-guide.html

@mpru
Copy link
Author

mpru commented Apr 18, 2024

@maurolepore hoy se cumplen las dos semanas de plazo para completar mis respuestas, pero aún no he tenido oportunidad de hacerlo. Pido disculpas por la demora, espero hacerlo a la brevedad.

@maurolepore
Copy link
Member

OK, gracias por avisar :-)

@mpru
Copy link
Author

mpru commented May 9, 2024

@maurolepore, apologies for the delay, here I acknowledge my previous response to Veronica and proceed to respond to Joel.

Response to @vjimenez9

My response to @vjimenez9 was stated in this comment. I really thank you again for your comments and suggestions.

Response to @joelnitta

Thank you very much for all the work and commitment put into reviewing my package. I really appreciate all the comments and corrections made, many of which I would have liked to have read during the initial stages of the package's development, since they refer to structural issues of the package. Below I am going to respond to your comments one by one, indicating the changes applied to the package or the reason why I have not implemented, at least for now, some of the suggestions.

Review Comments

To-do list

  • Add statement of need. The Who is Karel? section of the README hints at the need but does not describe it explicitly.

Response. Updated README in ropensci/karel@d07dfcb to try to address it more explicitly.

UI

Many of the error messages are preceded by cli::cli_rule(). While of course informative error messages are important, care should be taken that the package is not overly chatty. I don't see why the cli::cli_rule() is needed.

Response. Removed all calls to cli_rule() in ropensci/karel@a644c01

Tests

For expect_error(), it is a good idea to indicate the expected error message using the regexp argument so that you know the error is actually the expected one and not another error. This also makes the intention of the test clearer, for example the first test of test-set_up.R.

There is a lot of repeated code in test-set_up.R where each list of world elements (world_test) is being defined slightly differently. I think this could be simplified by starting with a single world_test_template list, then modifying it for each test to check that the correct error message is generated. For example:

world_test_template <- list(
  nx = 6, ny = 4,
  hor_walls = dplyr::tibble(x = 3, y = 1, lgth = 3),
  ver_walls = dplyr::tibble(x = 3, y = 0, lgth = 1),
  karel_x = 1, karel_y = 1,
  karel_dir = 1,
  beepers_x = 2, beepers_y = 1, beepers_n = 1,
  beepers_bag = Inf)

test_that("The generic world template works correctly before modifying it
           in subsequent tests", {
  expect_no_error(generar_mundo(world_test_template))
  expect_no_error(generate_world(world_test_template))
})

test_that("Karel's initial direction is required when creating a new world
           provided as a list by the user.", {
  world_test <- world_test_template
  world_test$karel_x <- NULL
  expect_error(generate_world(world_test), "karel_x is missing")
})

test_that("The correct number of avenues (nx) is required when creating a newa
           world provided as a list by the user.", {
  world_test <- world_test_template
  world_test$nx <- 6.4
  expect_error(
    generate_world(world_test),
    "nx, the number of avenues, must be numeric of length 1")
})

Response: Changed tests to implement this in ropensci/karel@ae770bf and ropensci/karel@a995fa8

It would be good to add a test coverage badge so we can verify what percentage of functions are included in tests.

Response: Implemented in ropensci/karel@9c1b69c

Examples

I recommend use of if (interactive()) instead of if(FALSE) for skipping example code like run_actions() that should not be run during checks. if (interactive()) is more explicit in its intent than if(FALSE), and will work when users copy-paste the example code. Sometimes CRAN checks can be picky about how you specify which code to skip in examples.

Response. Fixed in ropensci/karel@cb143b5

Multilingual documentation

As far as I know, this package is unique in its approach to multilingual functionality and documentation. I applaud the author for this commitment to breaking down linguistic barriers. However, there are several aspects to consider carefully here.

I am a little concerned about the multilingual aliases for function names. First, I think ultimately it could be counter-productive for the learners. For better or worse, English is the standard language used in programming. If the goal is to teach students programming, at some point they will have to deal with words that are in English. We can even see this in karel lessons: although the karel functions have names in Spanish, the learners still need to use base R code with syntax like if(), else(), function(), etc. It may be better to get them used to writing R syntax in English from the start instead of mixing English and Spanish (or another language). Furthermore, CRAN does not allow non-ASCII characters in R code, so it will be difficult or impossible to display function names in some non-English languages. Finally, using only one name per function makes the package easier to maintain. Currently, entire test files are duplicated and must be maintained due to having function aliases. However, as I mention below, one argument in favor of function aliases is that it allows you to maintain help files in a different languages... this is a complicated topic!

Response. I share your point of view. For better or worse, and sooner or later, our students must learn to use English, not only for programming, but because much of the new literature in the discipline is written in English. However, for the context in which we use this package (or in which I think others may use it, I write more about this later), I think there is an important difference between using and learning just a few English terms (if, else, function, etc.) and having everything else in Spanish, and having absolutely everything in English. With aliases, students can think about and discuss what actions Karel should take to solve a problem and write them down in their own language (e.g., girar a la derecha, juntar, poner), while also being able to consult help and see examples in their own language. I understand that this does not solve the need for English in the medium term, but I like having the possibility of using the environment mostly in Spanish as a first approach.

Apart from function names, I think localization of function UI and documentation is absolutely a plus and should be done. I see this as falling into three main categories: localization of UI, documentation of functions in the package (help files), and the package website. This package is pushing the limits of what R can do in terms of multilingual functionality, and as I describe below, mature solutions for each of these are not yet available in some cases.

For localizing the UI (function messages), I recommend the potools package (and PO files). This provides a very clean way to localize a package. Once it is set up, the user should have a seamless linguistic experience: if they are using a computer with a Spanish locale, all of the package messages will be in Spanish; same for English, etc. To get started with potools, I recommend this blog post by Maëlle Salmon. This is the localization aspect that has the most mature solution available.

Response: Thanks for commenting on the potools package, I didn't know about it. I think it's something I could explore, and I'd like to, although this would involve changing the current structure of the package extensively and in the short term I don't think I can do it. However, this approach goes hand in hand with having all function names written in one language (which should be English, following the previous reasoning that the rest of the statements like if, function, for, etc., are in English), but I really want and like the names of the functions to be in Spanish, and to use them in Spanish with my students, even though this incurs the alias system with the limitations that we discussed before.

@eliocamp is working on a package to localize help file contents, rhelpi18n. It should eventually provide a similar seamless experience as UI localization with PO tools, but unfortunately does not seem ready for production use yet. So honestly I am not sure what to do here. I wish there was a way to provide a help file in an alternate language that did not require a different function name. Actually, this may be a point in favor of keeping function aliases: it actually allows you to provide help files in different languages.

Response: What a nice project you mentioned. I seem to understand that the system proposed by the rhelpi18n package requires writing the documentation in different languages, which is also what I do now in my package, but saving these translations in different packages. That has the disadvantage of having to install one more package depending on the language you want to use it in, but it is an advantage because it is easier to maintain, and because eventually including more and more languages under the current karel concept would make the package become heavier than allowed. If this approach matures we could use it to have translations of the help pages, but again we would still have a single English name for each function, which I consider to be a limitation. I think I prefer karel's current approach for the moment.

For the website, it would be ideal if there was a "language button" that could be clicked to switch between languages on a given page. With the current setup, both languages (Spanish and English) are displayed in a single webpage, but a given user probably only needs to see one or the other. Also, while this approach works OK for two languages, it would likely become unusable if any more were added. It would be great if pkgdown fully supported multilingual websites, but unfortunately this does not seem to be the case. Although pkgdown can provide website elements in different languages by setting a YAML parameter, it is limited to making a single webpage in one language. Since this is currently set to Spanish, various website elements appear in Spanish even though some of the content is in English. So, in absence of a genuine solution from pkgdown, I wonder if a work-around via forking the package and maintaining a website in a different language from there could be an option. This is not ideal, but it would scale better if multiple languages were to be implemented.

Response. Yes, every time I see the website I think exactly that, with two languages it is fairly ok, but if someone really wanted to keep adding languages, it would quickly become impractical. Hopefully at some point pkgdown will support support for multilingual pages, that would be great. It seems to me that the forking idea could work if more languages are added, including links between the different webpages, although I'm not sure about the source code living in several kind of "official" repos. I think for now I'm going to keep the site as planned now.

Vignettes

This package is also unique in that much of the vignette contents are actually lessons teaching programming in R with karel, rather just than how to use the karel functions. I think it may be preferable to split out the lessons teaching R into their own website. This would make maintaining the package easier. I am not sure of the optimal format, but one that I can recommend is the Carpentries lesson template (known as "the Workbench"). I could easily see the vignette contents being converted into a Carpentries lesson and hosted on the Carpentries Incubator. Please consider this.

Response: I agree with this observation, I made use of the vignettes in a way that is outside the norm for R packages, turning them into lessons. In fact, I use these vignettes as study material for the students I use this material with. This also turns out to be an extra burden to achieve the objective of having all the documentation multilingual, adding a new language would mean translating all the vignettes. However, for the moment I prioritize making this project self-contained, and having my students rely on a single web page for the package and their lessons. I'd be interested in exploring your suggestions about including this in the Carpentries Incubator in the medium term, but it's not something I can pursue right away.

I also noticed that much of the lesson content is focused on control flow. While this makes sense as a general feature of programming languages, R these days is often used for data analysis, which may not necessarily put as much emphasis on control flow. I personally almost never use while(), and try to use apply or purrr::map_() family functions instead of for loops. I wonder if there may be someway to use karel to help teach data analysis, as it is in relatively high demand.

Response: What you notice has been chosen on purpose. To better answer, I must give some context about my use of this package. At my University, this package has been used in an informal pre-university course for some years now for students who will enter the Bachelor's degree in Statistics and who do not have any prior knowledge of programming. The objective is to teach them general programming concepts (applicable to any language) but in the main language that they will begin to use in the immediate future in their studies, R. That's why tools for data analysis or to improve some aspects of coding (like the apply or map examples you mention) are not included in the vignettes. They study all this and much more in the degree. In this course we only see these general programming ideas, not oriented to data analysis, in the environment that they will later use for data analysis. Perhaps the question that I should asked to myself is whether, thinking that the vignettes/lessons can be used in other contexts, it should not include other notions, but I think not, since in this way it remains limited and faithful to its original purpose.

Other random comments

  • When the gif plays, it is automatically looped. This makes it a bit hard to tell where the commands start and end, especially if Karel ends up in the same place she started. You may want to add "start" and "end" text to make this clearer. Another idea is to make the looping optional, since it is a bit confusing to the learner that Karel repeats her actions even though we have not explicitly used a for() loop etc.

    Response: the looping was already optional, as I faced this problem before. I couldn't make my mind about this, and ended up setting to TRUE the default value for the repeat argument in the .run_actions internal function and its wrapers. Now that you mention this, I changed it to FALSE in ropensci/karel@15272ee

  • Why do the beepers have the number "1" on them?

    Response: Because in each position there can be more than one beeper and this number indicates the quantity present there (if there's no beeper, then it's not ploted, otherwise the number tells how many there are in that spot). In some examples of the tutorials there are very interesting problems and exercises to solve taking this characteristic into account, such as detecting how many beepers there are in a position and duplicating them.

  • Under the Available actions for Karel section in English, there are two functions in Spanish, poner_coso() and juntar_coso().

    Response: solved in ropensci/karel@7bfce1e

  • The examples for the internal functions should use karel:::, not karel::. Because of this, the examples for get_pkg_env() and plot_static_world() fail.

    Response: solved in ropensci/karel@9024f2c

  • Please note I submitted a PR correcting some typos

    Response: I accepted it, thank you for having done such a detailed reading and having detected these typos.

@maurolepore
Copy link
Member

¡Gracias @mpru!

@vjimenez9 y @joelnitta, ¿podrían por favor informarnos si recomiendan más cambios o indicar su aprobación utilizando esta plantilla?

--

Thanks @mpru!

@vjimenez9 and @joelnitta can you please let us know if you recommend further changes or indicate your approval using this template?

@joelnitta
Copy link

Reviewer Response

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

@maurolepore
Copy link
Member

@vjimenez9

Solo para recordarte que esperamos tu respuesta.

¿Podrías por favor informarnos si recomiendas más cambios o indicar tu aprobación utilizando esta plantilla?

@maurolepore
Copy link
Member

@vjimenez9

Revisando los comentarios veo este comentario por el que asumo tu aprovacion:

Me parece que la mayoría de lo vital quedo plasmado. Supongo que con esto terminan mis sugerencias y no me queda mas que felicitarte. -- @vjimenez9 en #620 (comment)

Para no demorar la publicacion voy a formalizar la aprobacion. Si tenes alguna sugerencia mas, es bienvenida pero sugiero que @mpru la considere luego de la publicacion.

De todos modos, cuando puedas, por favor completa esta plantilla asi registramos formalmente tu esfuerzo.

Muchisimas gracias por tu trabajo.


@vjimenez9

Reviewing the comments, I see this one from which I assume your approval (translated with ChatGTP):

It seems to me that most of the essential points have been addressed. I suppose this concludes my suggestions, and I can only congratulate you. -- @vjimenez9 on #620 (comment)

To avoid delaying the publication, I will formalize the approval. If you have any further suggestions, they are welcome but I suggest that @mpru consider them after the publication.

In any case, when you can, please complete this template so we can formally record your efforts.

Thank you very much for your work.

@maurolepore
Copy link
Member

@ropensci-review-bot approve karel

@ropensci-review-bot
Copy link
Collaborator

Approved! Thanks @mpru for submitting and @vjimenez9, @joelnitta 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 will need to enable two-factor authentication for your GitHub account.
    This invitation will expire after one week. If it happens write a comment @ropensci-review-bot invite me to ropensci/<package-name> which will re-send an invitation.
  • After transfer write a comment @ropensci-review-bot finalize transfer of <package-name> where <package-name> is the repo/package name. This will give you admin access back.
  • Fix all links to the GitHub repo to point to the repo under the ropensci organization.
  • Delete your current code of conduct file if you had one since rOpenSci's default one will apply, see https://devguide.ropensci.org/collaboration.html#coc-file
  • If you already had a pkgdown website and are ok relying only on rOpenSci central docs building and branding,
    • deactivate the automatic deployment you might have set up
    • remove styling tweaks from your pkgdown config but keep that config file
    • replace the whole current pkgdown website with a redirecting page
    • replace your package docs URL with https://docs.ropensci.org/package_name
    • In addition, in your DESCRIPTION file, include the docs link in the URL field alongside the link to the GitHub repository, e.g.: URL: https://docs.ropensci.org/foobar, https://github.com/ropensci/foobar
  • Skim the docs of the pkgdown automatic deployment, in particular if your website needs MathJax.
  • Fix any links in badges for CI and coverage to point to the new repository URL.
  • Increment the package version to reflect the changes you made during review. In NEWS.md, add a heading for the new version and one bullet for each user-facing change, and each developer-facing change that you think is relevant.
  • We're starting to roll out software metadata files to all rOpenSci packages via the Codemeta initiative, see https://docs.ropensci.org/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.
  • You can add this installation method to your package README install.packages("<package-name>", repos = "https://ropensci.r-universe.dev") thanks to R-universe.

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

Welcome aboard! We'd love to host a post about your package - either a short introduction to it with an example for a technical audience or a longer post with some narrative about its development or something you learned, and an example of its use for a broader readership. If you are interested, consult the blog guide, and tag @ropensci/blog-editors in your reply. They will get in touch about timing and can answer any questions.

We maintain an online book with our best practice and tips, this chapter starts the 3d section that's about guidance for after onboarding (with advice on releases, package marketing, GitHub grooming); the guide also feature CRAN gotchas. Please tell us what could be improved.

Last but not least, you can volunteer as a reviewer via filling a short form.

@maurolepore
Copy link
Member

@mpru I see the package is approved but it seems it hasn't been moved to the ropensci organization, right?

Can we support in any way?

cc @yabellini

@mpru
Copy link
Author

mpru commented Jul 26, 2024

@ropensci-review-bot finalize transfer of karel

@ropensci-review-bot
Copy link
Collaborator

Transfer completed.
The karel team is now owner of the repository and the author has been invited to the team

@mpru
Copy link
Author

mpru commented Jul 27, 2024

Hola @maurolepore, gracias por tus mensajes y perdón por mi ausencia. La aprobación del coincidió justo con el nacimiento de mi hija y tuve que dejar en pausa algunas cosas.

Ayer comencé a completar los pasos mencionados arriba y en el proceso me surgió una duda, en la que tal vez @yabellini pueda ayudar. Este paquete no entraba en ninguna de las categorías de alcances de rOpenSci pero fue aceptado en el marco del programa Champions para pasar por el proceso de revisión, tal como hemos hecho. Me pregunto ahora si después de la revisión y aprobación, igualmente debemos transferirlo a rOpenSci o no por esta particularidad. Quería recordar este aspecto antes de continuar.

Estoy en la parte referida a la nueva publicación del pkgdown website, espero confirmación para continuar.

¡Gracias!

@maurolepore
Copy link
Member

Buena pregunta. A ver que dice Yani.

@yabellini
Copy link
Member

Hola, volvi de mis vacaciones y me estoy poniendo al dia. Disculpen la tardanza en volver al tema.

La idea original era poder enviarlo a JOSE despues de nuestra revision, pero eso implicaria escribir un paper (corto) pero aun implica escribirlo y debe ser en Ingles. JOSE aplicaria un fast track para este paper porque ya fue revisado por nosotros y como yo soy editora alli podria encargarme del proceso.

Independiente del punto anterior, voy a volver a preguntar sobre el traspaso a la organziacion de rOpenSci, lo que si no creo que podamos hacer es crear la documentación con el workflow de rOpenSci, especialmente por la naturaleza multilingue de la documentacion.

@mpru
Copy link
Author

mpru commented Aug 22, 2024

Gracias, Yani, voy a ir trabajando en el borrador del paper para JOSE y mientras tanto sigo dejando en pausa lo de la transferencia del repo, que por ahora quedó en ropensci, cualquier cosa lo volvemos.

@yabellini
Copy link
Member

Hola! Ya lo hablamos con el equipo y esta bien que el paquete este en la organizacion de rOpenSci. Aqui ya esta la documentacion generada: https://docs.ropensci.org/karel/

Mas adelante estaremos resolviendo como agregarle los badges a los paquetes del programa de campeones para indicar que fueron parte del programa y con eso queda claro porque es parte de nuestra organizacion aun estando fuera de nuestro alcance.

Con respecto del paper avísame cualquier duda que tengas al respecto.

Felicitaciones @mpru por el trabajo realizado!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants