Russ Allbery schreef op 21-09-2016 19:56:
Xen <l...@xenhideout.nl> writes:
I would simply suggest that in principle you keep bugs open until it
no
longer exists. But that you introduce a different open state other
than
closed that will communicate "has been looked at, is not capable of
being solved right now". This could be "pending" or "held" or
"kept". Because "closed" indeed communicates "not-a-bug" or
"works-for-me" or "invalid" or "fixed" and not "frozen".
I recommend reviewing the literature around how to manage development
backlogs. There is quite a bit of thought in this area, and this
approach
is widely considered at best useless (the holding area just becomes
another way of spelling "closed" because it accumulates so much stuff
that
it becomes unsearchable and no one looks at it) and at worst actively
harmful.
I get that no one wants to hear "no one is going to look at this bug in
any reasonable time frame." It's not a pleasant thing to hear. But
it's
vastly superior to just not hearing anything. You're making a mistake
that lots of people make with bug tracking systems: in a desire to be
non-confrontational and to never deliver bad news or provoke hard
conversations about prioritization, you're erring on the side of not
communicating at all or communicating in weak and ambiguous ways. This
can create unrealistic expectations on the part of the bug submitter,
which are later dashed. This is just bad all around, and it leads to a
lack of trust in the long run.
If no one is ever going to look at the bug again, just close it. It
feels
more confrontational, but it's far more honest, and it doesn't create
unrealistic expectations. (Obviously, try to do this politely and
constructively!)
I agree with Adrian that honesty comes in more forms than this.
You know probably just as well as I do that often times when you mention
the slightest of difficulties with any software package to anyone on any
Linux mailing list or forum, the first thing they often tell you is
"Have you filed a bug?" or when they are feeling particularly insincere,
they will ask "what is the bug number of the bug you have filed?" all
the while knowing you haven't yet filed anything, you were mentioning it
"here" first.
Then, when you proceed down that path, you find that it is often very
hard to get any one to look at the bug or to not close it instantly
because it does not agree with the position of the sun in the sky that
very day.
Now Granted, if Debian is a distribution maintaining packages of
software that comes from some upstream place, it is going to be very
hard for Debian maintainers to be responsible for the bugs or errors in
those packages, because... they are not.
Particularly in the case of something like Gnome anything that's wrong
with it needs to be handled upstream, there is no other way.
But telling people to file bugs constantly on the one hand and then
opening some waste bucket on the other hand where you "deal" with them
is no fair way of doing business in that sense, and certainly not
blaming or accusing Debian as the only culprit here, if at all.
Personally, as I've said, I find that "bugzilla" bug systems are very
user-hostile and something like Jira is already much much much much
nicer.
for the simple reason that a Jira issue tracking system is also a
creative outlet for suggestions and ideas, and not just complaints.
I think the point that people are trying to get across is that a lot of
what you say Russ feels like excuses.
You say "there has been a lot of thinking in the field" but that's just
an excuse.
If "closing" has any meaning then it must be some definitive state. If
some bug is nothing but petty complaining, fine.
If a bug report is too vague to consider, fine. You can state that as a
reason.
But normally, just saying, that unless "upstream" never even takes note
of the "downstream" bugs and hence bugs become "out of date" or
"outdated" due to changes, or something of the kind....
Anything that exists today is going to exist tomorrow unless it is
changed. Fixed. Reverted. Averted. Developed. Anything.
"Closed" means closed. It means the bug has been handled (or the report
has).
What if someone else comes across the same issue? Is the semantically
correct thing to do now to reopen it? And then what? For it to be closed
instantly again?
If you can say "the bug has been acknowledged but we can't really do
anything with it right now" I think that is "confrontational" enough and
actually semantically correct.
"Closed" doesn't make you want to look at the bug. Not even if you are a
developer interested in it.
If you say "on hold" or "held" or "frozen" or "acknowlegded but shelved"
(acknowledged but "sleeping") creates too much of a backlog then that is
a practical issue that doesn't warrant lying about the actual state of
the bug.
Just an analogy:
If you have a dam in a lake and the dam needs to let water though or the
lake will overflow on occasion. And the population was promised for this
to happen only once a week because during the water passing the lake is
less usable.
But the numbers don't add up and you have to do it twice a week. But to
comply with policy you will not admit that these are actually regular
outflows, but you are gonna name them something else like "emergency"
happenings. Then you could call that "confrontational" but you're in
fact avoiding a direct confrontation because you are using a sort of
dishonest way of /naming/ things in order to deal with a practical
problem.
You really /should/ be calling them "sleeping" or "on hold" (not meaning
they will be addressed later, they have just been shelved and will not
be looked at again, this is not some postponement I was proposing, I am
talking about really shelving those bugs while all the same still
acknowledgeing them) -- or, then, "shelved" -- but this creates for you,
in your mind, practical problems, so instead you will call them
something they are not, which is "closed".
Closed then, is a lie, to deal with a practical problem.
The practical problem is that either the system is just not designed
very well, or there are not enough people to man the posts (which is
like almost the same thing).
And given the way the system has been designed, or is constantly
functioning, which in some areas just doesn't work, you deviate from
what the bugs should be called and just close them prematurely just to
keep the queues down.
That's a practical 'trick' but it is nothing of the sort of a meaningful
design feature.
But you must first acknowledge that you are taking "emergency measures"
and that this "crisis situation" is the reason you are closing these
bugs, and not pretend that you have arrived at some overarching better
way of doing things!!!!!.
If some softare is in crisis (such as perhaps Gnome) and hence creates
an enormous amount of bug reports that no one could ever handle, then
that is the crisis situation you have.
But that doesn't turn "closing as many bugs as you can" into a sort of
elegant "normal" way of doing things.
Again: you are really abusing the "closed" state when it should be
something else, because nothing other than "closed" works (in your mind)
to handle that situation well.
But it remains a form of abuse of a state that is semantically
incorrect.
At least then acknowledge that you are doing so (or someone might)
instead of proclaiming it as the design feature of the century, so to
speak. It is the "best of two evils", it is not something desirable in
itself.
It's a way to deal with crisis, when semantics are not that important.
But don't turn it into a design feature because you will soon forget
that you have a crisis at your hands, and if you don't recognise that
your "closed states" are a way to deal with crisis, you will forget to
deal with /crisis itself/ because you will feel this to be the normal
and desirable state.
What I mean is that if you are going to defend your emergency plan as
the normal way of doing things, as the way you want it to be always, you
won't look beyond it to see where the problem really lies.
You must first acknowledge "Okay, the closed state is not exactly right"
and then say "but we need it because there are too many bugs and not
enough people" and THEN you can look at "why do we have a system of too
many bugs and not enough people?"
But if you accept the abuse of the closed state not only as normal, but
also as ideal, and perfect, that means the crisis behind it also becomes
normal, and perfect, and you will never seek to solve it.
Pardon the verbosity here.
you're erring on the side of not
communicating at all or communicating in weak and ambiguous ways
I don't think saying "this bug has been acknowledged but we don't know
how to fix it, or don't have resources to deal with it now, so it is
going to be shelved" is weak or ambiguous at all.
You are saying "yes it is a bug" and "no we are not going to deal with
it".
That's not ambiguous. That's very clear.
You can very clearly communicate that no one is going to deal with it
/even though you have acknowledged it./
And I don't see the problem with that. I think calling it "closed" is
what is ambiguous! Particularly if there is only one singular closed
state!
I think this whole discussion is testament to its ambiguity!!!!!!.
the holding area just becomes
another way of spelling "closed" because it accumulates so much stuff
that
it becomes unsearchable and no one looks at it
There is not a problem with spelling "closed" in another way because it
/differentiates/.
In Spain they have more words for the emotions than in our western /
north-european countries.
In Scandinavia they have more words for snow and clouds than in most
other countries.
In Polinisea they have more words for waves and things to do with water.
/Having more words/ is a good thing if you can communicate more clearly
with it and thus .....render yourself less ambiguous and less vague.
If "shelved" accumulates too much stuff, then "closed" would accumulate
the same amount of stuff, so what is the difference? It makes no sense
to desire "one" state instead of "two" for the same amount of bugs.
With "two" states, at least you encode a little bit more information
into the state. If no one would look at a collection of "shelved" bugs,
then do you think they would look at "closed" bugs?
You will have the same amount of bugs regardless, better have 2 states
for them rather than 1.
Anyway...
