diff --git a/en/gnome/docs/Makefile b/en/gnome/docs/Makefile
index 84b2c748a5..ca115bd647 100644
--- a/en/gnome/docs/Makefile
+++ b/en/gnome/docs/Makefile
@@ -8,6 +8,7 @@
.endif
DOCS= faq.sgml
-DOCS+= porting.sgml
+DOCS+= porting.sgml
+DOCS+= bugging.sgml
.include "${WEB_PREFIX}/share/mk/web.site.mk"
diff --git a/en/gnome/docs/bugging.sgml b/en/gnome/docs/bugging.sgml
new file mode 100644
index 0000000000..cd5178ee37
--- /dev/null
+++ b/en/gnome/docs/bugging.sgml
@@ -0,0 +1,82 @@
+
+
+
+
+ %includes;
+]>
+
+
+ &header;
+
+ Reporting a bug
+
+ 1. What to report?
+
+ The rule of the thumb should be: report as much information as you
+ can, because even if there is some irrelevant information usually
+ developers could quite easy filter it out. On contrary, situation is
+ much worse when there is too little informaton to reliably track down
+ or reproduce the problem - in this case developers have to speend their
+ time guessing and/or asking originator of report to send more
+ information.
+
+ There are plenty of examples of totally useless bug reports, something
+ like "Hey, gnomefoo port is broken. I'm running FreeBSD-X.Y.
+ Please fix." Nedless to say, that such report is just a waste of
+ your time, time of the appropriate developer and network bandwidth.
+ At the bare minimum the report should include the following
+ information:
+
+
+ - Exact version of the operating system (usually output of
+ uname -a).
+ - List of all packages installed on your system.
+ - Your environment (output of /usr/bin/env).
+
- If you are building from ports then approximate time when you was
+ last time updating your ports tree.
+ - Information specific for each type of breakage: full log of
+ unsuccessful build in the case when the build of the port is broken,
+ stack trace in the case of coredump, clean and detailed description
+ of the problem when application does something unexpected etc. Try
+ to put yourself into developer's shoes and in each particular case
+ evaluate what information would be necessary for him to locate the
+ source of the problem, don't just assume that he alredy knows all
+ about the problem, but is just too lazy to fix it.
+
+
+ If you have a solution or a workaround for the problem then include
+ it into your report as well, even if you are not quite sure that this
+ is a correct fix, even if it is not it could give developer idea about
+ what to look at and save him some time.
+
+ 2. Where to report?
+
+ There are several ways to report a bug in GNOME running on a FreeBSD
+ system: you could send report to the freebsd-gnome mailing list, file
+ a problem report in FreeBSD bug reporting system, send your report
+ to the particular GNOME developers via their bug tracking system or any
+ combination of those.
+
+
It is impossible to define guidelines that will clearly tell you where
+ to report in each particular case - you have to use your own common
+ sense, however some rules follow:
+
+
+ - If the problem is FreeBSD-specific and transient (e.g. checksum
+ mismatch, patch failure, syntax error in port's Makefile etc.) then
+ report to the freebsd-gnome mailing list.
+ - If the problem is clearly not FreeBSD-specific and you have no
+ readily available solution then report to the developers of the
+ software directly (for most core GNOME components this means that you
+ need to use their Bugzilla bug tracking system).
+ - If the proble isn't a FreeBSD-specific, but quite serious and you
+ have a fix available then report both to FreeBSD and authors' bug
+ tracking system, so that the appropriate port will be patched and
+ other users of FreeBSD will be able to benefit from your fix, without
+ the need to wait for a next vendor's release.
+
+
+ &footer;
+
+