Much, Much Less than "Billion Dollar Bugs" [or] How to get those little annoying bugs fixed?

One greatly contributing factor is the ease with which a person can contribute bug reports. Often all that is shipped with an application is an email address buried in a tarball, which is lost during rpm builds and the like.

Mozilla did one of the best things it could to help with the bug reporting by developing Bugzilla. It made it easy for the community to contribute to bug reports, even though the vast majority cannot contribute to the code base.

Another thing Mozilla has done well is to use the Talkback builds, which report errors back to a central repository automatically. No user intervention needed.

Mozilla's methods, as discribed above by ftobin, are technically sound, but bugs also take on more forms than technical. Dumb GUI design, missing features (not a bug per se, but you get the point), spelling errors, etc.

I don't want to sound picky, but I also meant to encompass the none- technical issues of bugs as well in the article.

Personally, I find a couple of real buddies (in addition to bug buddy,bugzilla, etc.) extremely attractive when faced with any breed of insect infestation. Cursing is more fun in tandem, parellel, tag team, etc. Sometimes it even provokes thoughtful helpful discussion rather than feelings of intense frustration.

What if, in addition to tried and true methods, ( such as et. al. above, tools which help users provide much of the detailed information the developer's need to tackle tough elusive bugs) a project set up a user wiki space.

Advantages

Sometimes it takes several user reports to establish what the bug really looks like. If four or five users are recreating bugs and talking to each other while interactively modifying their online bug reports if may be easier to get meaningful reports useful to new bug killers as well as our busy grandmasters.

Users talking amongst themselves and sharing workarounds can often reduce the impact (and thus agitated emotional flames) on the user while waiting for someone to pick up the guantlet.

This will also start training the users in what is important in reporting bugs so that they can use tools such as bugzilla better.

Neophyte programmers can learn debugging and knock off the easiest ones by working interactively with the best users. Most trolls and flamers will not hang around long when the better users delete them faster than they can type crap and insults in. Cowardly vandals generally look for easy targets.

The FAQs and bug lists would tend to get updated by a healthy community of users.

The better neophyte programmers, with meaningful bug reports in hand, having tracked the bugs down to precise location and consequences might enjoy the chance to work the developers and learn their methods. This will quickly sort out who is actually a knowledgeable grandmaster and who happened to be standing in front of a camera. Within the programming community. This leaves our public relations types to yakk at the press, while our hardcore software engineers train our masters to train our journeyers and interested neophytes, eventually providing a larger pool of potential volunteers labor to spread the burden of training the next wave.

It is my opinion that the semi knowledgeable user that choose to adminster and maintain the wiki site will inevitably learn more about gnu/linux/apache/perl/php/mySQL etc.

Disadvantages (Sorry, only a feeble effort here. I will play devil's advocate later if I have to develop more persuasive arguments and nobody else is interested in forwarding the holes in the scheme.

1rst step should be to setup an excellent how to set up the wiki sites. Resource requirements, detailed installation procedures, administrater mutual support wiki, and caution the ambitious user that it takes a serious committment to community building and a willing to continuously monitor the action on the site on a periodic basis.

The younger computer literate crowd probably prefer the existing stuff, it is working well for them, I assume? Probably need to resort to appealing to the older crowd who are just getting online to find out what all this internet nonsense is about. An anonymous guy that can allegedly design an engine or wing for an SR71 using paper, FORTRAN, and Gould SEL, Dec VAX, or Cyber mainframe (say a quarter of a Pentium 4 or approximately a Pentium Dual?) sitting with twelve or twenty others and Kelly Johnson? CIA myth to deceive KGB? in a room takes a while to convince that yakking and randomly dabbing here and there can produce results when someone see enough of the proposed solution emerging to run off and complete it just for the shear joy of creation. ..... right? Still, maybe he has heard the buzz and is still a bit pissed that instead of piggybacking his spaceplane on a 747, C5, XB70, SST, or supersonic equivalent and exploring the black yonder, the Blackbird he and a few others loved into existence is now considered obsolete, retired, and still classified while still holding most airspeed records.

I know where I might scare up some guys like that from the late Apollo days (they are dropping fast though) and a guy who managed a 2 Billion jet engine rotor modernization program for one of the two big guys, he may or may not be interested. Pretty good retirement location. I know where to find some other folks too. Certainly others here know techical people such as these as well. They would require some serious handholding .... hence the administrator wiki site to show them in an immersive environment how it work. We might only graduate 5-10 percent to serious wiki site administrators, but our software developers have better things to do than babysit linux servers, wikis, and users and every participant would be helpful. Good training for future software developers too, need a lot of knowledge to continually fix, maintain, and use a development system loaded with other people's buggy code.

It would help if we had some open/free business models to point at to assure them that this new hobby could potentially support itself or grow into something.

Yep. Pretty feeble devil's advocate. I could come up with plenty more obstacles to discourage anyone feeling tempted if anyone is interested. Gotta go. In the middle of getting an Oregon directory on http://www.wikipedia.com in shape to support my impending membership drive .... assuming of course that these niggling doubts about the R&D involving full compliance with spirt of the GPL and FDL are being addressed effectively somehow somewhere by someone. Their spirit appears pure but the pesky damn technical and legal details are difficult!

Good news. If there is any serious interest in discussing this in detail in a wiki I am pretty sure the CEO of Bomis would support us working in the business planning section of http://meta.wikipedia if we wanted to do some prototyping. We could get a prototype set up for the next bug rally and see how well it attracted users. Say .... I think I just downloaded gnutella 1.0 in response to some encouragement .... never did installl it. The dependency list was a bit long to tackle home alone and instead I decided to browse wikipedia a bit, put in some spacecraft data, and hit the sack early in preparation for the next day's study of wiki technology.

What the hell. I put a page at my meta.wikipedia workspace. You can add to the above, insert comments propose competing concepts for immediate community attention, whatever. It is an experiment. Maybe our inter open/free project supermob can spontaneously organize a bit. Let us boldly go and find out. mirwin workspace Wow! Almost forget to add the llink syntax. The editor there looks the same but the parser adds the link html.

Duh! Just noticed that I did not tell you what is in it for them. Smack! Bad forehead! I will tell you my guesses (preferably at my wiki space above) if you tell yours and then we can go to sci.space.* and use the guesses to discuss it sufficiently to determine what they really want out of the deal. Oh, by the way. Leave proprietary data at home, the site is theoretically FDL'd.

We get experienced wiki administrater trainee who have been around long enough to keep the anarchy at a productive wiki happy and melee minimized. We get mathmatically literate people interested in using computers to do interesting things with a variety of real world experience. Knowledge of Venn diagrams is required. They will do as they please just as we do. It will take some effort to initiate productive and prosperous projects. Some or many will fail. It is the successful ones that we will reinforce as we choose.

Grgh! Added a section. Hey! I can cut & paste the addition into the wikispace I just loaded. Maybe I will check the spelling and test the links while I am there. Later.

One obstacle to good handling of bugs -- and one that has been mentioned before -- is the fact that many users just don't like to report bugs to project maintainers. They'll complain on every forum except the bug database.

Another problem is that, as SteveMallett pointed out, a user's notion of a bug is quite different from a coder's notion of a bug: "Linux is buggy. It doesn't boot up with a GUI." Of course, since (as just mentioned) many users don't report such things, most developers have no way of finding out.

A good solution to both of these problems may be to release a program early, but also get the program to print a big fat warning upon startup that says e.g.

For experienced programmers only. Do not try this unless you know what you are getting yourself into!

Once the feedback from developers turns positive, the project can then be released to the general public for beta testing. If a coder likes a program, there's a good chance that the average user will like it too -- after all, coders are humans too, they're just different.

That really isn't that bad an idea. It's like a "warning this food product may contain nuts!" label. As long as you can turn the warning msg off the first time you see it.

So, let's assume that now we have eliminated unqualified people from hurting themselves and you with a "< beta" product that is released early. Adoption of the Mozilla methodologies is a working solution, maybe not optimal in each case, but it can work. No? Yes?

Next, how do you motivate programmers to fix uninteresting problems with the program or add features that they personnally don't care about (no personal itch)? I get the impression that, as in the previous article tk pointed out above, annoying programmers with endless requests is a poor idea, but is what happens now. Remember these are things you don't care about, but users do.

ex) Reading their old 'word' docs (data formats), transferring old bookmarks/email address books, having a "start my browser on this page: " option, etc etc etc. These really aren't totally unreasonable types of requests either. They're just boring.

Developers can run "unstable" if they want to get the latest-and-greatest stuff. However, the average user can run "testing", which gets packages from unstable after (2?) weeks in unstable without major bugs. I think that's the best way to do it. If you want to reach a diverse user base in a structured way, package your software for debian.

Indeed a difficult question. I believe however that there aren't that many `uninteresting' problems. As I said, coders are humans like everyone else, and indeed there is a fair amount of intersection between the concerns of users and those of coders. For example, I too would like better support for Microsoft Word files under Linux (though I don't receive that many Word documents to warrant starting a new project). The difference is, of course, that I can solve this problem myself if I want to -- if I ever get into a situation where I need to handle Word documents daily, I may just download wvWare and start hacking away on it.

Thus, I'll think that if there are enough developers interested in a project, the developers themselves will help solve many of these mundane problems -- and at the end of the day, there won't be that many uninteresting problems (as in, problems only Joe User care about) left to tackle, and the maintainer can take his own sweet time to attend to them. That's better than the maintainer releasing a project early to the public, and then having to tend to zillions of bug reports at the same time.

(I may be wrong though...)

The Gnome project has found bug-buddy to be very helpful to get a steady stream of basically useful bug reports.

Though it's still possible to write unhelpful reports with bug-buddy.

Our current challenge is recruiting enough people to help sort through the reports, putting them in the correct places, marking duplicates, marking fixed bugs etc.

More seriously, how about a script or pipeline or automatic routing or whatever it is called to have the mailing list manager create each new bug report or comment sent in to an xml, html, or whatever file to submit to the wiki of choice. Usemod seems popular and there is some kind of interwiki synchronization thingy at advogato.org. So a non wikipedia wiki developer monitoring the wikitech-l list mentioned anyway. It may have been in the context of it does not work anymore I am uncertain.

This duplicate site would seem easy enough to setup. If it attracts users then both mechanisms can be left in service. The tried and true linear time sychronized mailing (useful for public archival so neophytes can get up to speed easily with a bit of reading) and the chaotic self organizing userwiki (useful to allow useful neophyte participation right away whenever the urge hits, also wikipedia has integrated version tracking, pretty useful sometimes). A little garbage initially is no big deal. It will encourage the users to learn how to edit by deleting the machine code routing stuff that slips through. The slow ones can see who is managing to delete nonsense and query them for assistance until somebody decides to write a beginners (VIP, Executive, etc.) tour.

It will also be robust in the case of large scale virus panics. Since the user browser is logging into the central service and not receiving email, those devestating sweeps that mow down vulnerable Windows users may not be a factor ..... a bit irrelevant to hardcore *nix developers I guess. Still there are a few projects out developing for the Windows platform. Gives Windows users nice exposure to open/free paradigm if they are helping manage user support for the Windows projects such as perl, ....? blank sorry oh yeah! Wikis were developed on perl windows or ported quickly there or something. An open source userwiki that runs on Windows will allow Windows Apache users to host the user community site independent of the developer machines and resources. The developers or apprentices can log in via account like any user or anonymously, if they prefer, (as any user can as well) to get a candid snapshot of how things are really going in the community and authentic buzz regarding the product.

That used to be called management by walking around.

Seemed to make my better bosses and colleagues itchy .... hehe.

[[user:mirwin]]

I'm a developer on Bugzilla, and we are currently in a period of active development aimed at making Bugzilla more customisable. One of the key components here is a front-end/back-end separation via templatisation of the UI.

The advantage here is that you can have a template for the "bug entry" script which is as hard-nosed and demanding, or as light and fluffy, as you feel is necessary. You can have developer and end-user templates for the same script.

Hopefully, projects with a Bugzilla set up will be able to produce a "report your issues"-style template which encourages their users to report their problems.

The problem then becomes that of the Mozilla project - how do you deal with 200 incoming bug/problem reports a day? :-) We certainly don't have a problem with people not telling us what they think...

Gerv

If a userwiki automatically has the new reports copied into the database and the links placed into two lists, one for readonly access (Honor system unless somebody feels like programming different, initially post notice at top. Revision control reports changes and orginal can be recovered if vandals or accidents happen.) and one for direct immediate markup, discussion, derision, amusement expressment, alphabetizing, categorizing, speculating, whatever the evolving community can agree and enforce upon themselves however they choose to organize ..... essence of wiki community ..... Mutual freedom and responsibiltiy. Let's have fun and enjoy this common space, I will be me and you be you and we will figure out new rules or at least discuss the olds with them .... newcomers, strangers, aliens, outsiders, others.

Notice that someone will probably create a priority list for wandering developers with his priorities at the top.

Someone else will write a script to automatically log in after 4 a.m. collective aggregate average time and randomize or reprioritize in preparation for early morning wandering developers. It will be hilarious! Well worth getting up. The hell with Maxwell House, too much caffiene is dangerious with tripping the light fantastic at the murky edges of known mental spaces.

Post a notice of a fix method of the top priority and watch the topsy turvy. Include a humerous warning that it probably has bugs and needs some more work but a journeyer can probably take it from here. I will get back to it next week if I have the time. Keep your committments and manage the expectations well .... some of these users may be working grant proposals or business plans or resumes to take one last shot at improving their local space. Be careful. You want some things from these users after all and they are unlikely to be interested in assisting you if no protocol for civilized behavior can negotiated. From no trust where, how?

It will accelerate the process if you write or point to some summaries of proposed local customs and the local wiki features. Point at a sample healthy site that the users can understand or relate to or get some help. Wikipedia.com is building such a resource as we speak. Drop in and wander around a bit. Check the entry on your favorite rock band. Ever wonder where Murphy's law originated? Run the search at Wikipedia or go though technology, space technology, rocket sled. I found out working on this entry. Murphy is a real person, he worked a few miles down the street from me separated by a decade or two. Amazing.

1. Get a simple wiki space running (hopefully on user/adminstraters dedicated server, find some money to buy and send them one if you really want some results. That what I intend to do in a year or two. First I have to help get Wikipedia on track and get my own next gravy train set up and help train several community subsets and superset access agents and convince them that an approach to tackle several problems we encountered a couple of years ago in our methodology has been discovered and is currently being prototyped.

2. See if you can find somebody to write the script or configuration file or router or whatever the hell you decide to use to get editable files loaded automatically into your wiki from your report address so it integrates well with your project. It may be nothing more than echoing to another mailing address provided by your wikiadmin/owner/founder/autocrat/whatever. It may involve doing the programming yourself. Check back in a few months if you cannot find anyone to program it. I have some buddies that will do this for me when I ask nicely. It is time to call in some favors and start creating grubstakes and tickets. Since I need this myself, if no one else manages/produces/develops/post the necessary script I am going to get it done. I doubt that I will program it but you never know. I have the books, equipment, experience, etc. Just not the specific particulars.

3. Edit your wiki for fun at least one a day. When satisfied that external users can find the FAQ and Fundamentals and draft local etiquette guide and proposed ratifcation/negotiation/public discussion/debate/rules of engagement/whatever, then ....

4. Write a proposed mission statement and post it prominently. See Mission Statement on front page here. This statement probably biased the direction the lcoal community has taken just a bit, so I think anyway. Many people here think it is no longer applicable to the local community and dislike my personal experimentation methods. So what? Raph warned them. I warned them. The owner has not excommunicated me by deleting my accounts. Despite the simulated cert war or Kelly Crusade my buddies stood firm with against the Troll Overlords and now I am contributing, a bit. Maybe this seed will grow, who knows?

5. Accomodate diverse styles, opinions, deficiencies, etc. as collegially and effectively as possible. Be friendly. Chit chat about a subject of interest to the other people if possible. Express appreciation of good ideas. Build on success, ignore failure. Everybody has a bad hair day occasionally .... who should they talk for a morale boost if not their buddies at their local community? Moderation! Too much exposure to depression leads to depression. Share some joy once in while and forget you problem of the moment if possible. A toothache in America is just not as bad as being targeted by an American missile carrier 3 miles above (rise), 4 miles thataway (run), for a scalar value of ... ?? 9+16 = x*x x=5 ? How long to hide if it arrives at mach 2?

You still here? Asking me to solve your problem in the forum of your choice rather than the one I proposed? Have you at least cut and paste there ..... corrected a typo? I will be checking in there today. Yesterday was disappointing. ZERO, nada, zip, no initiative by anybody but tk who also prefers his own methods. Cool! Hehe .... it was correct usage as I applied it in at least one location in this thread. I added my opinion of the dragon book's explanation. Also a reference and colorful description that I saw somewhere before and remembered by checking the picture out on my out of date edition.

6. Thing about how it is appropriate to make money off the site. Resources do not grow on trees, well not in the U.S. anyway. I mean not that we use, they have to be put in plastic and marked 500 percent before suitable for consumption. If you do not need the resources then be sure to let your administrators know that you have deep pockets. I recommend caution with this approach. Simple math and experience shows that if more comes in than goes out the pile grows, if more out it shrinks. With zero allocation responsibilites or judgment or personal cost ..... Asymptotic? Consumption, not production. Consumers are O.K. (especially with electronic products), active parasites consuming more than they produce are detrimental to the host.

7. Salt the mine. Be prepared to tackle the first few top bug priorities as per the apparent/alleged/instantenous user consensus prioritization. Data management is their mutual collective responsibility but some signs of benefit from applied efforts is neccesary initial investment to build morale if you wish the site to succeed. If you do not wish to the site to succeed then do not waste people's time. Grumpy gray matter is extremely dangerous and we already have plenty around here.

8. Be flexible. If they are taking responsibility and doing the work let them do it their way. Presumably they learn from mistakes or they would be attempting to abandon titanic Microsoft products. Try to keep the lifeboat within swimming distance. We have a diverse passenger list here on planet Earth. The universe is watching!!! 12 Billion known sentient controlled camera systems on this planet disregarding other species, it is not the sinkers in water that are dangerous. It is the ones behind you watching you push them under while cackling "Let them eat cake."

9. I do not know. I have done this before. Only noticed a correlation between a couple of working systems a few weeks ago.

10. Your guess is as good as mine. Shall we do some science and experiment together?

I know what is in it for me.

Can you articulate for yourself and others what is in it for you?

If you prefer the clean version of the above, check the link provided in the previous post in a couple months. Maybe a better version will be there, if it pleases me or my buddies to provide it. We may choose to run off and make or beg for some money instead, or at least find somebody fun to play with while creating the future.

later, mirwin

Mozilla obviously doesn't have a problem of receiving too few bug reports; the sheer quantity of duplicate reports attests to that. Mozilla seems to have a different problem -- many bugs simply don't get resolved. In fact, many never seem to even get assigned to anyone!

Bug #40867, for example, is nearly 2 years old now, has 148 votes, is marked with a "blocker" severity, and is still classified as "NEW". Couldn't it at least be assigned to someone willing to take responsibility for making sure it gets fixed? Even "simple" bugs like #82151 don't get fixed in a timely fashion. (Would it really be so hard to add a simple test somewhere to fix this?)

Many bugs, especially the annoying little ones, get ignored completely (whether posted on Bugzilla or not), or generate endless discussion without progress. I've been ignoring annoying little bugs in Mozilla for years, and I'm getting tired of it. I don't know how much longer I can "keep the faith" when so many bugs never get fixed, and so many others keep appearing at random in places where things used to work. I've had newer versions of Mozilla break printing, crash on me randomly (taking dozens of browser windows usually), and otherwise scream "buggy" at me as a user.

As a developer, I'd love to help out with the code, but Mozilla is an enormous and fast-moving target, which makes it almost impossible to get up to speed in the limited free time I have -- and I've tried. A million lines of code is a lot to contend with. Hell, I expressed an interest in writing a telnet client module for Mozilla when it was first released, and nobody responded. I never did learn what it would take to do that, so I never have. Years after I made my offer to work on such a feature, a request for exactly that was eventually filed in Bugzilla, though I didn't discover it until just now. I find it ironic that ChatZilla is in the core Mozilla code, but a builtin handler for the standard telnet: URL form generated no interest...

Meanwhile. how long should I continue to believe the same claims that the latest nightly is great and that 3-week-old version is crap? Why should I have to reproduce a bug on a version less than a week old before a bug will get even the slightest attention? Even when I do reproduce a bug, it never seems to get resolved, so why bother? Hell, even if I track down the exact source code change where a bug was introduced, it doesn't get fixed. (But duplicate reports show up.)

I've been a Mozilla (and "Open Source") supporter from the beginning, but at this point, I don't know how much longer I can hold on. I think I'm starting to feel JWZ's disillusionment with the project, and I don't like that prospect. Look, I know that it's a big project and it's had a lot of work to accomplish, but really. Four years? Even starting from scratch, it should be in better shape by now, considering how much time and effort has been poured into it...

Mirwin, why do you keep on bringing up wiki in this? In my (very end-user) experience, it's not an easy interface to get the hang of. We already have a bunch of bug-tracking tools: debbugs, bugzilla, jitterbug (for not losing patches, at least), GNATS, whatever sourceforge uses, and more. There are several sites and apps which have step-through forms for people. (bug-buddy has been mentioned; the XFree86 site has a "fill this in to report a bug" form, and so on).

I wouldn't say any of those are overly intuitive (apologies, gerv :)), but they have the virtue of being wide-spread and many of them are usable offline. wiki is by its nature only useful if you have an interactive web connection up, and that costs money for some of us still. (Yes, this applies to several of the rest, though notably not debbugs.)

I'd be very interested in any insight from the mozilla folks, since they have long used bugzilla as a communications tool rather than a "this is where you drop bugs, someone might mark it fixed later" thing. And now every time I file a bug, it is instantly responded to by one of a flock of volunteers who make it their business to do something with it, even if it's to mark it a duplicate within ten minutes of my entering it.

I have some suggestions on how to ramp up bug reporting, but I'm not sure how useful they are. I'll add them when I have something a little more organised to say.

I do not know. How should we find out? I propose we experiment efficiently. This does not require massive time or resources or skill.

Personally, I wish to find out if it is a new fundamental tool. If so, it may be a building block of potental vast utility. We can synergistically help out a bunch of new people at Wikipedia doing serious R&D on FDL issues and collaboration methods while we find out. What the hell? Shall we hack a bit and see what the universe thinks?

It looks to me like we can set up functional user communities that could do a lot of the work currently being done by experienced people that would serve to orient and help newcomers self educate. Maybe it will work, maybe not. We could try a small prototype to gather some data.

It scales well if one can afford the computer nets and bandwidth. Many engineers/developers can work on a specification one component each or they can all get intensely interested in a specific problem and deal with the merge conflicts. It solves much of the problem with time lag/design divergence in concurrent engineering.

You stated that the interface is intimidating. I admit I found it bit so when I first encountered advogato. If it does not exist somewhere, I invite you to (anyone) collaborate on a step-by-step user guide for total beginners who have been told over the phone how to power up their computer (I assume it has a functional operating system).

later [[user:mirwin]]

deven said: "[bugs] generate endless discussion without progress". You have come across one of the problems the Mozilla project is still trying to cope with. Because our product ends up in the hands of a lot of people, and because we have a very open bug system and development process, people who have no capability or desire to actually fix things pitch up and add their 2 cents to their favourite bugs. More corrosively, it often gets to the point of abusing developers when those bugs aren't fixed, and people have been discouraged from working on the project because of this.

However, you can't have "many bugs simply don't get resolved" and also "Mozilla is an enormous and fast-moving target". Saying that "A million lines of code is a lot to contend with" is fallacious - you don't need to understand it all, or even very much, to hack on it. You can even hack on Mozilla's front end without compiling anything. I started off fixing one bug in some JavaScript and went from there. LXR is by far the best way to navigate round the source code.

You say "I expressed an interest in writing a telnet client module for Mozilla when it was first released, and nobody responded." What sort of response were you after? "Yes, what a great idea"? For better or for worse, things get done on Mozilla when people start doing them. Most developers are buried in their own bugs. Mailing the last person to check into a file and saying "I'm writing a telnet handler and I can't work out how to do X. You know that file - can you tell me?" would probably elicit a more concrete response than a question like "Is anyone interested in a telnet:// implementation for Mozilla?".

As it happens, Mozilla does now handle telnet using Protozilla. All of the above being said, in my guise as contributor-help, I'd be happy to put you in touch with the right people if you are still interested in making a proper telnet:// handler happen.

"Why should I have to reproduce a bug on a version less than a week old before a bug will get even the slightest attention?". Less than a week old is a bit strong, but because we don't cripple our nightly builds, we often find people reporting bugs on very old ones. Also, often our QA people see a bug report which could be a symptom of a previously-fixed bug, and so ask for a reproduction.

This tends to happen more to people without the "editbugs" and "file confirmed bugs" privileges, which you didn't have until a minute ago.

I, and other people in the bugs you quote, thank you a great deal for your very useful help. In the case of the two bugs you quote, you do seem to have suffered from poor bug ownership. Given that we've only got the developers we've got, there's not much that can be done about this. Apart from more people pitching in to help :-)

Gerv

Bear with me a moment while I fantasize about a solution approach. Sorry Deven, I have to understand a problem or a solution before I can state it precisely or concisely easily. No offence if you simply zip by without reading, happens all the time.

Steve is a genius. He did not ask us to track millions of bugs or fix everything right away. He asked us to fix a few easy ones. For me an easy bug is when I have a diverse set of talent lined up with sufficient resources to do the job. The impatient users can watch and learn from the tech team tag and often (in my experience) seem to enjoy the experience. How many Windows users have been on an asynchonous safari through the code with detailed tracking records of comments on associated talk pages and strategy arguments with links to the project documentation? (I know, watch this ..... I think Telsa is a tech writer and there is something called an open source writers group hanging around, plus anybody in the virtual safari environment can read and type even if they refuse to write well. Odd as it may seem, some people who will not put forward their own stuff will kibitz a bit if they feel comfortable doing so. This can be helpful in various ways. Sometimes this becomes useful cut and paste material and is used, sometimes merely tossed. It is what we keep that counts, not what we throw away.

Bug tracking and nitty gritty detail is for the last elusive ones hiding in the kernal, not your own code. Your own code can be corrected and then who cares about the bug? Besides that is what wiki brings to the table, it keeps all the records and our technical gurus, code commanders, journeyers, apprentices and interested neopytes can focus on the code walkthroughs, debates, techniques, etc. One file at a time on a journey though code and time. This is where the near instant scalabitlity becomes critical. There is no controlling this, tens, hundreds or thousands may be evolving code, documentation, outlines, arguments, etc. or merely indexing, linking and writing hiakus back and forth. The wiki technology enables this massive code walkthough and reverse engineering by keeping all the data. It would be unrealistic to expect a central staff to do all the organization and task planning and tracking with this approach.

Obviously this implies some unit testing after somebody thinks the code works and is itching to compile it and have as their contribution that they pushed the succesful compile button listed in the attribution database. Specifications for what the optimist thinks the file is doing will need to be written and tied into whatever diagrams, tables or indexes somebody thinks will sort this mess out. We are heavy into reverse engineering now. As the incorrect comments get logged and documentation started somebody will note the conceptual error and we will have some collegial discussions to try to figure out what is going on. This will inevitably lead to people coming and going to various files and commenting there in passing as they seek out the information. Finally some agreement on what the file is doing, the documentation is drafted and somebody starts coding the unit tests.

Meanwhile we need to interest an entire set projects in our new grand project. A lot of verbage has flowed through advogato about testing frameworks. I understand the basic concept, we had a sim lab. We are after a framework that is flexible enough to eventually let us run multiple versions of the code originating in different wiki space and compare them for correctness. Eventually we want stable code reporting conflicts so that the newly introduced bug can be backed out ...... or if sufficient diversity and teams have arisen to substantiate an error in the controlled (and certified as best and delivered to the end users) code ....... now we are bug tracking till we can figure out what is going on.

Meanwhile, back to our original chaos. Clearly this is going to take computer resources and bandwidth so I think we need a plan to formally present to Sun (assuming we go after OpenOffice as the biggest target of opportunity, in the interests of full disclosure I shall admit that I have identified OpenOffice as a huge target of opportunity to the Wikipedia community in exchange for their assistence helping us get started with their operational (in my opinion) BETA code. Not the active development stuff. Simply this, a lot of desktop users will get acquainted with their interface and be zipping to Wikipedia chasing a link regarding esoteric computer science when no busy grandmaster chooses to waste his time writing out precise correct definitions or concepts more than once or twice. He will simply enter it Wikipedia and then use quite easily as thus [[parser]] (ok tk, you got me. It was the grammars or dialects at the front end that I see which is different.) Better yet he can simply link to the term or concept and if it is standard but not there then perhaps someone will put it in or a neophyte such as myself will dig out a book and learn something attempting to paraphrase the merge of three explanations the search engine turned.

The improvements in education, vocabulary, and synergistic cooperation as feebly illustrated above do not appear very efficient. I do not know how you would calculate the derivatives but I do know that projects/programs that manage to leverage efficiently off of each others strengths to cover weaknesses while also improving or eliminate the weakness achieve a synergy and productivity that allows apparent miracles. Hence the chalkboard that everybody finds so funny. .... and yes, we seem to want a miracle. Everybodies pet project fixed or contributed to or polished at the same time by fairly ignorant volunteers doing as they please when they please.

Somebody may decide it is efficient to setup an appropriate language seminar, or tutorial. Keep in mind all the data is in the archives and backups. An opportunistic quality engineer and technical guru such as goingware may decide to setup a quality testing seminar or an outline of the types of products and coding techiniques he thinks avoids problems. I may totally disagree and provoke a public argument and challenge him to our first massive fork in the code base ..... not the project. If the code is modular and specified and correct we should be able to exchange the affected modules. There is some more framework development and coding there so unless somebody volunteers or somebody (or a team) manages to write up a coherent propopal (a pitch, winning persuasive presentation) and find the right people to provide it to there is little chance we are getting far here.

Still we are in our own little space self educating ourselves (we impatient desktop users and language deficient script kiddies who gravitate to the chaos) with a little drop in help from some experts to mediate complex technical discussion or drop hints when it seems warranted.

But where is the original developer team you ask? You did not really think that they are going to think an initially small group leading to a massive wave of fed up users and script kiddies with a little help from a publicity seeking wikipedia, a quality project that is falling on deaf ears, a weird idea that even civilians can use top end DOD extravagance if the proposer (that is me) does not have to pay for it and is not responsible for anything at all whatsoever, can accomplish anything do you? Ok, so there is fork three and the voting can commence as soon we can work out the manual methods while waiting for the developers or our hard studying colleagues to get the framework up properly to automate crosschecking.

So as interested parties sufficient to succeed we have:

Sun Microsystems for hardware, bandwidth, expertise?

The developers

Bomis (or Magnus, lead phpwiki script developer) Wikipedia for the ether we will live and breath occasionally

Quality project initiated by goingware if he feels like sitting around and coaching occasionally when and where he chooses to show up instead of preaching all the time.

Linux certification folks might be interested in working with us to setup for us to help draft certification in languages or linux as required.

May need license consulting if code is OSD, wiki environment is GPL's. We will be mixing data and code in the walkthoughs, dialogues, tutorials, documentation, and whatever else someone whips .... remember in the wiki anything goes until we manage to setup a charter and self government. Wikipedia is only getting around to this now after a year as they have hit critical mass and it matters now.

Participatory users

Spectators

Larger community drop in.

Maybe we pick up some help from various advogatees who wish to see this beast and marvel at it different views or perhaps they will go advocate for us when we look successfully enough that they should take credit for launching the bandwagon.

Now, all we have to do is flesh this thing out a bit and see if there is something to make everybody happy and the technical gurus after explaining why none of this will really work, can tell us how it is done properly. If we do not know we can always admit and go ask some experts for their opinions. The debate about why it really wrong may stimulate someone finding a correct approach.

It we were in the wiki environment we could start teaming up around various points of view and refining the talking papers while trying some of the techniques out. We would be missing the chaos from total neophytes but I could probably scare up 3 or 4 on short notice if we want some realism in the proposal development or program conceptualization phase.

I am forgetting something ..... ah!

Everybody sees the problem of course. It will work after initiated. It is merely a matter of attracting enough college students and retire systems engineers. But it has to be working well enough that the engineers think it will attract the manpower necessary or they will not be interested. Meanhwhile the students will wander in, sit around and do nothing for a bit, and wander off. Sufficient people to make the environment interesting initially is absolutely essential. Perhaps with sponsorship and sanctioned occasional participation of their paid professionals during regular business hours from Sun and Bomis we could pull it off. Perhaps if we set up the training courses initially we could attract interest from other high employee count companies. I am uncertain.

I think we should approach SCORE (retired executives) as well. If there is anything that motivates the under 25 crowd like being told by an old fart that their ideas will not work I have not yet discovered. Some of those guys are pretty good at this.

I guess we need more data. Wikipedia seems to have managed to get initiated while my little experiment has had meager results. Anybody see a way to collect empirical hard data to clarify things further?

Now that we have the tiny meaningless stuff and the grand and glorius stuff out of the way, anybody have some small to mediums to chat about? mirwin

While the interface to getting bugs in an interesting topic, it is a bit off topic. (coming from someone who loves to go off topic) 8^)

Getting bug reports of somekind doesn't seem to be a problem. Management of the bug reports could use some work, from your comments above.

I still have serious doubts that developers will fix the uniteresting bugs and would like to keep on that track. I know you can't do it all. I'm very sympathetic. Perhaps uninteresting bugs get addressed more with a higher profile project like Mozilla? Perhaps somekind of kudos/reward system for fixing bugs would be appropriate?

It's rumored that hacks of that gruntwork-kind are well well regarded but who is actually dishing out the kudos for such work? Anyone? Is this an area to address?

If we can deliver value then we can generate revenue and pay bug fixers. Neophytes or developers or teams. Bug bounties or by the hour or both to see which works best. See wikipedia.com research notes for useful background and data on possible market demand mirwin

I have my doubts that throwing money at a problem is the answer. If bug bounties were successful wouldn't the incentive be to generate bugs to fix? I know that sounds overly simplistic.

In that vein.... Lets compare products. M$ & others have money (or cash flow at least) and do not generally make better products. Money doesn't make you make better products does it? I'm being a Devil's Advocate here, but I don't see a huge leap in bug-killing coming from cash. Especially since cash is not a commodity abundantly available to us.

Has anyone actually run any analysis on some of the startups using the community developed commons to calculate an ROI back to the community of original developers? Do we have corporate executives taking care of us as stakeholders? Perhaps Microsoft stakeholders are not the only parasites around.

IMO, one way to mitigate newbie/enduser frustration is to provide some sort of notification, saying particular software is not guaranteed to work 100%, errors may occur anytime.

Another one that I had some experience was the implementation of some sort of error handler that fires off an email to the bug-list. Or an error logger writing to a text file.

It is definitely tougher to manage bugs in the open source world since developers are not insulated from the endusers. Given the situation, it is best that expectations are clearly stated from the beginning so that endusers aren't misled by false information.

So it seems I wasn't correct when I said that there is a fair amount of intersection between the concerns of developers and those of ordinary users. I'm not sure if it's just me, but I get the impression that the developers of Mozilla are more interested in going for meetings, creating new browser themes, etc. than doing real, solid stuff.

Perhaps this is because the Mozilla project isn't something that people (either developers or users) will have a vested interest in: it's more of a showcase for the bazaar development model, and not a very successful one at that. There are so many existing browsers out there that to most people (including developers), the Mozilla project will be among the last places to look. Thus it can be expected that most Mozilla developers won't be interested in fixing `uninteresting' problems.

So it may really be this: the ability of an open-source project to handle bugs is partly determined by the nature of the project itself. Generally, a project which people are really going to use, rather than just toy around with, will have its bugs fixed more quickly -- this is because some of these people will themselves be developers, and it'll be in their own interests to fix those boring bugs out there. Projects like Linux, Apache, X, etc. have come such a long way partly because people are using them for mundane computing tasks on a day-to-day basis.

I had a think about this. I came up with far too much, so I'll attempt to summarise.

The single thing that makes me report bugs is the feeling they're actually wanted. One of the very first bug reports I made was extremely trivial: a typo fix and changing the order of five characters in the default Muttrc shipped with Mutt. I got two replies from two developers both thanking me and the next version of Mutt shipped with it.

And I really felt I'd made a difference, trivial as it was. Inspired, I started sending more, all over the place. Some were fixed, some were ignored, some were flamed, some were marked WONTFIX, some were passed elsewhere, and some were my fault. So I've had a fairly wide experience of reactions.

Ways to stop users sending bug reports:

• Ignore bug reports
• Ask for further information without telling the user what commands to use to provide it
• Mark WONTFIX with no explanation
• Flame the user. Bonus points for in public, referring to standards without explaining what they are and why the user should have known this since birth
• Make fun of the user (not the same as flaming, but just as effective)
• Flame the software the "just shoved in the CD and installed" user is using. Compilers are particularly good for this. After all, everyone should have to replace the compiler their distro provided and actually supports.
• Don't incorporate patches
• Don't explain why a patch is wrong
• Make it impossible for the user to tell which program is at fault
• For software used in countries where access is charged by the minute, ensure they must be online and faced with a bug-tracker that is mystifying and takes some minutes to load in order to send a report.
• Don't tell the user what other software might be involved and thus that it is worth providing the versions of those too.
• Put bug-reporting details only in /usr/(share/)doc/app*/README. After all, every user should check this, info app, man app, the webpage, the FAQ, app --help, app --version and the about box as a matter of routine.
• Ensure user doesn't know whether the report is going to a single person, a mailing list, a newsgroup, an archived group, a website or /dev/null, so that they feel too nervous about their potentially "I did this all wrong" problem to mention it in public.

Ways to encourage users to send bug reports should be obvious from the above. I shall, however, try to write something more useful than that soon.

That's a very broad statement :-) Some people are interested in making themes, it's true. Other people aren't. In fact, we have very few working themes (fingers of one hand) at the moment.

There are so many existing browsers out there that to most people (including developers), the Mozilla project will be among the last places to look.

What other cross-platform browsers are there out there? Opera, perhaps, but it's neither free nor Free, and its DOM support is terrible. The Mozilla project certainly wasn't the last place the Galeon developers looked, anyway.

If you want good reasons to develop web pages with Mozilla, check out the DOM Inspector and Javascript Debugger.

Generally, a project which people are really going to use, rather than just toy around with, will have its bugs fixed more quickly

I agree with this statement; but what makes you think a browser is a project people aren't really going to use? The Mozilla project fixes approximately 1,500 open bugs every five weeks, which sounds like a pretty good rate to me.

Anyway, getting back on topic - Telsa, thanks very much for your very interesting comments. Believe me, I'll be measuring our bug systems against them this evening and seeing how we measure up :-)

Gerv

Excellent points nymia. A note. Be sure the user understands what the error initiation cycle is, knows how to turn it off and/or design its routing list themselves. They may be more comfortable that adequate oversite is in place if they can add echelon, Tom Ridge, and other appropriate designated drop points and/or public serveants, buddies and/or communities to prevent a hostile takeover of their computer. Personally, I think losing one of my portables for the few hours/days it would take to get it restored would be an incredibly low operating expense to turn in the contribution of identifying a spy, child molestor, saboteur, Easter Egg bandit/vandals, preemptive patent and copyright fraud, legal harrassment etc. The intense frustration and years regaining solvency engendered by these cowardly anonymous assassins and femnazis creates enough brain damage in our population at the top that the fallout at the bottom is not addressed. The North American Quack Associations and support groups all have serious combat fatigue. I watched pushers and negligent/exhausted people who allegedly took a Hipprocratic Oath to first do no harm preparing for mass suicide and/or wealthy early retirement to enjoy or end remembering their incompetents as their "self selected" tasks. This allegedly suicide of only "honest" employee of Enron smells, quacks, looks, feels and tastes like a dog turd placed on a massive coverup/fraud ranging all through and around enron and up to the top panels or staffs of alleged USA USG. Why are they afraid to show their homework? I provide realtime data and analsyis of my flaws, impulses, conceits, self agrandasment, fantsay enty points, pretend targets, real targets etc. etc. and invite collaboration in how to analyze and attempt self healing to as much of hte planet as possible for as long as we can access the data. We will learn something from this eventually that will allow the medicine people to begin improving their techniques and how to shield vulnerable people from more damage faster than they can heal and stay afloat. It would be nice if the employees could at least refrain from vandalism while stripping the larder, safe, etc. here in the USA and abroad.

Medically engineers and real healers will do us little good while the representatives and top management are treated with the simple elegance and meager standards available at Walter Reed while the rest of the population is exposed to mass murder, negligence and unmonitored experimentation on duped civilians and militarly professionals under direct orders to step up and be experimented on while assuring incompetent quack command (she must need new star for next infestation) they will obviously, of course keep records and data so that maybe if chalkboards breed themselves to sentient babysitters some solutions can be found to keep some of our 300K from the Gulf War alive until can be dispersed (bodies buried) in the wider public view nobody uses. I must have my privacy! Everybody must cut eyeballs out and blank memories so nobody see my fashion shoes closet. Oh! Excellent ROI for some. See Queen Elizabeth balancing the monarchies budget by ordering the Empirial fleet after success to remain achored. No shore leave allowed and no supplies shipped. No discharge fee or back wages required as no such thing as death benefits. We shall be comparing and contrasting this with the U.S. performance in vietnam and gulf war and see if we can find where the ROI resulted. Should make for some interesting allegations and devil's advocacy synergized exponentially. Userwikis are coming in other formats as a clan does not live on software alone.

If I ever get a note from a child who has loved me by taking time from his busy schedule to help me find the joy to design wind tunnels, skylabs, espionage simulations, space camps, etc. saying a bug/worm{defect/criminal} ate his computer harddrive or data entry form before he could hit return and also erased all his known backups .... My QA people are going to be interested because I am going to be a bit intrigued. I may have to sleep a couple of days after inital data entry or hike the high desert breezeways singing battle hyms and playing the harmonica and/or keyboard at my projected spacecamp, skylab, engine simulater canal (alleged, have to do dimensional analsysis to verfity percieved simularities ..... if incorrent then must finally do tensor work to lean how to capture images triggered by fantasy inputs, see boundary layer turbulent flow theory and reference old methods of inside out symmetry calculations to calculate combustion chamber flows in gaseous nuclear reactors and/or NERVA ...... heat flow and mass dispersion, by recirculated the design mixture at the boundary layer one can run much higher tempatures in the core {h2/lox, nerva, gaseous, ..... ??antimatter?? I love enterprise, a lot of outstanding work and very little looks wrong or boring. History, art, and reality fading into R&D aspects of black yondering, hee ha standing salute and public accolades (here and later wiki, almost finished see? ) to sing the public public love song and design delivery system ala love canal hacker plan/project requesting an accounting to achieve balance. See Steve Miller and Sharon, Agent of Change, Conflict of Honors series.

---- Go back and mark top inital draft requires some serious hack attacks (appropriately combat chattered and carbon collaterated with chaotically overlappling venn diagrams and prototyped procedures and phase lead/lag circuity inserted carefully in places OK

Your children are of course, as per the alleged USA Constitution/public consensus, your private property to prostitute to sadists as you wish ...... or whim or ignorance or whatever ........ privacy ... first refuge of a scounderal or merely dishonest un self disciplined people apparently incapable or unwilling of love? There is no fundamental human rights until we, the people, the clans of man, the sentients of the universe, decide to make it so; shouldering necessary burdens with sufficient love to create new universal law or rough appearances of gain towards until we get their. Consider that I was trained as engineering physicist. Old bench seduction joke. I can be practical if necessary, I think not, critical mass has been achieved and is dispersing sufficiently. We play well and joyfully with proper care and diligence sufficient to make mentors proud and happily amused, and we win. Enemies will melt own brains just as promised by OZmandias. That appears fairly clear to me even though I am zoning a bit. Note the date, check with rirwin, subtley if you can to see if he thinks I am acting abnormally. Ask Major Tom what he thinks, he explained the space shuttle Challenger fiasco to me in terms I could understand while I was still grumpily ignorant and extremely disappointed/frustrated. What the hell, I play safe a little while longer. Go back and mark top inital draft requires some serious hack attacks. ----

tk The developers feel unappreciated and harnessed. What should we expected. I posted public notice at wikipedia that I for one expect some ROI on the massive speculative investment completed by real hackers to top priority. When someone hands you a few billion in intellectual capital for free a non parasite might consider providing some lunch money to someone somewhere in an appropriate way as per their own vision of schemes of things. When we get first transparent public utility online at wikipedia (Or fork if owners like their tools the way they are, Sanger and Jimbo are no fools, they are going slow enough to get something right I would tell you more but I need to use to check answers on essays prior to publication) to finance very necessary expansion and provide lunch money to productive contributors. Contributors can alway pass on and report so or not however they choose. I personally am going to prematurly take piggy bank of plastic 12 ounze? full of change found laying around in streets of USA (true, gold linings?) down and invest in the new Boise Spanish Cultural Center. We have an extensive local Basque community and I am sure all herre can see clearly the implications of venn diagrams and alleged possible business markets above in Mondragon. Unless realtime events have obliterated opportunity. Plan check do research me too you?

---- Wow! Telsa!Excellent researcher, massive data dump. Ok, I sorry for explicit harshness and I will attempt a more colleaguial air when attempting to discuss this stuff rationally in the future. Wikipedia is an excellent learning lab for collaborative editing. We need to get their attribution system fixed though so it tracks everything. The researcher babbling about some unknown license where he keeps all credit and denies all assistance contributed is partially correct. Scientists, researchers, and everyone else who wants tracking data on their contributions for whatever purposes should have it. It is motivational and when depressed provide self therapy entry point to cycle back and review accomplishments. If cannot do something big, and can not sleep, it helps to have some critical work that is fairly trivial and routine to do while blasted back in the launch seats listening to the joyful roars of our artisks on the FMs/CDs/MPs/etc. overlaying the turbulent purr of our upgraded reverse engineered F1s aimed high. Some of the researchers need the attribution data (even anonymous zeros are data, arithmetic not very good until nought was made up) for some critical ongoing research into various types of brain disorders.

----

gerv Defects breed faster than scapegoated species bugs in complex systems. New defects are introduced attempting to fix old defects in poorly structured projects. Good history lesson that is applicable. Stealing the B29 Superfortress. This plane was concurrently engineering by craftsmen and engineers and all else necessary and sufficient to produce an incredible leap in aircraft technology. They did it primarily with personal tools available in the stone age. All other means of production of tools and war materiel was saturated with keeping logistics channels to all expanding fronts saturated with the food, supplies, and tools created and sent to the men at the front lines with love from supporting free communities.

----

mirwin