-
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 for 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 R Core members who need to spend more time triaging issues and deciding which issues to spend their time on, which impacts the time they can actually spend on R development and their motivation.
Recently there was 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 R users more involved with reporting and helping to fix R bugs a more permanent solution is needed.
The goals of the in-development bugRzilla R package are twofold: make it easier to access data of the 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, the goal of the project is to make it easier to review issues and to submit new high-quality issue from R itself. You can see some slides about the idea on here.
While previous effort to interact with bugzilla exists (bugtractr)) they are abandoned, there are errors and they don't allow for any interactions beyond downloading the data. Also they do not provide a way to download data using authenticated means, which for some analysis might be relevant.
Studies about processes such as bug reporting, review and fixing, can provide a lot of information about the communities involved and provide insights into how the processes work. This can help to identify issues with the processes, which can motivate changes to improve them, or help people find the best way to navigate the processes, knowing what to expect. For instance this study helped confirm 'semi-periodic' fluctuations on CRAN submissions.
Previously there was a problem with a high number of issues opened that were not relevant to the site or were just requesting for help without consideration of the other sites and means the R project has to help users. To prevent this situation a manual review of each request to join the bugzilla site was implemented. This raised the entry level requirements and might prevent some people to contribute. So providing ways to prevent low quality issues or comments might help to make it easier for newcomers.
After being paired up 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. We would also use this time to 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 an account on R's Bugzilla, if you don't have one already (Familiarize with Bugzilla).
- Increase test coverage of bugRzilla (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 R Core reviewing R issues, freeing up 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 for people to work on.
For the student, this project will familiarize them with writing a package, writing tests, interacting with an API, and preparing a package to submit to an archive. They will develop their understanding of how debugging or patching is done, and the processes of working with another person's code and collaborating on a project. Also it will introduce them to the community, possibly getting in touch with the R Core and other organizations like R Forwards (the R Foundation taskforce for women and underpresented groups) and the R Contribution Working Group (a cross-community group working on initiatives to encourage new contributors).
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> (@llrs), 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: Dr. Heather Turner [email protected] (@hturner), R Forwards chair, author of several packages (BradleyTerry2, forwards, gnm, PlackettLuce) among other involvements with the R community (personal 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. This can be done with the package or through Bugzilla (Check familiarity with bugRzilla code and Bugzilla).
- Medium: Create a function that opens on the browser a desired bug report on Bugzilla. Create some tests for the function. (Level of technical skills)
- Hard: Propose a plan (no need to provide code but it is welcomed as example, no need to run it) to analyze issues to learn how to make high quality 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.
- Damodar Dhakad, https://github.com/damodardhakad/, https://github.com/damodardhakad/gsoc-bugRzilla
- Piyush Kumar [GitHub], [Test Link]