> But what impression do we want to give the users?
You either fix your bus your self or they get never fixed unless another
one is bored about it and fix it :-)
Actually if we like to get better user- experience we should focus on
bugs not new features... but bugs get only attention if they really
break many user in a worse way.
I already noted that in a recent discussion about the move to GH, where
it was mentioned we can't move because there are so many gerrits open
because we need to work on new feature ...
For Tycho I regular check the list of bugs, ask users for more details
or if the problem is unimportant in the meanwhile and even picking some
for each release to fix them. I think there should be a rule not
starting with new features if you have not had fixed one bug before ;-)
Am 10.02.22 um 11:42 schrieb Ed Merks:
I do keep lists:
https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&classification=Modeling&component=releng&component=doc&component=website&component=Core&component=Doc&component=Edit&component=Mapping&component=Tools&component=Xcore&component=XML%2FXMI&list_id=21197880&order=resolution%2Cbug_id&product=EMF&query_format=advanced&resolution=---&resolution=FIXED
https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=FIXED&classification=Modeling&component=Core&list_id=21197881&order=bug_id%20DESC&product=MDT.XSD&query_format=advanced
https://bugs.eclipse.org/bugs/buglist.cgi?Bugzilla_restrictlogin=on&bug_status=UNCONFIRMED&bug_status=FIXED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&classification=Tools&component=Docs&component=Dynamic%20Working%20Sets&component=P2%20Management&component=Preferences%20Management&component=Project%20Configuration&component=Release%20Engineering&component=Setup&component=Targlets&component=Tools&component=Utilities&component=Version%20Management&list_id=21197882&order=bug_id%20DESC&product=Oomph&query_format=advanced
https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&classification=Eclipse%20Project&component=p2&list_id=21192801&order=bug_id%20DESC&product=Equinox&query_format=advanced
https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&classification=Technology&component=General&list_id=21197883&product=Justj&query_format=advanced
And while you might not keep lists, auto closing issues reminds not just
you that attention is needed but it reminds the users that you don't
keep a list. And it might will tell the users that you don't really
care about backlogs of issues enough to track them. Whatever isn't
dealt with in a few days or weeks will linger for the robot's auto-close
lifetime by which point the reporter hopefully doesn't care anymore
either. Of course the problem is not that we nor you don't care, we're
all just super busy. But what impression do we want to give the users?
That we're so busy we need a robot to help us?
On 10.02.2022 11:28, Mickael Istria wrote:
FWIW, I personally like the "reminder" about old bugs I once cared
about and then have forgotten about, and that often allows me to take
a decision of whether I'm fine seeing them closed (sometimes marking
them as resolved or not important any more), or whether I need to
reopen them with more context.
I almost never do active triaging of those bugs by looking at a bug
list. The only triaging I do happens by reacting to these
notifications. Remove the notifications, and I'll personally be doing
less triaging as a result (for the very little it counts in practice).
If I had to vote, I'd vote -0 for the removal of autoclose, which
means I don't mind overall about the decision, but if it were only me
I would keep the autoclose.
_______________________________________________
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list,
visithttps://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev