r-devel · SaranjeetKaur · Apr 12, 2021 · Apr 5, 2021 · Apr 5, 2021 · Apr 5, 2021
diff --git a/11-bug_tracking.Rmd b/11-bug_tracking.Rmd
diff --git a/12-reviewing_bugs.Rmd b/12-reviewing_bugs.Rmd
@@ -1,41 +1,40 @@
-# Reviewing Bugs
-
-## Python triage team
-
-## Becoming a member of the Python triage team
-
-### GitHub Labels for PRs
-
-## Fields in the Bug Tracker
-
-### Title
-
-### Type
-
-### Stage
-
-### Components
-
-### Versions
-
-### Priority
-
-### Keywords
-
-### Nosy List
-
-### Assigned To
-
-### Dependencies
-
-### Superseder
-
-### Status
-
-### Resolution
-
-### Mercurial Repository
-
-## Generating Special Links in a Comment
-
-## Checklist for Triaging
+# Reviewing Bugs
+
+## How you can help to review bug reports?
+
+Once you are aware where bugs are reported in $\textsf{R}$, a great way to contribute is to help reviewing the bug reports.
+
+Around the clock, new bug reports are being submitted on Bugzilla or the bug trackers (for instance, GitHub issues) of $\textsf{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. 
+
+Note: 
+1. If you want to review bug reports on Bugzilla, you are required to have a Bugzilla account. To get a Bugzilla account send an e-mail to `bug-report-request@r-project.org` from the address you want to use as your login. Briefly explain why you want a Bugzilla account and a volunteer will add you to $\textsf{R}$'s Bugzilla members.
+
+2. More details on how you can review a bug report are available on this [blog](https://developer.r-project.org/Blog/public/2019/10/09/r-can-use-your-help-reviewing-bug-reports/)
+
+### Classifying bug reports
+
+A good bug report is the one which:
+
+1. Clearly explains the bug so that it can be reproduced.
+
+2. Includes the version of $\textsf{R}$, the machine architecture, and the operating system platform on which the bug occurred.
+
+These are the relevant details that should be a part of a good bug report. You can help with these things once you have experience developing for $\textsf{R}$:
+
+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. Check whether the bug occurs on a different binary build of $\textsf{R}$. It is helpful to know whether the bug is affecting: `r-patched`, `r-devel`, or `r-release` binary builds of $\textsf{R}$.
+
+3. Writing a unit test: If the bug report lacks a unit test that should be a part of $\textsf{R}$'s test suite, then you can help with providing it.
+
+This is all helpful as it allows the Core developers and/ or maintainers to classify a bug report properly, so that it can be handled in a timely fashion.
+
+### How to find a bug report or an issue that you can help with?
+
+1. You may find old bug reports or issues that can be closed, either because they are no longer valid or they have a patch that is ready to be committed, but no one has had the time to do so.
+
+2. You might also want to search for issues in topics which you have a working knowledge. When on Bugzilla you can use the advanced search for specific topics. Bug reports are by default public on Bugzilla (unless the defaults are changed to avoid security vulnerability), so you can select from them.
+
+## See also
+
+1. [Reviewing bug reports: Blog](https://developer.r-project.org/Blog/public/2019/10/09/r-can-use-your-help-reviewing-bug-reports/)