-
-
Notifications
You must be signed in to change notification settings - Fork 104
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
Comments
Thanks for submitting to rOpenSci, our editors and @ropensci-review-bot will reply soon. Type |
🚀 Editor check started 👋 |
Checks for karel (v0.1.1.9000)git hash: 4b057e67
(Checks marked with 👀 may be optionally addressed.) Package License: GPL-2 1. Package DependenciesDetails 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.
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. basec (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) karelbeepers_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) clicli_abort (21) dplyrn (4), tibble (3), filter (2), case_when (1) utilsde (7), data (2) ggplot2geom_point (2), scale_x_continuous (2), scale_y_continuous (2) magrittr%>% (6) methodsel (5) tidyrexpand_grid (4) statstime (3) purrrpmap_dfr (2) gganimategifski_renderer (1) 2. Statistical PropertiesThis 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:
Statistical properties of package structure as distributional percentiles in relation to all current CRAN packages
All parameters are explained as tooltips in the locally-rendered HTML version of this report generated by the The final measure (
2a. Network visualisationClick to see the interactive network visualisation of calls between objects in package 3.
|
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
@mpru Thank you for the submission. I am working on finding a handling editor. |
@ropensci-review-bot assign @maurolepore as editor |
Assigned! @maurolepore is now the editor |
@mpru, es un placer editar tu paquete. Pronto empezaré a trabajar en la lista de verificación. Mientras tanto:
|
@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. |
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? |
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. |
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:
Editor commentsFIT rOpenSci accepts this package as part of the Champions program. VIGNETTES
TESTS
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
-- https://r-pkgs.org/testing-basics.html#test-organisation
-- 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 |
Thanks Mauro! I already started working in your comments, I'm reviewing and changing my unit tests. I'll suggest reviewers as well. |
@ropensci-review-bot seeking reviewers |
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 |
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
Tests
Others
Suggested reviewers
That's all for now, thanks. |
@mpru thanks a lot for this! It will make the reviewers's job easier.
I think it's OK. That's the kind of increment I see with
I think you're right, and Airtable is only useful to editors with the right access permission. I'll resume the search for reviewers. |
@ropensci-review-bot assign @vjimenez9 as reviewer |
@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. |
@vjimenez9: If you haven't done so, please fill this form for us to update our reviewers records. |
@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? |
@ropensci-review-bot assign @joelnitta as reviewer |
@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. |
@joelnitta just a friendly reminder that we're looking forward to your review :-) |
Package Review
DocumentationThe package includes all the following forms of documentation:
Functionality
Estimated hours spent reviewing: 5
Review CommentsTo-do list
UIMany of the error messages are preceded by TestsFor There is a lot of repeated code in
It would be good to add a test coverage badge so we can verify what percentage of functions are included in tests. ExamplesI recommend use of Multilingual documentationAs 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 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 @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. VignettesThis package is also unique in that much of the vignette contents are actually lessons teaching programming in R with 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 Other random comments
|
@ropensci-review-bot submit review #620 (comment) time 5 |
Logged review for joelnitta (hours: 5) |
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.
|
@mpru: please post your response with Here's the author guide for response. https://devguide.ropensci.org/authors-guide.html |
@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. |
OK, gracias por avisar :-) |
@maurolepore, apologies for the delay, here I acknowledge my previous response to Veronica and proceed to respond to Joel. Response to @vjimenez9My response to @vjimenez9 was stated in this comment. I really thank you again for your comments and suggestions. Response to @joelnittaThank 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 CommentsTo-do list
Response. Updated README in ropensci/karel@d07dfcb to try to address it more explicitly. UIMany of the error messages are preceded by Response. Removed all calls to TestsFor There is a lot of repeated code in
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 ExamplesI recommend use of Response. Fixed in ropensci/karel@cb143b5 Multilingual documentationAs 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 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 Response: Thanks for commenting on the @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 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. VignettesThis package is also unique in that much of the vignette contents are actually lessons teaching programming in R with 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 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
|
¡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? |
Reviewer ResponseFinal approval (post-review)
Estimated hours spent reviewing: 5 |
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? |
Revisando los comentarios veo este comentario por el que asumo tu aprovacion:
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. Reviewing the comments, I see this one from which I assume your approval (translated with ChatGTP):
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. |
@ropensci-review-bot approve karel |
Approved! Thanks @mpru for submitting and @vjimenez9, @joelnitta for your reviews! 😁 To-dos:
Should you want to acknowledge your reviewers in your package DESCRIPTION, you can do so by making them 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. |
@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 |
@ropensci-review-bot finalize transfer of karel |
Transfer completed. |
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! |
Buena pregunta. A ver que dice Yani. |
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. |
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. |
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! |
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
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.
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
¿Tienes intenciones de subir este paquete a CRAN?
¿Tienes intenciones de enviar este paquete a Bioconductor?
¿Deseas enviar un Artículo de Aplicaciones sobre tu paquete a Methods in Ecology and Evolution (documento en Inglés)? Si es así:
Opciones para MEE
Código de Conducta
The text was updated successfully, but these errors were encountered: