Re: abandoned bug reports

[Dmytro O. Redchuk]

On Tue 15 Feb 2011, 18:26 Graham Percival wrote:
> On Mon, Feb 14, 2011 at 01:42:05PM +0200, Dmytro O. Redchuk wrote:
> > As for me --- sometimes it takes *too much* to follow threads (yes, my 
> > English
> > is much worse* than it may appear).
> 
> How much time?  Could you record this next time?  i.e. at the
> beginning of your time on Monday, do you spend 2 minutes catching
> up on emails?  5 minutes?  10 minutes?
> (and do you have your email setup with the filtering we recommend
> in the CG?)
No, actually it looks like this: i am flagging (shift+f in mutt) as important
another new (which possibly discusses new issue which has not been added to
the tracker yet) thread, reading all thread's messages thoroughly (for, yes,
30 seconds to let's say 90 seconds depending on the topic, the thread, my
workload, conditions around me etc) and deciding whether i _possibly can_ deal
with this problem or it is _too hard for me_ ("next time" is possible too).

If i think i can (so, i am ~60 or more percents sure that i understand this
issue and it is "valid issue" -- and there is no discussion with opposite
opinions between people) -- i start to test it (sometimes i've added
modified snippet, simplified or "enhanced") and then add it to the tracker.

If i think that i don't understand "what's they're talking about" -- i skip
this thread (have it flagged, with a hope that sometime in the future i'll
have better mood or conditions).

Of course, i am flagging as important every unanswered new thread regardless
of day of week.

After "processing" all threads this way -- i look into "issues to verify".


Probably, this is an "ideal model" of my "workflow" -- i am pretty sure i am
much worse self-organized, then i described .)


Oh, well, regarding "email setup" in the CG: no, i didn't follow it. I have
set up (mutt: local delivery + imap/google) a bunch of folders/filters/hooks,
i don't want to register another google account, i am pretty happy with that
what i have. I've read some 5 or 7 times that section, found it quite
reasonable and helpful but decided that my own "layout" is good enough.

Now i feel like it's not a problem to deal with mailboxes. l~F for all
flagged... i know you know.


> If it takes 10 minutes (or even the full 15 minutes!) to delete
> the emails that have already been processed, that's fine -- just
> let me know, and I'll think of some suggestions for dealing with
> emails, or a different procedure, or something.  But at the moment
> I just don't have enough information to make any good suggestions.
No, it's not a problem to deal with mailbox.

Sometimes there appears "relatively long" discussions, and -- for me -- it's
almost impossible to follow those threads and _understand_ "what's they're
talking about". With my english, programming and music notation skills, and
knowledge of LilyPond.

And i think "oh well somebody will understand this having spent much less
effort, probably".

> Ultimately, I was expecting a 50% turnover every year in the Bug
> Squad, so I spent a lot of effort defining your jobs as precisely
> (and easily) as I could.  That's why I'm disappointed that, after
> six months, we still have emails getting lost.  :(
Documentation is good. The problem is outside of it, surely.


Some "side" thoughts, like dreams, which, possibly, would help bug squad
people to survive. Unordered, too few to order.

Would be great if:

 * ... bug-lilypond would be for reports, not discussions.
    Sometimes it's quite difficult to separate, but would be really _great_ if
    every kind person followed "the rule" (i invented it right now): "If
    unsure [i mean not 93 or more percents sure] that this is a bug -- discuss
    in lilypond-user, or lilypond-devel *please*".
    Surely, everyone has his/her own percents -- it's not a problem.

 * ... every issue report in the tracker would contain code to verify with.
    If it needs to be modified -- if should be modified. Yes, i know that not
    every issue can be verified with a snippet.
    Issues with no description and a snippet (for instance -- with a link to
    discussion, which may not contain a valid snippet at all) are the hardest
    to deal with, because _already reported_ issue needs to be "investigated"
    in some sense.  If developer's time too valuable to make good report --
    well.. i don't know... my time is too valuable to decrypt bad report,
    sorry. It is the matter of my incompetence, probably, -- it's ok, i can
    live with that ,O)
    Strictly speaking, there is nothing about good and bad reports in CG, but
    i believe you can agree with me, at least partially.

I don't mean that these can solve the problem, it is outside of that.
But it could help a bit. Very little bit, but anyway =:O]

ps. About [in]competence -- working with issues can be good practice and gives
me new knowledge very often! But it is a matter of efficiency, too -- every
time i may make a decision (probably wrong) how to spend my time. Better
reports are easier to deal with. Worse reports may not appear to be of
interest. Get me right. I hope "i am with you!" (as Carl said some time ago).

Thank you.

-- 
  Dmytro O. Redchuk
  Bug Squad