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

@@ -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
+url="https://gitlab.gnome.org/GNOME/gtk/issues/new">file a bug report</ulink>
-documentation.
+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
+undocumented exception to the rules, please
-url="https://bugzilla.gnome.org">https://bugzilla.gnome.org</ulink>.
+<ulink url="https://gitlab.gnome.org/GNOME/gtk/issues/new">file a bug report</ulink>.
 </para>
 
 </answer>

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 
+file a bug report on our
-<ulink url="https://bugzilla.gnome.org">https://bugzilla.gnome.org</ulink>.
+<ulink url="https://gitlab.gnome.org/GNOME/gtk/issues/new">GitLab project</ulink>.
-We'd also appreciate reports of incomplete or misleading information in 
+You should also file issues if the documentation is out of date with the
-the GTK+ documentation; file those against the "docs" component of the "gtk+"
+existing API, or unclear.
-product in Bugzilla.
 </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
+not only for bugs. We track all GTK+ development in GitLab, to ensure
-the way to be sure the GTK+ developers won't forget about an issue.
+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
+If you develop a bugfix or enhancement for GTK+, please open a merge
-Bugzilla as well. Bugzilla allows you to attach files; please attach a
+request in GitLab as well. You should not attach patches to an issue,
-patch generated by the <command>diff</command> utility, using the 
+or describe the fix as a comment. Merge requests allow us to build
-<option>-u</option> option to make the patch more readable. All patches 
+GTK+ with your code applied, and run the test suite, on multiple platforms
-must be offered under the terms of the GNU LGPL license, so be sure you 
+and architectures, and verify that nothing breaks. They also allow us to
-are authorized to give us the patch under those terms.
+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 
+You should follow the <ulink url="https://gitlab.gnome.org/GNOME/gtk/blob/master/CONTRIBUTING.md">contribution guide</ulink>
-<ulink url="mailto:gtk-devel-list@gnome.org">gtk-devel-list@gnome.org</ulink>. 
+for GTK+, available on GitLab.
-But be sure to file the Bugzilla report as well; if the patch is only on the 
+</para>
-list and not in Bugzilla, it's likely to slip through the cracks.
+
+<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>