Re: [Audacity-quality] When to post to -quality WAS Re: [Audacity-devel] Cancelling Timer Record recording

[Gale A. <ga...@au...>]

| From Vaughan Johnson <va...@au...>
| To aud...@li... 
| Subject [Audacity-quality] When to post to -quality WAS Re: [Audacity-devel] Cancelling Timer Record recording
> On 5/29/2012 1:37 PM, Gale Andrews wrote:
> > 
> > | From Vaughan Johnson <va...@au...> 
> > | Mon, 28 May 2012 22:13:42 -0700
> > | Subject: [Audacity-quality] [Audacity-devel] Cancelling Timer Record recording
> >> On 5/28/2012 12:31 PM, Gale Andrews wrote:
> >>>
> >>>> ... Should have been on audacity-quality to begin with.
> >>>
> >>> Arguable either way I think. I've been frustrated recently by
> >>> others posting what looked to me like -quality posts to -devel.
> >>
> >> I don't see how that is your justification for you doing exactly that,
> >> posting a -quality post to -devel.
> >>
> >> Others did what you thought was wrong, so that justifies you doing it?
> > 
> > Didn't you think it was "wrong" too? :=)
> 
> I wrote that it should have been on -quality, so obviously I thought it
> wrong to post it on -devel.

Hi Vaughan

I only really looked here to see what you thought about where
to post at release time, but to try and aid clarity... 


> My understanding of what you wrote is that because you thought other
> people had posted to the wrong list, you purposely did so. Not likely to
> achieve the presumable goal of getting people to post the right list. 

OK, so if we want everyone on Team to post to the correct list 
then all "errors" must be pointed out, whoever committed them. 

Right?   


> >>> But I think we have agreed that to err to posting to -devel only
> >>> is a lesser sin than cross-posting. 
> >>
> >> Disagree. I think it's better to move it when it was originally posted
> >> to the wrong list. We had a good long spell in the drive to 2.0, where
> >> the distinction was observed, and I think was very useful. 
> > 
> > I see the issue is as it always was, Vaughan. 
> 
> And I still see it as an invented issue. Here you go again.
> 
> Clearly this thread was about user experience, not code, so belonged on
> -quality.
> 
> 
> >There are a few areas
> > such as extensive correspondence about testing where it would 
> > seem unambiguous and beneficial to use -quality. 
> > 
> > But if someone wants to discuss issues with users enabling SnapTo
> > in error, or losing their timed recording, coding decisions must 
> > be involved and the decision is greyer.
> 
> Not at all. Those discussions are about user experience, not code. If we
> agree to do something about them, then yes, a developer will have to
> change the code, but that has nothing to do with the discussion.  

OK, so if the technicalities of how to implement the desired 
behaviour as code needs to be discussed, we have to move the 
thread from -quality to -devel at that stage, and Cc it back to
-quality when the code change has been made (so the -quality 
thread comes to a proper conclusion). 

Have I got that correct?


> >The people who posted 
> > about SnapTo, Timer Record and other emerging bugs didn't want
> > to cross-post and presumably thought the content was closest to
> > -devel. 
> > 
> > I agree this worked tolerably well in the drive to 2.0.0, at the 
> > expense of some issues:
> > 
> > * cross-postings to -quality and -devel 
> 
> Those should be rare. The times I did it were RM announcements.
> 
> 
> > * content posted on -quality which was code, so inscrutable 
> >    to other than developers    
> 
> So you're saying somebody posted to the wrong list. That's the error I
> was trying to address.
> 
> 
> > * fragmentation of the archives (because people not on Team
> >    will always post "quality" issues to -devel).  
> 
> Why would they ever do that, much less always?  

They do that. I can barely recall any posts to -quality made by 
someone not on Team. Can you? 

If such posts are forwarded consistently to -quality, then it 
should be OK. Right? 


> > It worked horribly during 2.0.0, which I guess is why there have 
> > been few -quality postings since then. 
> 
> I totally disagree that it "worked horribly".
> 
> 
> > 
> > I'm fine with erring to post on -quality when identifying and 
> > discussing bugs, if everyone on Team is going to do it. I'm
> > fine with extensive posts about how to code an agreed 
> > solution moving to -devel.     
> > 
> > And I'm fine with not using -quality at all during the Release
> > Process.
> 
> Why special-case it?  

I would think as James pointed out, because we have enough to 
do at release time without getting two copies of the same posts. 

Recent posts to -quality were not responded to by developers. 
I am not sure if that is because -quality has a lower priority
when developers are extra busy at release time, or not.  

So, if a new bug comes up in the course of 2.0.1 release, where 
do we post to? -quality is supposed to be for characterisation 
of bugs. 

Also are all "new features" always to go to -devel, even if it's a 
new Nyquist plug-in proposed for inclusion? There are quite a 
few I/Steve will want to propose in the near to mid term, so I
would like to do so to the correct list. 

The other approach to this may be to be grateful that -quality 
has helped keep the peace by reducing the volume of posts 
to -devel that we had before, and not care so much about 
"wrong lists". 



Thanks, 



Gale