hpr-knowledge-base/hpr_transcripts/hpr0092.txt

Episode: 92
Title: HPR0092: bugs
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0092/hpr0092.mp3
Transcribed: 2025-10-07 11:23:48

---

And
This is class two for Hecker Public Radio.
Bug reporting and bug triaging.
These are great ways to get involved with an open source project that you use, that you
want to contribute to, without really knowing anything about, for instance, programming
or project management or anything like that.
Now when you buy a commercial piece of software, the perception is that you are buying a certain
amount of security, that the company has paid people to do bug testing and things like
that, so that when you run the software, it runs really, really well and does not fail.
Now of course, there's not any software package out there without a bug in it, of course,
so the effectiveness of this model is highly questionable.
Now the alternative obviously is open source software, and for that to really work, I think
one of the requirements or one of the ideas is that a lot of the users are going to also
be quality assurance people, they're going to be bug reporters, so that when the program
does fail, you are able to send a report to the programmer, to the development team, telling
them how it failed, when it failed, and possibly why it might have failed, so that they can
take that and improve on it, and so that they'll have a better program and everyone using
it, including yourself, will have a better user experience.
So if you're using a software a lot and you're enjoying it and you like it and you're into
that application, one of the great things that you can do for it is other than donating
money so that the development can continue, is to submit bugs, so that if it does crash
or if there's something that needs improvement or something happens that is not expected,
filing a bug will help the programmer or programmers know where the problem is or what needs
improvement.
Now if you've never filed a bug before, you might be a little bit unclear as to how
that whole process works, so I'm going to go through that briefly and then I'm going
to talk about what happens on the other end as well.
To file a bug, you're going to typically get two choices.
One is going to be if the program crashes, a lot of times the programmer will just include
a little dialogue box, notifying you that the program has crashed and that you should
send a bug report to them and sometimes there will be a little button right there that
says send the bug report or there will be instructions on where to send the bug report.
So if it's that, if it's that casual, then basically all you're going to do is either
click the button or just open up an email and email the address that they're giving you
telling them that yes, the program quit and this is why it quit, this is how it quit, this
is when it quit.
The idea there is to give them basically a step-by-step instruction on how to replicate or recreate
that bug so that they can sit down in front of their system and do exactly what you did
leading up to that bug or leading up to that crash or whatever.
Try to give it to them just like a recipe basically so that they can just sit down, read
your instructions, do it and bang, see the same bug that you saw.
That's the ideal.
If you can't do that, then just give them as much information as possible, you know,
leading up to what was going on before this bug occurrence happened.
The other way is a slightly more formal way, I think probably a little bit more typical
through some kind of bug tracking system.
Usually this is just a web-based database.
Bugzilla is one of the big ones that you'll hear about but there are others and this is
usually found either again as some kind of pop-up window after your application goes down
or it's on the web, the project's website or something like that and you can find their
bugzilla or whatever.
You go to the site, usually you'll have to create an account there.
You'll give a username, probably maybe a password and your email.
The email is going to be very helpful because if they have questions about your bug report,
they'll be able to contact you later on to ask you more for more information, which is
actually quite good.
So you can create your user account and then you just go through some little drop-down menus
usually or maybe some selections telling them what version of the program you're running,
what platform you're running it on and again sort of a text area where you can fill in
ideally a step-by-step instruction for the programmer on how they can recreate that bug.
If you don't feel like you know what you're doing, maybe this is the first time you've
ever filed a bug in a bug tracker, just do your best.
You'll be pleasantly surprised, I think, to find how nice these people are.
They're really appreciative that you're filing a bug, you're taking time to do this.
So they're going to be very nice about it.
They don't care if you don't do it exactly as a program or would, you know.
They just want your feedback and if they need more information, they have your email
address and they will contact you.
The first time that I filed a bug with an open source project in their bug tracker, I
was really pleasantly surprised to find that they actually did email me back a couple of
times telling me different things that I could try to get around this bug and they had
me try some different things and report back to them.
So it was a lot more interactive than the previous bugs I'd filed with commercial software
packages where you just send your bug in and it kind of just disappears.
No way to track it, no way to keep track of it.
So give that a shot, it's fairly easy to do and it's very, very helpful.
They can help the programmers, it can help you, it can help everyone else using the software.
So it's a great thing to get into.
Like I say, those are usually found just on the project's website, there's usually some
kind of link to their bug tracker.
You have to understand that bug tracker served two purposes.
One is for the people filing them and the other is for the people dealing with the bugs
that have been filed.
So don't get thrown off about like different queries and things like that.
What you want to do is create a new bug.
You don't want to create a new query.
But the queries are is for the other side of the bug process and that is the people, the
bug team of that project, the people who are getting all these bug submissions and need
to sort through them and kind of categorize them and classify them and prioritize them
and things like that.
And this is another great way to get involved with a project that maybe you use on an everyday
basis and love and want to get involved with.
You can get involved with your bug team because the bug processing doesn't actually require
a whole bunch of programming knowledge or development knowledge.
You can do this as just an everyday user.
One of the most important things about doing this bug processing is just being familiar
with the project, being familiar with the program enough so that you can look at the bug
reports, kind of make sense of them and maybe even recreate them and then process them.
You use the way to get involved with a project.
This is simply, again, go to their website, look at their bug process, find out if there
is a bug team that is actively recruiting and email them or jump on IRC if they have an
IRC channel and tell them that you're interested in helping out.
Getting started in this is a little bit intimidating possibly.
If you've never done anything like it, it can be a little bit confusing but it's really
a lot easier than you realize.
Essentially, they've got a big database of all these different reports of different
kinds of bugs.
When you first join up on a bug team, they will typically assign a number of bugs to you,
maybe on a certain topic or during a certain time period.
You can take those bugs and you sort through them one by one and they will help you for
the first couple of bugs as much help as you need typically.
These people are very happy to have your help and it's part of their job as the bug team
leaders to help you become familiar with the process and to get comfortable with processing
these bugs.
You can take a bug, you'll look through it, you'll read it, usually you try to recreate
it.
You just set that bug on one side of your screen, open up the application on the other
and step through the things that the bug reporter has relayed as an issue and see if you
can get it to do the same thing.
If you do, you can usually file it typically one way and the bug team leader will tell
you they're preferred methods and if you can't recreate it, you'll file it a different
way or if you just are totally confused, you can get help from the bug team leader, things
like that.
It's a very interactive process.
It's not like you have to just sign up and then you're just kind of on your own and
you have to figure it out.
They're very helpful.
They're ready to help and you catch on really, really quickly.
Like I say, the most important thing is you're just to be familiar with the application.
So this is something that you probably want to be fairly, you just want to make sure
that you know the application well enough so that you can attempt to create the bugs.
You don't have to know everything and in fact that is actually a benefit of doing bug
triaging is that you learn a lot about the application.
You're going to be doing things sometimes that are very obscure that maybe you never
even realize that the program could do and here you are stepping through these issues
to see if you can recreate a bug and kind of learning that, oh wow, this application
does that and it does this.
That's great.
I never knew that.
It's a very neat way to learn.
A lot of times you'll learn just the most obscure things and you start to really build
up your knowledge about that application and if it's a very broad application like a
desktop environment, you might be learning a lot about Linux, like hardcore Linux stuff
that you know maybe you read about or maybe you heard about in class but kind of went
over your head at the time or you kind of forgot about or you weren't clear on.
After you try to recreate the bug like three times, you're going to be really clear on
that aspect.
So you're learning a lot.
So it's very beneficial for yourself, it's beneficial for the project and what benefits
the project, benefits the community and everyone wins.
So you can try that out and it's really cool, it's really helpful.
It's a great way to spend an evening if you don't have anything else to do, you know processing
bugs for a project that you use every day and are excited about anyway.
I mean that's a great way to help out.
So yeah, pick your project and go get involved one way or another.
Bug reporting and bug triaging, those are great ways to start out and especially bug
triaging, it's a great entry into that project.
So if you are you know learning to program or you're developing some skill and you want
to contribute to that project in some sense, you know getting your foot in the door with
just bug reporting or bug triaging rather, I mean that's kind of a cool way to get
familiar with some of the people involved in the project because you're working pretty
closely with the developers, you know, you're, you and the developers are making comments
on the same bugs.
So it's a really good way to get to know the project kind of from the inside.
Thank you for listening to Hack with OverGradio, HPR is sponsored by tarot.net so head
on over to see LRO.np for all of us here.