Digested

A user/packager/developer/sycophant finds a bug, needs to communicate with a developer to alert them of the issue. The information goes into a huge, unwieldy database that only the most intrepid and dedicated read, probably to rot. And we wonder if adding another field would solve the problem.

This is a social communication issue. How many patches have languished in bugzilla for months? The system encourages the gathering of useless information, and actively prevents access to useful data.

Maybe the whole paradigm is borked. I'm sure there is a wealth of useful data in bugzilla. Just like there is in the box of papers I hauled to the dump the other day. Anything really important will show up again anyways. Bad news always comes back.

First off, developers know what are bugs and what are just unfinished features. Unfinished features are on a list somewhere and don't need to clutter a public database.

Anything over two weeks old automatically drops to /dev/null unless it is marked as valid by the developer. Important stuff will show up again. Without the necessity of handling everything, important stuff will be handled.

Some apps that are at the stage where large numbers of bug reports are just noise (see unfinished features), refuse bug reports. The developer probably has the 10 or 20 users that he/she listens to anyways. Once things have matured, open bug reporting to catch the odd corner case.

Force the reporter to make a commitment; don't open a bug until it is confirmed a second time by the user, with more explanation. An automatic email asking for confirmation and more information a few days after the initial report will confirm whether there is really a problem, and if there is, the user will have more data to supply.

Attached patches generate emails to 30-50 developers picked at random from those who have committed recently to svn in a similar module. IOW, patches will be picked up and handled. Derek and Sam stop selecting commits that refer to bug numbers, which probably has encouraged the insanity :)

Developers get a private email address that they give to packagers and those working with them as testers to report directly. When the traffic gets too high, get another email address.

After feature freeze, at some suitable time, open a channel for bug reports such as a mailing list. The flood of emails will probably give a good idea of the state of the release. And a side benefit of focussing attention on bug fixing without forcing developers to wade through mounds of marginal information in bugzilla.

Nurture a category of users; Testers. Recognize these individuals that are available for testing, capable of maintaining a build system and willing to submit bug reports directly to the developer. Developers at the unfinished features stage could then easily find testers to help bring the software to maturity. This doesn't mean closing the development process, rather is a means of providing a resource, and encouraging the communication and collaboration that actually works. And more than likely many of these testers will eventually graduate to development.

Use the coming scripting and unit testing capabilities to allow testers to define correctness. Essentially recruiting regression test writers.

Would KDE developers know what wasn't working without the Total: 9838 bugs and 9141 wishes that are now open? Absolutely. How many developers would rather make an appointment for a root canal than wade through bugzilla? There has to be a better way. Aaron is right. We wonks love deterministic solutions. This isn't a deterministic problem.

Something I ran across:link

I think the fact that these folks are so amicable is one reason why the software has been built so well. When you engage a community of users and developers, there's no room for myopia and one-upmanship, which I've unfortunately seen too much of in certain other projects.

This is in reference to Kontact.

After blathering on at some length about file managers, I ran across some of the ideas that the Appeal project is thinking about. Here is a link to the Content Manager proposals.

This is interesting, and gets the juices running. How to address the challenge of presenting the complexities of data in a way that looks good and is not confusing. The many ways that one document could be presented, or better, the inherent metadata contained within the document (and hopefully collected and collated by something like Tenor) could overwhelm a user, all the while granting the user enormous power. Using the smooth pop-up panes similar to what we see when we hover over an icon in Kicker suggests possibilities. A transient and 'melting' overlay, with possibilities of further drill-down and instantaneous back-out permits deepening levels of complexity. The more you drilled into an object, the more detailed the overlay. This would be very similar in action to taking a pile of papers, flipping through them, glancing at the ones that seem pertinent until you find the one you want. Easy in, easy out. If you find what you want, or want to bookmark or keep your thumb somewhere, allow a level of overlay to be opened as some kind of container.

This overlay view could apply to folders, either virtual or physical. Overlays would show different paths of inquiry or action, leading to another overlay or action screen. Some kind of visual or textual representation would show the user where they are.

When the same data is presented in many different ways and contexts, it is very easy to get confused. This has been the downfall of virtual file systems. Actually confused isn't the right word. It is difficult to remember how you got somewhere. It doesn't take very many levels to get confusing. This week I was working in a complex that has a new control system for their ice plant. The graphical display shows the equipment status and allows changing setpoints and viewing logs. There are 6 major screens. Everyone including me had to click on a few different views before finding what we saw before and would like to see again. But, and this is important, to do what I needed to do required access to much more. Similar to KDE users opening Konsole to do routine tasks that are cumbersome or impossible to do graphically.

A minor nit, and perhaps an important philosophical point. Please please please don't forget something so basic that we can miss it; computers are tools for managing complexity. If I have two documents in my life that I need to handle, edit, send, or whatever, two only, I don't need a computer. The internet, birds, flowers, cultures, scientific pursuits, any endeavor is appealing to us due to the infinite variety that is presented to us. We love abundance. That is why we have 250 gig hard drives. If you are doing a mockup, put 20, 30 items in it. It will change how you view the problem. Or at least force us to think about how we can easily get it down to two or three.

What I want in a File Browser(tm). Or what I don't want, and I think would be a mistake.

Some obvious things are speed. Instantaneous display of folder contents is an absolute. If it takes as long to display a moderately sized folder as it does to open Konsole, Konsole wins.

I don't want a gui designer to tell me how I should organize my files. Design decisions force usage. If a small number of files in a folder work best, then the designer is telling me I should work that way. No.

The current thinking is to somehow model real objects to help us understand simple concepts (We spent a few years learning to read, but we really don't want to use that). In the past, any large amount of data that needed to be sorted, stored or retrieved had some intermediary who did that for a living. Think executive secretary, librarian, the ancient scribes and secretaries. For what I have in my home folder and descendants, I would probably have needed two or three people to keep it for me. The objects I can keep track of in spatial memory are few. The rest are thrown in closets or piled on my desk waiting for me or someone to sort through them. Any screenies of 'spatial file manager' conveniently shows 3-6 objects in each folder. Spare me. What we need to model is the parsing, sorting and retrieving capabilities of a good librarian/secretary.

A good example of this is iTunes, although I ran into a flaw within 15 seconds which renders it unusable for me. It models a very narrow minded librarian who cannot fathom anyone being interested in anything but music. For music it works well, with a few hints allows you to find what you want. But it only works with a very narrow data type. Let me explain.

I heard that iTunes had audiobooks. And indeed they do. So I installed iTunes for Windows using Crossover Office. It is an older version, so maybe things have changed a little, but it illustrates the point. I found the audiobooks section, clicked on it and got a bunch of categories; non-fiction, history, mysteries, etc. Great. So I click on Non-Fiction and what do I get? A list of authors. Bah. You have to select each one individually to get the book title. If you search on something, it returns music selections and audiobooks. There may be a way of fine tuning this, but frankly I gave up. Life is too short to try to shoehorn a piece of software vision into my reality.

So a file representation that works well with one type of data may work horribly with another.

Another very irritating thing, this time about Konqueror, is the difficulty in narrowing the displayed files. In my home folder, if I'm looking for a pdf file, I can conveniently type /home/derek/*.pdf. I end up with half the screen showing subfolders, with my pdf files at the bottom. That is full sized screen. If I want to split the screen in two for easy moving, all I see are folders. This is where I look for the little X button and open Konsole.

By the way, is there any way using the mouse to do a wild card sort on a particular metadata? In list view there a limited way, but icon view?

I want an easy way to drill down into non-hierarchical data, with an obvious and very easy way to back out. I want to be able to use applications to handle their data effectively, without knackering the file manager. I want the file manager to recognize and respect the hierarchical structures that I build, at the same time ignoring them when I'm trying to find something. I want the file manager to recognize my skills of pattern matching and filtering out unimportant data.

If you have ever worked with a good secretary, you know what I want. Remember that job we did over at so and so's? I want to see the engineering calculations I did, or didn't we have a mechanical failure similar to the one we had yesterday? Who did we talk to about that? A good secretary will have the answers for you in a very short time. I want my computer to do the same thing for me. Let me throw things on her desk, and have it at my fingertips. But don't touch this pile. I'm working on it right now.

I don't want to have to enter a bunch of data to have this happen. If I download a document, create a spreadsheet or KWord document, I don't want to have to fill in a bunch of metadata. I would prefer not to have to create a file name either. The computer, like the secretary, knows (or should know) what I'm working on, what the file is about, where it came from, and where it should go. Sometimes I may want to be specific, but most of the time not. The computer can read, can't it?

Being fussy and miserable, damn the computer that does things without telling me, and doesn't allow me to override it's decisions.

I haven't found a graphical filemanager interface that matches the power and flexibility of the command line. I suspect that most of the audience here hasn't either. Shouldn't a good gui filemanager be far better than the command line?