On Fri, 2015-02-13 at 18:43 +0100, Sébastien Wilmet wrote: > On Fri, Feb 13, 2015 at 06:20:15PM +0100, Bastien Nocera wrote: > > On Fri, 2015-02-13 at 18:15 +0100, Rick Opper wrote: > > > Then how will project devs know if a bug is - as the status implies - > > > not yet confirmed? It may be a problem with a single users unique > > > setup, > > > > Which is still a bug, and it's still "new". > > > > > or a design decision > > > > RESOLVED WONTFIX > > > > > , or caused by something specific to a certain distribution... > > > > RESOLVED NOTGNOME > > > > > Isn't that the point of this tag? > > > > There are other statuses available which already cover those cases. > > It's useful to distinguish UNCONFIRMED and NEW. Some products in gnome > have many hundreds bugs, and triaging all of them takes a lot of time. > What you suggest needs to triage _all_ the bugs. > > For example in gedit UNCONFIRMED means that the bug is not triaged. With > NEW, you're sure that the bug exists (or existed) and should be fixed > upstream. For someone willing to contribute, searching in more than 400 > bugs is not really convenient. So by filtering the search results to > include only the confirmed/NEW bugs, it's already much better (it's what > is advised for newcomers on the gedit wiki).
Then opt-out. I can tell you that UNCONFIRMED isn't used in, at least, gnome-shell, gnome-settings-daemon, gsettings-desktop-schemas, gnome-control-center, totem, totem-pl-parser, gnome-desktop, gom, grilo, or grilo-plugins. _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
