All right, everyone, welcome. I'd like to introduce Roseanne Meza, who is the premier forum wine forum. So she is the hero, the heroine to all of us wine developers, because she keeps them away from us, the users away from us. While we're calling out heroes, I think it's important to celebrate Gibbs' work, our friend Bela, who

has done an enormous amount of work on Bugzilla over the last year. So I think we should thank them all for their help. So thank you, guys. And I think you have some slides. But if I recall right, it's kind of QA. Like, you're happy to be interrupted, and it's more

of a sudden it can be shaped. So Karen is going to give her moral support as well. I'm not a performer, really. But you need to speak as loud as you can, please. OK, so my title is Wine User Experience. And I want to talk about, first, a little bit who our users are. Last year, when I could generally talk about users, I

got the sense that people were interested in who our users are, what proportion uses this distro, what proportion uses this problem. And I could, because I read the form, I could, of course, give my impressions. But this is just what I remember. The memory is imperfect. So this year, I got ambitious and decided I was going to

try and take a more scientific look at it. So I actually scraped the forum for last year. And I didn't have time to tag the whole year. I just got this bright idea in early January.

But there were 816 threads created on the forum between July 1st and December 31st of last year. And I systematically left them and had them, which was things that I was interested in trying to figure out statistically, as well as anything that started to

look interesting as I was rereading that stuff. So it's kind of experimental. It's maybe not the most scientific approach, but it's my first stab at trying to quantify some information. Because, of course, on the forum, there's a great deal of information about what our users are experiencing, but it's in a very messy kind of format.

So the first thing to keep in mind, the first thing I looked at is why are they posting? And it's important as I go through the other statistics to keep in mind that this group I'm looking at are people with problems, overwhelmingly.

We don't hear from people for whom one is working perfectly. I mean, once in a while, someone, you know, once a year, someone will post on the forum, you're doing a great job, it's wonderful, we love you. But, you know, three-quarters of our posters on the forum have a specific problem they want to solve.

It's usually, most of those are how-to questions, how do I do this? Some of them are also, the next biggest group of questions are does this act work in line before I buy it?

There's a small group of random other reasons for posting. Often suggestions, mine should do this. Which, being users, admittedly often the suggestions are simply naive.

Why don't we raise money to pay developers to do this? Which, I'm sure the developers will love, but, of course, users don't have a clue how expensive that is. So, you know, we'll give you 50 bucks to write this patch.

They're well-meaning. I also looked at the operating system they're using and now there's 98. We don't require people to identify that, but because we now have specific Linux and Mac sub-forums,

even if they don't tell us what they're using, we know by where they posted. So, of our forum users, again three-quarters, are on Linux. Mac users are about 12 and a half percent unknown and we had two lonely FreeBSD users.

And that's about typical, you know. We get a couple FreeBSD users a year. I will say, I believe the Mac users proportionally are underrepresented, and the reason is most Mac users are in fact using third-party apps

to run line, and that's not supported on our forum, and in fact we have a sticky at the top of the forum thing. We don't support these things and it's telling them, don't post it. So, I suspect there are probably more Mac users out there, certainly, than proportionally, but they're not going to come to our forum for help.

I also looked at other people who used Linux, to the extent that, again, they identified it. Many didn't, but proportionally, Ubuntu and derivatives, other than Linux,

Mint are the biggest group. I simply counted Linux Mint separately, because they're big enough to be counted separately. They're our second biggest group. Followed by Debian, and then that little wedge of other, and a breakdown of how it worked out.

The other other is their distros, but they were fewer than 10 each, 10 posts, so I just lumped them together. So this kind of, obviously, Ubuntu dominates here. Now, keep in mind, this is a group we're talking about, a group that has problems,

as opposed to a group that is representative of all our users. So one can speculate, you know, why Ubuntu users seem to have more problems. I think one of the factors is that Ubuntu is marketed to newbies. They have a higher proportion of newbies in general,

and the other groups that have fewer people, these tend to be more experienced Linux users, or they're able to solve their own problems. So even if they have problems, they're not necessarily coming to us for help. Whereas Ubuntu users, what we see on the forum,

you know, or I think last year I said, our typical user is just finished installing Ubuntu and now wants to play World of Warcraft. And they're not even quite sure how to use their package manager. So I think that's a big reason why we see so many Ubuntu users.

And again, I don't think they're necessarily that dominant in terms of all users. It's just that they're that dominant in terms of who we're hearing from who has problems. I also took a look at what version of Wine they're using, and now not everybody identifies it.

Actually, only about 54% actually identifies the version of Wine. And in the group, you know, starting at the top, 1.7, which came out in August, 1.6 came out in July. Previous development released 1.5. Previous stable released 1.4.

And pre-1.4, ten people, I lumped them all together. There are always random people who are using ancient versions of Wine. The general reasons for that are either they're on a very old distro and there are literally no new packages for it, or they have an app that needs an old version of Wine.

Often they have an old patch and you've never made it into Wine. Their app depends on it, so they literally have to use this ancient version of Wine to run this machine. Now, looking at this, it looks like, kind of like,

the current development release is about equal in usage to the current stable release, within a 50-50. That's misleading. We'll see on the next chart. But keep in mind that the time period I looked at includes the two weeks when 1.6 first came out,

and it was literally the newest release. So people who normally use the development branch and update every two weeks were, of course, using 1.6 at that point. And so that's artificially caught. Now, having read the form, I knew there was a particular problem

with the 1.6 branch. And the next chart shows usage by month, and I specifically did this. 1.5 is at the bottom, and that goes down. That blue line, 1.6, usage was at its high point when it was released,

which is not surprising because, again, as I said, people who normally use the development branch were also using that. So that initial drop is expected when 1.7 comes out because that group jumped to this. What's unexpected is the nose dive 1.6 takes

between August and September, and by the end of the year, it's actually below usage of the previous stable release. And this is something for those of us who do use your support, not just on the forum, but also in Mozilla

in terms of triaging those. It's been driving us crazy because... Maybe because in Ubuntu it's still 1.4 by default? Yes. That's what I was getting to. That is exactly what happened. Ubuntu shipped 13.10 with 1.4.1.

We're talking about, of course, newbies. We don't necessarily know there even is something other than what their DSTOR's repository has, so they installed 13.10, the newest version of Wine. They run into a problem. Hopefully they come on the forum

more equipped to deal with these kind of newbie problems, but unfortunately, a lot of them have, in fact, been filing goals for 1.4.1. They've been told to retest. They find it's fixed, of course. It was fixed a long time ago. And, you know, then they go through having to upgrade.

So that's been a problem for the past few months, literally. In terms of... It shows how dependent users, particularly inexperienced ones, are on their packagers

and what their DSTOR packages are. Now, in this case, it's not the user's fault. They don't know any better. This is their package manager, told them they had the newest version. And to be fair, whenever someone goes out to a forum for a bunch of reasons like that, what they're told to do is apt-get install this.

So when you're gonna go get Wine, apt-get install Wine, and then you have Wine. And that's what they're told to do. So is this... Scott didn't update his package fast enough? I mean, what's the issue here? I mean, it can't be with 13.10.

That's all dope, right? It wouldn't be... How about 2018? I think it was too late to change the package. They have a decision which package they use for the release, and thus import small bug fixes in the way, and change the package to a newer version

is not allowed in the short time before release. And after the release, you have to take a big way to get a package update in the same release. I mean, yeah. 1.6 came out in July.

I don't know which time it is. I know OpenSUSE managed to ship in another version. Maybe for example when... I don't know, but for example when Scott has holiday in this summertime, for example just in this time, when he comes back, if maybe the deadline is over,

I don't know. Yeah, I don't know the reasons. I just know it's causing us problems. And this is abnormal to have the stable release drop that much. Now, the development branch is as expected going up.

Part of the reason it's going up is the other big thing that happened last year is the December Steam update basically broke all versions of Wine prior to that. It was fixed in the development branch within one day.

You guys are superheroes sometimes. Seriously. I mean, you can't ask for anything better than that. But of course I spent a lot of time on the forum repeatedly telling people the update to 1.7.8.

It was updated in the development branch right away. That wasn't that important to the stable branch until like 1.6.2 which just came out not too long ago. So, again, that's also taking from people who perhaps may have preferred to stay with the stable branch if they use 1.6. But, of course, needing to play their games

takes precedence over everything. So, we have a sharper object. One question. What distributions do you use like the stable branch except you don't have to be able to target it? Because I know Fedora is not Fedora. So, you don't have to upgrade.

They take whatever it needs. The decision to have this two-branch system was made before I ever became involved in Vine. And I know there are differing opinions. As someone who does user support, I'm endlessly telling people to upgrade

to the latest development release. I mean, there's a certain kind of a grace period after the new stable branch comes out I'll give, you know, for maybe a month or so, I'll save them a great release to the latest stable branch.

I start to see that there are bugs even in the latest stable branch that have been fixed in the power branch. So, I say, at that point, I start telling people automatically to try the latest development. It's a problem helping users.

Those of us who help users, we're experienced users. We're using the development branch. As it goes further in time, what was my6 was like. That was, you know... But time-based.

Well, the thing is, you don't know how many users are happy in using the stable release. Yeah, we don't. Oh, yeah, that's true. This is the special program. Yeah. So... Yeah, I said that... We don't, we don't. Though I think we can effectively say that with Steam,

a whole lot of Steam users were very unhappy, at least until it was backported, but we don't know. Now that it's been backported to the stable branch, they may be perfectly happy. Now, people have a misconception about the stable branches. I said this last year. To users, the word stable means it doesn't crash. And, of course, that's not true.

What you mean is not true? In general, people find the stable branch crashes more than the development branch. In particular, they're using 1.4.1. And the reason for that,

the reason I'm particularly frustrated that 1.7 was foisted on a bunch, or 1.4 wasn't foisted on a bunch of users is that the VC, WwiseVC run in 1.4.1 was not yet ready, complete enough to run multiple apps.

That was fixed by about 1.5.9. So, we're still, you know, seeing in these 1.4, people are seeing crashes in unimplemented functions that were implemented 18 months ago. And so, you know, my end, that's what has me frustrated

with trying to help people, because it was a needless problem. You know, if they'd been given 1.6, they wouldn't be seeing these crashes. So, yes. Maybe stable is the wrong word. I mean, like, slow. Stable.

Actually, if your application works, I mean, don't change WwiseVC. Stable is what you're saying. You know, for those of us, again, who? Six months or a year ago, this is a duplicate. So, it's creating unnecessary work

for the non-developer volunteers, like me. We shall end the release. Future fix, please. Okay, the next thing I looked at is third-party apps. It was a controversial thing.

Many of our users, this is basically people who mentioned having used a third-party app prior to, you know, posting. WineTricks, biggest usage. Not surprisingly, because it's the only one that's kind of semi-supported on our forum. I said it's controversial because, you know,

officially we only support plain wine. You're only supposed to foul bugs. And even on the forum, you're only supposed to be using plain wine. We accept WineTricks simply because those of us who do the help mostly use it occasionally ourselves. And, you know, speaking for myself,

some of the questions about WineTricks are in fact problems with WineTricks, not problems with wine. I'll answer it if I know the answer off the top of my head, otherwise it's generally recorded to the guys at winetricks.org. The second most common one uses Play on Linux. Again, controversial,

and people are told try plain wine. And a smattering of others, WineBodeler, Wineskin, and obviously ClamMac are actually all Mac wrappers. And this is definitely, as I said,

under-representative in terms of people who are actually out there using these wrappers because specifically we have a sticky at the top of the forum telling them that WineBodeler and Wineskin are not supported here. So we're, you know, just not in.

And Q4Wine is the newer one. And we are hearing about Type 1. We're occasionally getting people asking for our help and, you know, I refer them to your, and I've looked, by the way, that your support looks very good to me. So, you know.

And in fact, I've recommended Type 1 to some of our users to say, well, I can't get some of it to work in wine after I'm in it. I say, I think the best bet is Type 1, so go talk to them. So, but yeah, the, you know, the third-party app is a controversial one

because for those of us who do support, people come in having totally messed up their wine prefix by installing a bunch of native DMLs and making other changes, and in the case of Q1Wine, it's possibly using a patched version of wine that's not supported, and we're the bad guys who have to deal with it.

So no, you can't do this. We won't talk to you unless you use Q1Wine. Okay, problems building wine. I looked at specific kinds of problems in Q1Wine, and I went to who has problems building wine. Not surprisingly, Debbie is at the top

of people who have problems building wine. Most of our users are using packages, but, you know, there are people who, for various reasons, try to build it. Usually, the main reasons for wanting to build wine instead of using a destroy package

is that the destroy packages are out of date or there even aren't any. Sometimes it is because they want to use a patched version of wine. Sometimes it's actually because they want to run a regression test. So reasons for Debian having such problems

are multi-arch, of course, and the difficulty of getting 32-bit dependencies, but there's another reason of that that our instructions for building wine on Debian on our wiki predate the move to multi-arch. So they're totally useless for current Debian.

Useful for people using really old versions of Debian. We have seriously had people pleading with me for help, and I don't use Debian. I'm not qualified to give them advice.

So if anybody out here there uses Debian and knows how to build wine on Debian, if you could take the time to update our wiki, your fellow Debian users would be very grateful, and I would be very grateful to you as well, because then I would have some accurate up-to-date information

to point our users to. Why do you oppose that that problem with multi-arch is more common on Debian than on Ubuntu, which also uses multi-arch? Ubuntu doesn't build packages, it doesn't build packages. They don't, but we also have up-

Somebody did pull in, I think it was actually Dan Cagle, posted up-to-date instructions for building wine on Ubuntu. And it literally comes down to, people have said they have searched the entire web and couldn't find up-to-date instructions for building Debian. Now I actually found a blog

that looked like it knew what it was talking about, and I literally have been referring users to this blog entry. Nobody said it didn't work. Of course, the other problem is people don't always give me feedback one way or the other. But at this point, I'm pointing people to an external blog

that seems to know what it's talking about, and I hope it does. But I don't like doing that. You know, really, ideally, these kind of instructions should be on our website. Copy and paste it from the other website. If somebody could verify, somebody knowledgeable about building on Debian,

it would actually verify to me that this actually is the accurate way to do it. Well, did the users come back to you? They didn't. I mean, that's part of the problem. The problem is, I don't know. You know, the problem with dealing with users is the disappearing user. So, you know, you give them a suggestion and never hear from them again, and maybe that's because it worked and they're happy,

and maybe it's because they gave up, and maybe it's because they found a different solution elsewhere, or maybe they died. I don't know.

Sent us, and I was actually, myself, surprised, I'm thinking in my memory as being that big a thing, but they actually have a similar problem in getting up-to-date information

as well as packages to satisfy dependencies. Yeah, the other problem is that Alexander loves to break that. It's on your phone.

Obviously, if you can't even build, install Wine, then, you know, you can't even get to further problems.

Yes, we have people who don't know, and what two users are at the top, and Linux Mint also uses the same packages. So, it's overwhelmingly, in that group,

people having problems installing packages. Part of it is user inexperience, but it's not entirely their fault. The problems were clustered in September and December. In September, as I recall, there actually was a broken bunch of package up there briefly

that simply wouldn't be installed. And so, yeah, they came under. In December, the problem turned out to be our instructions on our website for adding the PPA.

We have this nice little page that looks like, you know, completely idiot-proof. We have nice pictures, and it's starting to warn you, copy and paste this line. Now, how could anybody screw that up? But we did, because there was an extra space in the HTML,

and because of that extra space, if they literally followed that instruction, it would not work. Now, I feel bad because we had a string of confused newbies coming out of the forum insisting they followed the instructions to the letter,

and they don't work, and I'm thinking, well, you did something wrong. I don't know what it is. I don't use Ubuntu. I don't know what package manager will report it because the passage container, and kind of brushing them off until someone, thankfully, finally figured out and filed a bug and didn't get it fixed.

Bad for these poor users. I didn't perhaps treat them as well, but this was our fault. Oh, we, I haven't, actually, someone did have a problem. I mean, we always had, we,

again, because a big part of this is user inexperience, we're always going to get some people who just, when you don't know how to use the package. We on the forum, I just, I refer them to the distro because package managers are so different from distro to distro.

I can help them with OpenSUSE. That's what I use. But I don't have a clue how Ubuntu's or anybody else's works. So we generally refer them to their distro forum, and we actually, the guidelines for our forum are that knowledge, basic knowledge of how to use

your operating system is assumed, that you're experienced. The reality is that description fits the people answering the questions on the forum. It does not generally fit the people asking the questions. You know, there's a balance we have to strike

because we are not a general how to use Linux forum and we could easily become logging because of the nature of our user base because they are people who are just a switch. Windows are very inexperienced and you know what I mean. So at some point we have to draw a line and say, no, I'm not teaching you how to use your package manager.

But this was definitely our fault. Seems like Ubuntu could sanitize the user. Yeah. I don't know if having a space at the beginning should show off the mysterious error that you can't figure out.

Okay, so I also tried to tag threads for problems running online. Granted, problems are all over the place. But the key word that came up most often was crash. Possibly because something that's serious is more likely to get people actually seeking help.

Graphics was second. Running an installer that failed was third. And the one that kind of surprised me that it was that high was fonts. And then yeah, I just put up stuff that had at least ten, you know, input device includes lumped them all together,

keyboard, mouse, tablet, then mono.net, sound, networking, and performance. And this was actually things that I tagged as problems, not questions. The one, in most cases, the numbers are the same. They're basically all problems.

Performance is the one area that actually had almost as many questions as problems. And how did I make the distinction? Well, in performance, performance is so bad you can't play this game, as opposed to it's perfectly playable, but I want to

every last frame per second, I can get. And so we have definitely a group of hardcore gamers who, what, every last frame per second, as opposed to this represents the people who say, you know, this is so bad, it's unplayable. So that's kind of a, you know, general range

of the kinds of problems users are recording. My experience is that the distinction between this is unplayable and I want the best performance I can get, this kind of nuance. It is. I have to think... When I was tagging, I basically accepted

how the user perceived it, because this is what I'm looking at. It's user perceptions. If they say it's a problem, then it's a problem. I had this crossover user who played Skyrim at seven frames per second and was perfectly happy. Then there are those guys who played Counter-Strike at 100 frames per second

and said, it's terribly slow, I'm on 300. Yeah, and that's how they said that I'm, from my point of view, looking at, you know, how happy are our users, how are they coping. I take their word that this is okay, or this is not okay.

What was the problem? Oh! Sometimes it looks good. I have a lot of people sometimes who have an application that's bad and then stole some points and then... It looks either they're not rendering properly

or in some cases not showing up at all. They're getting a little... A missed point, basically. Application forces are on, then if it's not there, it's not falling back. So you have to have a proper point to solve. And line teams does the job. Get the points and it works. In some cases, actually, font problems

turned out to be actually language variable problems. People are literally, you know, I'm trying to run. The Japanese fonts are showing up. If you try to run a Japanese program, but your system is set to English, it just doesn't work. You have to make sure that the locale of the machine matches the locale of the program.

And you can start, you know, aligning with the correct language variable. Now in some cases, people have done that already and the fonts still aren't showing up. And that's an actual bug. But that, starting with the language variable is one thing that's actually not documented on our site. We have actually periodically get questions about it,

but it's not actually in the user guide or the FAQ. So, that was my statistics. I'll talk a little bit about user support, or as I put it, dealing with people who don't follow directions.

And that's an oversimplification, of course, because I'm a user myself. To the extent that I can help people is because I read the directions and I follow directions. But we have a lot of information on our site. And it's clear that people aren't reading it.

In many cases, because a lot of what I do is in fact simpler for people. The answer to your question is here in the FAQ. Now, my background, you know, I'm not a technical person, my background is as a teacher.

And to treat my users kind of like I treat students. Which means, yeah, I do expect them to do their homework. I expect them to be willing to learn. If they're not, that's their choice, but then it's, you know, have a nice day.

But I also know as a teacher that dealing with a student, I can't just say read the textbook. That's all you need to do. And I also know that if a lot of students are making the same mistake, they're just not getting it. As a teacher, I have to take a look

at what I'm telling them. Because clearly I'm not communicating effectively. So, in talking about, you know, people not following directions and reading stuff, I wanted to take a look at why aren't they? And are there things that we could be doing better

to make it easier for them? The example of, you know, that problem with a bunch of page is a clear example where it was our fault when they were trying and it wasn't working. Now, it's obviously not that we don't have enough information.

We have a wiki with 848 pages. We have a Zillow, which as of yesterday was up to 35,485 total bug reports. 7,700 still open. But in terms of looking for troubleshooting,

you often want to read the closed bug reports as well. Information might be there. It might be something, one of the problems is people filing bugs for things that were already fixed because they're using that old version to get bugs. In AppDB where we keep user reports

on performance in various apps has over 12,000 issues. And the forum has 16,782 threats. So, it's not lack of information. Why aren't they reading all the 65,000 pages?

Just there, just go read it. The sheer volume of it, divided actually into four distinct areas, the wiki, Mozilla, AppDB, and forum,

which are essentially separate entities. Maybe all YH2.org, but they each have a separate login. They have a separate search. And so the first thing a person coming into the website has to figure out is,

which one am I going to search? You know, should I be looking in the wiki, Mozilla? Now if they come to the forum, and I'll keep pitching the forum, they get my help, and I'm pretty familiar with the website. I mean, I sometimes think my main role is a cross between a traffic cop and a reference librarian.

So I just say, you don't care when you go over there. And, you know, this is the information you need. As familiar as I am with the website, there are times when I can't find things I know are there, because I've seen them before. So don't underestimate the difficulty faced by users on our website.

Now let's say they decided to search more than one. They will sometimes find multiple pages on the same thing that don't agree with each other.

So I was putting together this presentation, and this kind of surprised me. We actually have four different sets of instructions on how to file a bug. They don't say the same thing. In some cases they directly contradict each other.

And so what a user is going to do if they're coming in to file a bug and they, you know, never file a bug before, they're not a technical person. It's in part going to depend on which set of instructions they happen to read. For one, there's a very real danger

they're just going to discount all of them and do what they think best. Or they're going to pick and choose pieces. I mean, they're going to help as best they can. But this is why I think in part, and I wanted to focus in part on bugs

because users, obviously inexperienced users file them. It causes problems because they file bug reports that no one could possibly even attempt to fix because it doesn't have the information needed to even think about it. Or it's a duplicate, invalid, they're using an old version of Wine,

they didn't read the instructions, or, you know, which set, or they read the wrong set of instructions. Not, like, this is a, sort of a job that you can recruit people as volunteers to work on, right? It doesn't require skilled Wine.

Like, fixing this could be done by, there are many people in the world who could fix this, right? Where Wine hacking is harder. Have we just not attracted those volunteers for doing something wrong? Is it, I mean, is it just... Well, we asked the person if we did a lot of migrating stuff to the wiki

and cleaned up the wiki, but it's a lot worse. Did we not buy them enough beer? I mean, what... You need to invite them. Okay, this one is the wiki one, and that's probably the best one and the most up-to-date.

And in terms of users actually filing bugs, that's the user guide. This is the one above, it's on the Wine HQ, the main page, so if users were going to Bugzilla, that's what they would see. Now, that's a lot shorter than this,

and I think part of the issue is people are not actually reading this. I think people with triage bugs who would like them to read this are not, and that's actually one of the things I wanted to address is why I think they're not. So what I want to do...

So here is the next thing I see that says,

before you report a bug, please make sure you've completed the following steps. So this looks like the instructions. So let's pretend I'm a new user. What's in front of me tries to follow the instructions, but I'm not experienced.

Something crashed, and I got this nice pop-up saying, you know, a bug. Gave me a nice little window to capture that trace. And I wanted to walk through these steps from the point of view of someone who's never filed a bug before.

So the first step, create a log-in account. Well, that's easy. I can do that. Create log-ins on the website. So I go ahead and do it. It's fine. Step two, use the available bug list. It says, this list shows the submitted bugs that have not been assigned to anyone yet.

If you want to work on a bug, this is the place to start looking. So I, you know, I just installed Ubuntu ten minutes ago. A bug list.

It's limited to 500.

Well, if I wanted to see all 7,700. But let's not. That takes a while. Maybe. Is this even in there? As a user, what that step teaches

is that some of these instructions are not necessary or relevant to filing bugs. And I'm going to remember that because I'm an intelligent person who learns. So we've gone through that. Now, step three.

Here you are using the latest stable version or a build from Git, comma, if similar bugs have recently been fixed. Now, okay, so I'm an English teacher, so I'll tell you. I'm getting really short on your warning.

I don't want to stop you because what I want you to do is get this fixed. But we are getting a little out of time, so I kind of want to see if we can accelerate this. Okay. All right. We don't have to be rigid on our schedule, but I do need to...

All right. So just looking at the grammar side, it's an atrocious sentence. If similar bugs have been fixed and committed, how on earth am I supposed to know that? If I click on Git, it leads me to another page that tells me how to maintain my patches using Git.

So I know that doesn't apply. So that leaves me with the latest stable version, which that I can understand as a user. And I'll go, and my package manager will tell me that 1.4.1 isn't even the latest stable version. And so I'll go on to read our tips on bug hunting and support.

Now, and I've already gone through a couple things that I know aren't related to reporting bugs, so I say, well, this has nothing to do with me. I'll just skip that, because I'm getting tired and I'm in a hurry. I don't want to file this bug. This link is what leads to that page that has the actual accurate information

that people should be following. They're going to skip it, because it doesn't look like it has anything to do with recording a bug, and you've already trained them, and some of this stuff doesn't. Then read the FAQ. You might do that. Submit only unknown bugs.

You actually have two conflicting links that lead to different places. This one will actually lead you to finally submitting the bug. So we had a series of instructions, half of which have nothing to do with actually recording a bug. We ended up in a way to train people to,

in fact, ignore part of our instructions. And that's why they're doing it. So it's easy, you know, to say, well, users are, you know, inexperienced, they're stupid, they're not following directions, but in fact, we're training them. They are, in fact, intelligent people who are doing what we're teaching them to do.

That's my point, so... So who is going to fix this page, right? Do we have any of the Bugzilla elements doing it? You're going to fix it? All right. Anything else you wanted to get to?

No, that's it.