Re: Debian does not have customers
Russ Allbery schreef op 24-09-2016 1:12:
Bart Schouten <list@xenhideout.nl> writes:
I think the point that people are trying to get across is that a lot
of
what you say Russ feels like excuses.
An excuse is when you know you should do something but aren't going to
do
so, and are trying to justify that decision to oneself. That's not the
disagreement here; rather, we have a very fundamental disagreement over
what people should do.
I rather doubt we have that a fundamental disagreement.
Sorry to say it in this way (that is not my clear intent here ;-)) but
often times I just think that when someone says "I disagree" I wonder if
they've actually understood what I've said, but since they sometimes do
not summarize what they think I've written (or said) I have this
peculiar notion in my mind that they're talking of a different thing
than I was ;-).
I hope that is fair enough here.
You believe that I should be doing certain things in bug management,
and I
don't agree with you. It's not an excuse for me to tell you that I'm
not
going to do the thing you want me to do because I think you're wrong.
:)
Maybe you don't even understand what I think you should be doing ;-).
Maybe my explanation was just not very well done and now you're
defending against accusations that were never made ;-). Or against
"desires" that were never really expressed.
It's a way for me to say "I don't agree with you and you haven't
convinced
me."
When I mean "excuses" I mean the kind of things that sound like "I
haven't taken the trash out because the sun was too hot." Maybe for a
person (for one person) the sun being hot is a good reason (excuse) not
to do something, for another it just sounds like an excuse, you know.
Sometimes "There is a lot of literature on this subject and experts
agree that ..." sounds like an excuse because those experts aren't here,
those arguments aren't made, and it's an external authority that has no
place in a discussion or debate; hence it will always feel like an
excuse because it is not a real argument to make.
To give perhaps a weird example: non-food-grade vinegar is perfectly
edible. If you mix "cleaning vinegar" with say tropical fruit juice (the
thick kind) you get a kind of drink that feels really strengthening and
anyone with half a mind would know that if this stuff is only harmful in
high concentrations, dilluting it to the point of not having much
"vinegar acid" anymore will make it well.... just vinegar.
They call it "non-food-grade" based purely on the concentration of the
acid, so if you dilute it, it becomes food-grade. But people will then
cite the "experts" that say that you can't drink it. You gotta keep
thinking for yourself, you know.
So when you cite "experts" I don't know what drug those experts were
abusing while not creating a functional system, to put it a little
'aggressively' like that ;-). As you say below, and as you attest to
below, having a second way to classify a thing can never change the
fundamental functioning of a system. It is theoretically impossible that
adding a second "closed" state with more meaning would create a
non-functioning system when before it was functioning. That's not
possible.
So if I then hear talk about "experts" analyzing systems, I wonder what
kind of systems those were and if they actually agreed with what I just
proposed, and I think not, actually.
It's not that I'm not hearing you; it's just that I don't agree.
Well and sorry to repeat it, but I also wonder what you mean by my
statements if you do not summarize them and only characterize them.
It feels more like talking past each other than anything else.
If we had some other state in our bug system other than closed that
also
gets the bug off my view and makes it disappear from the various
tracking
statistics on, say, the Debian package tracker that I'm trying to keep
clean, I would probably use it because I'm kind of obsessive about
classifying things.
Hey, don't blame yourself, it's a good thing, to a certain point ;-).
Sure, if you can turn that "open" bug into a "shelved" bug and make it
disappear from "open bugs" lists then that seems like a perfect outcome,
right.
It means a little more differentiation just turned it into a better
system, right.
This is why a fundamental disagreement with the "closed" state for these
kind of bugs is important because it can improve the system, and ...
perhaps you've already agreed in a way without saying so (or while
criticising your self ;-)) (for it) that an extra state would be handy:
- it does not appear on open bugs
- it does not appear on closed bugs
- it does not give the person the impression that his/her bug is getting
totally ignored
- it does give the impression "Okay, my bug is getting recognised, it is
not getting wiped, I have been heard".
The /only/ thing people have an issue with is not getting heard.
Using a lot of white space just to make that more visible ;-).
All people want is just to be heard and not for their message to be
thrown into some dust bin.
People are only ever after one thing: acknowledgement.
If you can give people acknowledgement, they will get off your back
instantly (for the most part, if it is sincere, etc.).
This is simply because /acknowledgement/ implies that a responsible
person has heard and understood. Once a responsible person has heard and
understood, we don't need to harass that person anymore because we can
be safe and sure that the person will act on his/her own accord now.
I once engaged... with the author of a commericial Windows package. In
the end he said "I don't agree with everything you've said, but you've
struck a personal chord with me there."
That was everything I needed and I just let it go at that point with the
complete confidence that something good would come out of it.
The reason people are so frustrated with Linux bug tracking systems or
respondents from the maintainers or developers of packages (or often
even the world around that; the fanboys, or the support people, or the
ones who are interested in such package or program) -- is that so many
times what we say isn't acknowledged.
I will even go as far to say that some of the global problems we face
today is the result of some people not ever being heard, at which point
they eventually turn "extrememist" in order to /be/ heard.
Actually listening to people and saying "Okay, what you say is right, I
hear you say, I hear your side of the story, I have understood what you
want and what you are concerned about, leave it to me to think about it,
I can't promise you anything but I can see that this is important, not
just to you, but perhaps to the whole situation, so thank you."
One author once phrased this as: "What hurts you so much that you feel
you need to hurt me in order to mend it?"
If someone changed the BTS, I'd shrug and change what
I do. But I don't feel like this is necessary or particularly
important.
Well.
If the frustration of people with bugs being called "closed" without any
action having been taken on them, is important, then it is.
You could phrase that as "being taken" (on them).
If the frustration of people with bugs being called "closed" without any
action being taken on them, is not important, then it isn't.
What is important to me are two points: one, that we (as much as
possible;
this is hard, for all the reasons pointed out in this thread) tell
people
if their bugs are unlikely to ever be looked at if this is the case
rather
than just silently ignoring them, and two, that we be very clear that
the
existence of a bug (particularly a non-RC bug) does not create an
obligation for the maintainer to fix it.
Two points with that, that you have really already recognised:
- there are different kinds of "unlikely to ever be looked at" -- there
is the kind where you can say this thing with 30 seconds of your
attention, and there is the kind where you have /already looked at it/
but you have decided /not to look at it further/. These are different
classes of bugs.
The first class would be:
- received, looked at (read), considered insufficient for any kind of
processing, closed with reasons stating such
The second class would be:
- received, looked at (read), considered important, thought about,
related to other bugs, not considered sufficient as a standalone bug to
be evaluated any further, and closed (shelved) with not enough leads to
go on.
But it's just important not to /call it/ closed because it has many
implications that are not warranted here. Closed means "dealt with" and
that is also a signal to other developers that the bug /contains no
interesting information/ or /does not merit looking at again/. You
cannot redo every piece of work constantly.
* The one closing the bug performs a function for others that will not
need to look at it.
* The way that the one closing the bug classifies the bug, gives other
people information, it is a summary
* If the summary is done right, it gives the correct information, or
proper information, and those other people will have been done a service
because they do not need to repeat the same work over.
You work as a team and this classification is a service to your team
mates that do not need to repeat the same classification; it has already
been done for them.
This saves time later on as you study what needs more attention, for
example.
So you need to be able to depend on the classification of bugs because
if it is dependable, it saves you time.
And then it saves the whole system time.
That is why I would personally say that a system with only 2 states for
every bug (say), "open" or "closed" is not very potent to say the least
and does just not offer a lot of benefits in that sense.
I mean to say that personally I would conclude from this analysis that
having more states would be a good thing because it gives more
information to other people that don't need to repeat the same work of
reading the bug or classifying or judging the same bug from the
beginning again.
The whole reason to classify is to encode information and if this
information is only 1 bit, ....
And then people get mad with that.
I don't know, I think just in many cases that when people have a kind of
moral or political argument, what they are really "bitching" about is
things that result from a certain system or the constraints that a
certain system poses on them.
Things that can go wrong in a Skype chat, or a YouTube comment thread,
between people, or whatever communication medium you have, these days
especially, the fact that you cannot use any formatting in email makes
it harder to read long texts, which makes it harder to write long texts
(and get away with it), the fact that HTML is not very well suited for
the formatting of emails, etc. etc. etc., all imposes limits on the
communication of people that can hinder them in getting the point
across.
Misunderstandings often arise because people are not perfectly capable
of dealing with imperfect systems.
Part of my work as a programmer, of course, is to improve those systems
;-).
But I haven't really been able to lately :(.
Anyway, that is all I can say on this subject almost.
Facebook is not a place for meeting new people.
Skype is not a text messenger service.
Whatsapp is not a place where you can safely meet someone new.
Instagram is not a place where you can really talk to anyone without
them panicking all the time, and without being "hurt" by social
appearance or popularity or status quo of interrelations between other
people.
Kik is not a place where you can really keep contacts around and hence
use it is a instant messenger service.
Email is not a place where you can see whether the other has read your
message.
Bugzilla is not a place where you can be positive and inspiring.
Google is not a place where you can NOT be distracted by other things as
you are trying to do some work.
Jabber never took off with anyone, it seems.
Google Hangouts is too far removed from YouTube, etc. etc.
The world is full of broken systems.
I feel communication was easier 10 years ago.
Anyway, too long, too much.
We all want to fix bugs, but we do that as part of a volunteer project;
people aren't always going to have time, energy, or desire, and that
has
to be okay, or we will lose the volunteer efforts of people who would
be
able to contribute occasional work but who don't want to incur the
obligations of letting Debian maintainer work turn into a second job.
I think that should be the goal of anyone here.
Reply to: