in the light of current events one problem comes up again:
how do we deal with enhancement requests reported in Bugzilla?

Currently we count 1'193 open GIMP bugs, of which 607 are
enhancement requests. We're drowning in them.

In 2015 Jim DeLaHunt pointed out a discrepancy between the
website and the documentation, see

Unfortunately the topic wasn't discussed, but still persists and is
in a current case time consuming and going blue.

In the past I already closed bugs as INVALID until they are agreed
upon on the mailing list, but it wasn't considered the best solution.
Actually we put the bug on hold, but Bugzilla has no bug state for this.

How about this:
1. On enhancement requests we check for Bugzilla duplicates and former
mailing list discussions. On duplicates and formerly disagreed requests
we close the bug with a suitable reason as DUPLICATE or WONTFIX.
2. If the request is not a duplicate we answer with an friendly stock
answer and ask to bring the topic to the developer mailing list.
If it's a pure GUI topic, then to the gimp-gui mailing list.
Until the topic is discussed with a clear result, we set the bug into
3. On agreement we set the bug into state NEW, otherwise close it as
If the reporter refuses to post the request to the mailing list, then
either we post it there if we think it's useful, otherwise we close
it as INVALID.

If no further discussion is ongoing we close the bugs after an agreed
period of time, e.g. 3 weeks since reporting.

The goals are getting useful feedback, while keeping the bug base small.

It would be nice if we found a final solution now and made it clear at
the website and in the documentation.



gimp-developer-list mailing list
List address:    gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Reply via email to