open tasks, jobs, unmaintained stuff, etc.

[Adam Treat]

On Saturday 06 March 2004 9:31 am, Waldo Bastian wrote:
> On Sat March 6 2004 01:34, Adam Treat wrote:
> > > Well, I would say it's about the fine art of finding the right
> > > balance between the benefit of an option and the cost (in the
> > > terms that you mentioned) of such an option.
> >
> > More warm and fuzzies.  I'd love a balanced system.  I don't
> > think many would disagree with this.
>
> Great to have some common ground here.

Yah, but this was always common ground!  I can't think of one person 
who has come forward and said, "You know, those systems that are 
balanced and Just Work^TM are not my cup of tea.  What I *really* 
want is a complete mess with obfuscated and worthless options so I 
can play around all day and not get anything done."

Of course, it is a wide world so please feel free to point out someone 
with such a position.  The main problem with these higgie discussions 
is they inevitably lead to two avenues of discussion: you find 
otherwise highly rationale (see Guillaume) people expounding on 
philosophical/abstract nonsense while making huge generalizations as 
if they were concrete fact OR they degenerate into (see Boudewijn) "I 
like this options so it should stay!" (see View Doc Source in RMB for 
great example)

If you don't want to lose your mind or get hopelessly frustrated its 
best to just stay away unless/until someone comes up with a concrete 
proposal for changing something you care about and then of course you 
can descend into the pits of "It should stay!" VS "No, it should go!"

> > But the real question is whether or
> > not "View Document Source" should be in the RMB?!  Right?!
>
> Exactly. And for each and every one of such option we should have a
> discussion with a documented outcome and then move on to the next
> thing.

Ok, but shouldn't this discussion be taking place on the usability 
list?  I mean, all I see on core-devel right now is people branching 
into the abstract generalizations and the pissing match about the 
kicker config for visible handles.

> The kcfg editor is a good tool because it creates an additional
> potential solution to such discussion, having a wider solution
> space available is always a good thing. To dismiss it beforehand
> based on gross generalizations is rather closed minded. There
> should be plenty of usability issues where it should be considered
> as a possible solution and very possibly subsequently dismissed for
> any of the particular reasons stated in this thread when
> applicable, but not before that.

I love that Zack is working on kcfg.  Definately a Good Thing^TM.  
Still I don't see how this thread belongs on core-devel.