-
Notifications
You must be signed in to change notification settings - Fork 6
bugRzilla: Helping submitting issues to R
Changes on R are made by a group of people known as R-core. To notify them of errors, improvements and wishes of R the established channel is using a bug tracker. Many issues remain open a long time due to several reasons, poorly described, incorrectly documented or reported, not confirmed... This increases the work of the R-core which needs to spend more time triaging issues and deciding with which issues they spend their time with, which impacts on the time they actually spend on R and their motivation.
Recently there have been a call for help from the R-core members that resulted in a successful increase of closed issues. However, in order to make this more sustained and get the R users more involved with reporting and helping fix R bugs a more permanent solution is needed.
To make it easier for them filling or interacting with could be done from R bugRzilla goals are twofold: make it easier to access data of R issue tracker, and make it easier to interact with it from R itself. The first goal is almost done, the main goal of this project is the second one. With data of the history of issues and the community the goal of the project is to make it easier to review issues, submit a new high quality issue from R itself.
While previous effort to interact with bugzilla exists (bugtractr)) they are abandoned, there are errors and don't allow to interact with it beyond downloading its data. Also they do not provide a way to download data using authenticated means, which for some analysis might be relevant.
Studies about issues and process can provide a lot of information about the communities and provide insight about how a process goes. Which can help identify roadblocks an change the process to improve them, or find the best way to navigate them knowing what to expect. For instance this study helped confirm 'semi-periodic' fluctuations on CRAN submissions.
Once paired till the beginning of the coding months we would get to know each other and our respective backgrounds (career, goals, interests, ...). If you are not familiar with the different groups of people or navigating through R we would start with these. Also set up a good working environment for a successful project (integrated development environment, version control, code style, agree on a schedule...)
There are 10 weeks for coding if you need some break or can spend more time one week but not others this schedule is amendable on the pairing months:
Week 1 to 3:
- Get bugzilla account if you don't have one already (Familiarize with bugzilla).
- Increase test coverage (Familiarize with the existing code base).
- Gather data about existing bugs, history and stats and report it to the R community in a blog or website.
Week 4 to 7:
- Write helper functions to fill good issues.
- Provide functions to comment issues or run code from issues.
- GSOC: middle evaluations and review of the progress.
Week 8 to 10:
- Document in a vignette how to interact with bugzilla users including submitting an issue and commenting on other issues.
- Prepare for CRAN submission and initial public announcement on mailing list and social media.
- 1-2 weeks of buffer (polishing with users' feedback, wrap up the project)
The impact of this project on the R community is to increase participation on bugzilla by a broader pool of users and increase the quality of new R issues. This in turn will help to reduce time spend by the R-core reviewing R issues freeing them more time to actually fix the issues or advance the development of the language. This depends on the communication and adoption by the community but at least the project will help identify the low-hanging fruits to work them.
On the student, I hope it will familiarize with writing a package, writing test, interacting with an API and prepare a package to submit to an archive, understand and know how debugging or patching is done and identify the process for better interaction with other's code. Also it will introduce you to the community, possibly getting in touch with the R-core and other organizations like R-forward.
Students, please submit your tests resolution (even if you don't complete the task).
- EVALUATING MENTOR: Lluís Revilla Sancho <lluis.revilla at gmail.com>, package developer of several packages (BioCor, BaseSet, experDesign) and author of several analysis about the R community, see my website, involved in Bioconductor, rOpenSci and R-forward. Ph. D. student on bioinformatics.
- Co-mentor: to be confirmed, tentatively Dr. Heather Turner , R-forward leader, author of several packages (BradleyTerry2, forwards, gnm, PlackettLuce) among other involvements with the R community (check my website).
Students, please do one or more of the following tests before contacting the mentors above. In parenthesis the skills that will be evaluated.
- Easy: Find the first 5 issues posted on bugzilla (Check familiarity with code and data)
- Medium: Create a function that opens on the browser a desired bug report on bugzilla. Create some test for the function you created previously. (Level of technical skills)
- Hard: Propose a plan (no need to provide code but it is welcomed) to analyze issues: What questions would be interesting? How would you answer them? (Critical thinking and independence)
Students, please post a link to your test results here.
- EXAMPLE STUDENT 1 NAME, LINK TO GITHUB PROFILE, LINK TO TEST RESULTS.