diff --git a/REPORTING-BUGS b/REPORTING-BUGS
index ad709e4ccb7c..6ed518b6f715 100644
--- a/REPORTING-BUGS
+++ b/REPORTING-BUGS
@@ -1,3 +1,47 @@
+Identify the problematic subsystem
+----------------------------------
+
+Identifying which part of the Linux kernel might be causing your issue
+increases your chances of getting your bug fixed. Simply posting to the
+generic linux-kernel mailing list (LKML) may cause your bug report to be
+lost in the noise of a mailing list that gets 1000+ emails a day.
+
+Instead, try to figure out which kernel subsystem is causing the issue,
+and email that subsystem's maintainer and mailing list.  If the subsystem
+maintainer doesn't answer, then expand your scope to mailing lists like
+LKML.
+
+
+Identify who to notify
+----------------------
+
+Once you know the subsystem that is causing the issue, you should send a
+bug report.  Some maintainers prefer bugs to be reported via bugzilla
+(https://bugzilla.kernel.org), while others prefer that bugs be reported
+via the subsystem mailing list.
+
+To find out where to send an emailed bug report, find your subsystem or
+device driver in the MAINTAINERS file.  Search in the file for relevant
+entries, and send your bug report to the person(s) listed in the "M:"
+lines, making sure to Cc the mailing list(s) in the "L:" lines.  When the
+maintainer replies to you, make sure to 'Reply-all' in order to keep the
+public mailing list(s) in the email thread.
+
+If you know which driver is causing issues, you can pass one of the driver
+files to the get_maintainer.pl script:
+     perl scripts/get_maintainer.pl -f <filename>
+
+If it is a security bug, please copy the Security Contact listed in the
+MAINTAINERS file.  They can help coordinate bugfix and disclosure.  See
+Documentation/SecurityBugs for more information.
+
+If you can't figure out which subsystem caused the issue, you should file
+a bug in kernel.org bugzilla and send email to
+linux-kernel@vger.kernel.org, referencing the bugzilla URL.  (For more
+information on the linux-kernel mailing list see
+http://www.tux.org/lkml/).
+
+
 [Some of this is taken from Frohwalt Egerer's original linux-kernel FAQ]
 
 What follows is a suggested procedure for reporting Linux bugs. You aren't
@@ -9,25 +53,8 @@ please read "Documentation/oops-tracing.txt" before posting your bug
 report. This explains what you should do with the "Oops" information to
 make it useful to the recipient.
 
-Send the output to the maintainer of the kernel area that seems to be
-involved with the problem, and cc the relevant mailing list. Don't worry
-too much about getting the wrong person. If you are unsure send it to the
-person responsible for the code relevant to what you were doing.  If it
-occurs repeatably try and describe how to recreate it. That is worth even
-more than the oops itself.  The list of maintainers and mailing lists is
-in the MAINTAINERS file in this directory.  If you know the file name that
-causes the problem you can use the following command in this directory to
-find some of the maintainers of that file:
-
-     perl scripts/get_maintainer.pl -f <filename>
-
-If it is a security bug, please copy the Security Contact listed in the
-MAINTAINERS file.  They can help coordinate bugfix and disclosure.  See
-Documentation/SecurityBugs for more information.
-
-If you are totally stumped as to whom to send the report, send it to
-linux-kernel@vger.kernel.org. (For more information on the linux-kernel
-mailing list see http://www.tux.org/lkml/).
+If it occurs repeatably try and describe how to recreate it. That is worth
+even more than the oops itself.
 
 This is a suggested format for a bug report sent to the Linux kernel mailing
 list. Having a standardized bug report form makes it easier for you not to