[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: list of usability-related aKademy discussion
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2004-07-26 8:36:29
Message-ID: 200407260236.29848.aseigo () kde ! org
[Download RAW message or body]

On Monday 26 July 2004 02:08, Frans Englich wrote:
> I think the last couple of hours have shown we are pretty well covered up
> in this area :) For example, my KControl(kdenonbeta/kcontrol4) is 650 of
> LOC and is built on Designer files etc. so it's easily changed(I think
> Benjamin's version is up-to-date too). I'm sorry -- we're pretty good
> covered up on the code front :) I estimate it is very likely our upcoming
> KControl will have a design similar to Benjamin's and mine.

i agree, but also disagree. it's interesting that over the last year having 
discussed to <explitive deleted> death what components MUST be present in a 
new KControl, that those coming up with new designs keep missing several of 
those items. the iconview idea is great and a step in the right direction. 
but it's just a start, and not the end. moreover, there are KDE devs who 
aren't involved (and won't get involved) in kde-usability that NEED to have 
input on this (for reasons that should be bleedingly obvious). i intend to 
help rectify that @ aKademy.

note that this is not because anyone is a crappy developer. it's because 
things such as kcontrol are hard to get right on a list such as this. there's 
too much noise and too little high-bandwidth communication.

> > i don't want to do this via email and irc as i'm tired of typing the
> > volume of text implied by such discussions;
>
> Yes, we all are. That's one reason to why both Benjamin(I think) and I push
> for a "formal KControl document" -- to set one discussion in stone.

yes, i think this is a good idea: a living document that contains our 
collective KControl wisdom =)

> > i'm looking forward to face-to-face
> > discussion =)
>
> If you discuss KControl, remember the conclusions have to be rock solid and
> be able to handle the usual kde-usability-noise -- otherwise they will be
> useless. I, and perhaps others who's not going, sees aKademy as a private
> email discussion wrt to decision taking -- you will have to write such a
> formal document, and be prepared to see it be critized, as any other
> decision. (Makes sense right?)

we'll be writing code there as well. just as you, Benjamin and others have. or 
did you first write and pass a long formal document here before writing code? 
did you get everyone and their dog to help you write that code? no, you 
discussed it with various people and got to the business of writing code. and 
that's the way it should work.

i've attended previous KDE annual meetings virtually via IRC, and you can do 
the same. it turns out that development at such events is, in practice, no 
more nor any less closed and limited as any usual devel in KDE =)

> But I would skip discussing KControl on aKademy because it would lead to
> much friction. 

that's silly. the whole point of these yearly meetings is to work on the Big 
Issues. or do you simply not want other people's input?

> Benjamin, Jamethiel, Walter Benoit, and I have done tons of 
> work and are most up to date wrt to KControl(AFAICT) --

i could add several names to your list of "up to date wrt to KControl". 
several of them will be at aKademy. few if any of them are on this list. 
viewed that way, kde-usability is a private email discussion as well. i hope 
you'll agree with me that that's a ludicrous statement, and therefore so is 
the same statement regarding aKademy =)

> and neither one of 
> us are going[1]. We have tons of documentation and code, and discussing
> KControl without us would very likely lead to our work being discarded, and
> our knowledge not being sewn in.

woah, woah, woah. why do you think i posted here? to ignore your work? if i 
wanted to do that, i would've gone quietly to aKademy and said nothing here. 
i WANT your input, including what aspects of your work done thus far you want 
addressed. e.g.:

	status of current work
	future direction of current work
	points of conversation you are interested in seeing addressed and/or want to 
be involved in

> In other words, it is a quite a big chance 
> you will return from aKademy, report your work, and we say "you missed this
> & that", and "we have already written that & this" etc.

thanks for discounting the 100 or so KDE devels who will be @ aKademy 
off-handedly like that, but i'm willing to take that chance all the 
same.  ;-)

> I think the above mentioned people and the work that have been presented,
> is more than enough for reaching a great result. Skip KControl on aKademy,
> leave that to us, and go full speed on the other issues -- anything else is
> taking too much risk.

heh. you seriously want less involvement rather than more? because you are 
concerned your views will be stomped on? that's not how meritocracy works, 
nor is it why i'm opening this discussion (as i already covered earlier in 
this mail).

to be frank: already several important items have been missed in the current 
kcontrol revisions various people have come up with. you've also hit home on 
several things. we have several parallel development branches in CVS (3 or 4 
at last count) and that simply isn't sustainable (we need ONE branch to 
eventually land in KDE4).

in the nature of open source development, aKademy will be a place where we can 
build on those successes, extend them further and help figure out how to 
merge efforts. this is a bazaar, not a cathedral, no matter where it happens.

> The KDE Usability Articles project is, from my viewpoint, the biggest thing
> that have happend for KDE on the usability front in a long time -- it

=)

> affects KDE deeply from an organizational perspective. It is important its

which is why it needs open discussion, not quiet and closed development.

> have been reviewed. Let's see how things evolves during the next two weeks
> -- eventually I'll write a short paper which can bring people up to date(as
> good that can be done), and we can do a Q&A on IRC so you can represent it.

that would be great. if you can get this together, i'll be certain to get it 
discussed @ aKademy.

> * Perhaps you could split up the reporting between different people("you
> blog about meeting X, I about Y" for example)

i'll see how it goes when i get there...

> * Sound record the meetings(suggestion..)

nice, but doubtful unless someone can hook me up with simple audio recording 
equipment and a place with lots of bandwidth to upload them to. =/

> * Write reports about:
>    * What people that was present and their roles("Joe have done this and
> that, currently do Foo, and works for Hema"). Small one-liners :)
>    * What was decided, and why
>    * What ideas that was turned down and _why_
>    * Of course not overly detailed, but everyone must know what was
> decided, so we don't step on our toes on future work, or know who to
> contact if one wants to know more/join development

forget the stepping on toes crud: that's an attitude for failure. we need to 
simply assume that what we are doing is done in spirit of preventing all of 
that. i want to be able to communicate what happens @ aKademy as it happens 
clearly and to represent the voices of those who can't be there for 
usability. if we're successful (which we will be), there will be no 
toe-stepping-on. so i don't want to phrase discourse in those terms. i'd 
prefer it if you didn't, either.

in other words: relax, this is KDE not an Evil Empire =)

as for medium of communication: should i simply use my blog or is there a 
preferred mechanism? (i'd prefer not to use a wiki. don't like them. =)

> In short; when aKademy is over, it shouldn't appear like a "fork" in
> development -- we who wasn't there should be able to slide into your work
> and we /all/ continue together with your accomplishments. As we know;
> resolving conflicts is a mess.

you are missing the point entirely. these meetings aren't a fork. they are a 
continuation of what happens in the normal day-to-day development of KDE, 
simply sped up due to the ability to do it all in person.

so please... can we start this conversation again, but this time with you 
providing a list of things you would like discussed, things you'd like to be 
involved with, work you've done, working you will be doing, directions you 
see things taking, etc?

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]