From kde-usability Mon Jul 26 08:36:29 2004 From: "Aaron J. Seigo" Date: Mon, 26 Jul 2004 08:36:29 +0000 To: kde-usability Subject: Re: list of usability-related aKademy discussion Message-Id: <200407260236.29848.aseigo () kde ! org> X-MARC-Message: https://marc.info/?l=kde-usability&m=109083236522919 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 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