Re: [Gimp-developer] About closing feature requests as invalid

As  for this detailed intended workflow: it looks like the best of all Worlds,
and is ok for me. Thankyou for all the effort you put on this.

On 21 April 2014 15:24, scl <scl gplus gmail com> wrote:

On  19.4.2014 at 6:29 PM Joao S. O. Bueno wrote:

So, I for one, feel like such requests in bugzilla should be left in
the "New" or "Unconfirmed" state,
with a text inviting the person to discuss it either her or on IRC,

I think 'Unconfirmed' is exactly the state we can use here:
the request is yet to be confirmed - in this case to find out
whether there is a real need for it. 'Unconfirmed' also is
not offending.

From the three alternatives Bugzilla, IRC and mailing list a
mailing list has the best visibility to the target audience
and should in my opinion be preferred.
Currently we use the GIMP developer mailing list but our users
are likely not there, but rather on the GIMP users mailing list.
At the end we write software for users and it's good practice
in open source to listen to the users. On the other hand the
developers are on the GIMP users list, too, so we catch them all.
Therefore I'm for discussing new features on the GIMP users
mailing list.

Another point are feature requests that arrive at Peter's GUI
brainstorm. I find the GUI brainstorm's intention a great idea that
should be kept alive. In my opinion it could also be used to collect UI
ideas for later features, but it should not be misunderstood as a
letter box for feature requests.

My proposal to handle feature requests:

a) A request is made in Bugzilla.
If it is a duplicate: RESOLVED DUPLICATE.
If it is a troll request, like to bring back the 2.6 save behaviour:
If it is a valid feature request: UNCONFIRMED, forward discussion to
the GIMP users mailing list. We set Platform:=all, Importance:=enhancement.
If it is unclear whether it is a bug report or feature request:
forward discussion to the GIMP users mailing listto clarify its
character there.

We reply in timely manner with a friendly stock answer. This is not
meant to fob somebody off like an arrogant company but to ease our own
work. Who likes to use own words is free to do so.

b) A request is made to the GUI brainstorm:
If it is a valid request, then Peter replies shortly and forwards the
request to the mailing list. In the meantime the idea gets the tag 'New
feature' on the brainstorm blog and can be referred from the mailing
list post to clarify the idea.

c) A request is made on a third party website, like Stackoverflow
or a forum.
If it is a valid request, then the present GIMP team member replies
shortly and forwards the request to the mailing list.

2) The topic will be discussed on the GIMP users mailing list.
Yet we should find a default action when no discussion comes up.
Does it mean 'Yes' or 'No'?

3) When the discussion has finished we take the result in a timely
manner to Bugzilla.
If the request is accepted, then it goes into state 'NEW' and we
add a short summary, links to the ML discussion and the UI brainstorm.
If the request is rejected, we close the bug with WONTFIX.
In both cases we add the Bugzilla link to the mailing list thread
for future investigations.

How do you people think about it?

Joao, you mentioned some open requests on the mailing list
that haven't made it into Bugzilla yet. Do you have them at
hand so we can bring them to Bugzilla now?

No, not at hand - when I mentioned I was thinking of my thread on
"set of operations", which Peter described as a way to do "Macros",
I sentto the list 2-3 weeks prior to the LGM
(pause to search reference on the list archives - found:

Kind regards,


gimp-developer-list mailing list
List address:    gimp-developer-list gnome org
List membership:
List archives:

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]