forked from r-devel/rdevguide
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy path06-reviewing_bugs.Rmd
47 lines (24 loc) · 3.36 KB
/
06-reviewing_bugs.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
# Reviewing Bugs {#ReviewBugs}
## How you can help to review bug reports?
After understanding where bugs are reported in R (Bugzilla) or in other projects (GitHub/GitLab/R-Forge), a great way to contribute is reviewing bug reports.
Around the clock, new bug reports are being submitted on Bugzilla or the bug trackers (for instance, GitHub issues) of R packages and existing bug reports are being updated. Every bug report needs to be reviewed to make sure various things are in proper order. You can help with this process of reviewing bugs.
### Preparing to review bug reports
If you want to review bug reports on Bugzilla, you are required to have a [Bugzilla account](#bugzilla-account). More details on how you can review a bug report are available on this post on the R Blog: [R Can Use Your Help: Reviewing Bug Reports](https://blog.r-project.org/2019/10/09/r-can-use-your-help-reviewing-bug-reports/index.html)
## Classifying bug reports
A good bug report is the one which:
1. Explains clearly how to reproduce the bug.
2. Includes the version of R, the machine architecture, and the operating system platform on which the bug occurred.
Relevant details should be a part of a good bug report. You can help with the following tasks once you have some R programming experience:
1. Reproducing the bug: If you see a bug report which does not clearly explain how to reproduce it, you can try reproducing the bug and eventually make things easier for the core developer(s) and/or package maintainer(s).
2. Checking different binary builds: Check whether the bug occurs on a different binary build of R. It is helpful to know whether the bug is affecting: `r-patched`, `r-devel`, or `r-release` binary builds of R.
3. Writing a unit test: If the bug report lacks a unit test that should be a part of R's test suite, then you can help with providing it.
These helpful tasks allow the Core developers and/ or maintainers to classify a bug report properly, so that the bug can be handled in a timely fashion.
## How to find a bug report or an issue to review?
1. You may search old bug reports or issues that could be closed. Old bug reports may no longer be valid or may include a patch that is ready to be committed, but no one has had the time to review and commit.
2. You might also want to search for issues in topics in which you have a working knowledge. When on Bugzilla you can use the advanced search to find specific topics. Bug reports are by default public on Bugzilla (unless the defaults are changed to avoid security vulnerability).
## Example of a bug review submitted on Bugzilla
If you would like to see how bugs are reviewed on Bugzilla, the [Bug 16542 - nlme:::summary.lmList with unequal outputs per group](https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16542) is an example where an old bug report is being reviewed. It is tested to see if it was still an issue and a few ways are proposed to resolve the issue.
**Note**:
There is a `#bug-reporting` channel on the [R Contributors slack](https://r-contributors.slack.com/) where you can share your bug report(s) for review/feedback before submitting to Bugzilla. This can help with checking that it really is a bug, that you have included the important information and excluded redundant information.
## See also
1. [Reviewing bug reports: Blog](https://blog.r-project.org/2019/10/09/r-can-use-your-help-reviewing-bug-reports/index.html)