[gtk/no-more-bgo] docs: Point people at the right place for bugs

[Emmanuele Bassi <ebassi src gnome org>]

commit 210d90021b8a2e68b24ac4aba3a5e34240530103
Author: Emmanuele Bassi <ebassi gnome org>
Date:   Wed Jan 9 12:21:08 2019 +0000

    docs: Point people at the right place for bugs
    
    We don't use Bugzilla for GTK any more, so our documentation should
    reflect that change.
    
    Closes #1559

 docs/reference/gtk/question_index.sgml |  8 +++----
 docs/reference/gtk/resources.sgml      | 42 +++++++++++++++++++---------------
 2 files changed, 27 insertions(+), 23 deletions(-)
---
diff --git a/docs/reference/gtk/question_index.sgml b/docs/reference/gtk/question_index.sgml
index 28a470dd1c..9f8af36241 100644
--- a/docs/reference/gtk/question_index.sgml
+++ b/docs/reference/gtk/question_index.sgml
@@ -77,8 +77,8 @@ specific widgets and functions.
 <para>
 If you have a question not covered in the manual, feel free to
 ask on the mailing lists and please <ulink
-url="https://bugzilla.gnome.org";>file a bug report</ulink> against the
-documentation.
+url="https://gitlab.gnome.org/GNOME/gtk/issues/new";>file a bug report</ulink>
+against the documentation.
 </para>
 
 </answer>
@@ -105,8 +105,8 @@ state (explained in its documentation).
 For strings returned from functions, they will be declared "const"
 if they should not be freed. Non-const strings should be
 freed with g_free(). Arrays follow the same rule. If you find an
-undocumented exception to the rules, please report a bug to <ulink
-url="https://bugzilla.gnome.org";>https://bugzilla.gnome.org</ulink>.
+undocumented exception to the rules, please
+<ulink url="https://gitlab.gnome.org/GNOME/gtk/issues/new";>file a bug report</ulink>.
 </para>
 
 </answer>
diff --git a/docs/reference/gtk/resources.sgml b/docs/reference/gtk/resources.sgml
index 05e18084d7..2d9f021f24 100644
--- a/docs/reference/gtk/resources.sgml
+++ b/docs/reference/gtk/resources.sgml
@@ -17,15 +17,14 @@ Getting help with GTK+
 </refnamediv>
 
 <refsect1>
-<title>Filing a bug report or feature request</title>
+<title>Opening a bug or feature request</title>
 
 <para>
 If you encounter a bug, misfeature, or missing feature in GTK+, please
-file a bug report on 
-<ulink url="https://bugzilla.gnome.org";>https://bugzilla.gnome.org</ulink>.
-We'd also appreciate reports of incomplete or misleading information in 
-the GTK+ documentation; file those against the "docs" component of the "gtk+"
-product in Bugzilla.
+file a bug report on our
+<ulink url="https://gitlab.gnome.org/GNOME/gtk/issues/new";>GitLab project</ulink>.
+You should also file issues if the documentation is out of date with the
+existing API, or unclear.
 </para>
 
 <para>
@@ -37,29 +36,34 @@ discussed, we'll add a note to that effect in the report.
 
 <para>
 The bug tracker should definitely be used for feature requests, it's
-not only for bugs. We track all GTK+ development in Bugzilla, so it's
-the way to be sure the GTK+ developers won't forget about an issue.
+not only for bugs. We track all GTK+ development in GitLab, to ensure
+that nothing gets lost.
 </para>
 
 </refsect1>
 
 <refsect1>
-<title>Submitting Patches</title>
+<title>Working on GTK</title>
 
 <para>
-If you develop a bugfix or enhancement for GTK+, please file that in
-Bugzilla as well. Bugzilla allows you to attach files; please attach a
-patch generated by the <command>diff</command> utility, using the 
-<option>-u</option> option to make the patch more readable. All patches 
-must be offered under the terms of the GNU LGPL license, so be sure you 
-are authorized to give us the patch under those terms.
+If you develop a bugfix or enhancement for GTK+, please open a merge
+request in GitLab as well. You should not attach patches to an issue,
+or describe the fix as a comment. Merge requests allow us to build
+GTK+ with your code applied, and run the test suite, on multiple platforms
+and architectures, and verify that nothing breaks. They also allow us to
+do proper code reviews, so we can iterate over the changes.
 </para>
 
 <para>
-If you want to discuss your patch before or after developing it, mail 
-<ulink url="mailto:gtk-devel-list gnome org">gtk-devel-list gnome org</ulink>. 
-But be sure to file the Bugzilla report as well; if the patch is only on the 
-list and not in Bugzilla, it's likely to slip through the cracks.
+You should follow the <ulink 
url="https://gitlab.gnome.org/GNOME/gtk/blob/master/CONTRIBUTING.md";>contribution guide</ulink>
+for GTK, available on GitLab.
+</para>
+
+<para>
+If you want to discuss your approach before or after working on it,
+send and email to <ulink url="mailto:gtk-devel-list gnome org">gtk-devel-list gnome org</ulink>. 
+You should not send a patch to the mailing list, as it will inevitably
+get lost, or forgotten. Always open a merge request.
 </para>
 
 </refsect1>