Right now we're going around giving feedback -
what was the highlight of the week so far, what was the most
frustrating part, what we need to change.(mchua,
13:12:50)
Everything at the top of that bug is metadata
that lets us find and work with it more easily, and manage it -
status, aliases, product, component, etc.(mchua,
13:35:34)
The bug itself is described in the description,
of course.(mchua,
13:36:03)
The definition of a good bug report is
"something that gets the bug closed." So you have to be (1) precise
and (2) persuasive - bug advocacy (persuading folks that this bug is
worth the effort it will take to fix) is crucial.(mchua,
13:36:39)
You can do this by proving to them it is
important to fix, by showing them how it is easy to fix (the more
work you can do so that developers don't have to pick it up, and the
more resources you can set up for the eventual bug-fixer, the
better), or hopefully, both.(mchua,
13:37:20)
Tickets are individual tasks, so "take a
ticket!" is often a good student project. How do you find things
that are good student projects?(mchua,
13:40:21)
One way to do that is to look for keywords -
sometimes projects have a keyword that they use to tag bugs that are
new developers to fix.(mchua,
13:40:55)
These keywords aren't always accurate nor
up-to-date... if you don't find useful things in there, ask around
in the community to help you/your students scope out good
projects.(mchua,
13:43:14)
Chris is walking through the different bugzilla
fields right now - most of them are in the links I have put in
above.(mchua,
13:43:29)
Here's a general "fields in bugzilla"
reference, too.(mchua,
13:43:48)
Bugs usually go back and forth ("I think this
is a bug," "Yes, it's a bug," "I need more information about the
problem," "I think I have a solution," "Nope, doesn't work yet, this
happens..." "Oh, try this patch instead", "Yeah, that works!" "Bug
is fixed!") until either they're fixed or someone decides the bug
won't be fixed.(mchua,
13:49:14)
And in the end, it may be decided that a bug
will *not* be fixed - for instance, this bug is likely not going to
be fixed because the version it refers to is now out-of-date.(mchua,
13:50:12)
Bugs may also be closed because they're
duplicates of a bug that has already been reported (Closed:
duplicate) - in which case they're just pointed to refer to that
other bug.(mchua,
13:55:07)
Bugs may also be closed because nobody can
reproduce it, so there's no indication that there is a bug.(mchua,
13:55:20)
Bugs can also be closed as WONTFIX - that is,
"you are describing something that the software does in fact do, but
we do not think that what you are describing is a bug that we need
to (or can) fix, so we won't work on it."(mchua,
13:56:13)
These things are subject to debate, for the
record. ;) Just because someone says something does not mean you
have to agree.(mchua,
13:56:32)
When looking at the conversations in bug
comments, looking at the dates and names to see how old the convo is
and who's in it is a good idea.(mchua,
13:59:24)
One of the analogies that came up in POSSE
Worcester was that it's like reading research - after a while, you
know who writes about what, you recognize the names in the
conversations, you have a sense for what topics of discussion are
hot and which ones have cooled down for a bit. You get the same
sense for projects in FOSS.(mchua,
14:00:05)
You can get bugmail - you can add bugs to
something called a "watchlist," and automatically get email updates
when that bug gets updated.(mchua,
14:03:43)
Some projects use Trac, some projects use
Bugzilla, some projects use another tracker... use whatever system
the project you're working with uses, and pick your favorite if
you're starting your own.(mchua,
14:10:13)
there's also some nifty plugins that can be
used for Trac: http://trac.edgewall.org/wiki/PluginList(ganderson,
14:14:39)
Bugzilla tends to have more features useful to
large FOSS projects (dependency tracking between bugs, etc) than
Trac.(mchua,
14:15:03)
Back briefly to bugmail - here's a good
explanatory link for that:(mchua,
14:15:48)
Chris is now talking about review flags, using
Fedora's bugzilla as an example. These are ways of "tagging" a bug
so that a certain team puts it into their to-do queue.(mchua,
14:16:27)
If you're starting your own FOSS project, there
are places that will set up and host infrastructure for you.(mchua,
14:18:07)
This is for any FOSS project, and will
automatically give you a bug tracker (Trac), version control and
code hosting (git, cvs, svn, etc), and more for your
projects.(mchua,
14:18:47)
Other alternatives are services such as
sourceforge, etc.(mchua,
14:19:13)
One danger is that student projects that start
up in sourceforge, etc. wither and die because of lack of connection
to a bigger community - so encourage your students to release early
and releaes often, and reach out about their code to others.(mchua,
14:20:33)
In other words, get your code to a minimally
usable state as fast as possible - even within a week - and go out,
get others to use it, asap.(mchua,
14:20:55)
Steve's talking about the FOSS@RIT project
right now; ask him for more detail if you're reading these
logs.(mchua,
14:22:30)
We just decided that there are two topics we
should cover tomorrow(mchua,
14:26:41)
What a student project looks like to the FOSS
community - picking a project from inside RIT and having ctyler and
mchua look at it and give their impressions on how that project's
doing at engaging folks from outside RIT to help(mchua,
14:27:20)
How to gauge the activity of an unfamiliar
project and dive in - pick a project someone here is interested in
but hasn't started with yet, and have ctyler and mchua go through a
10-minute demo of how they'd start.(mchua,
14:27:54)
Intro to projects for the rest of the week(mchua, 14:29:38)
Vocabulary: i18n == "internationali(z/s)ation"
(saves typing *and* arguments over American vs British
English!)(mchua,
14:35:08)
Mel's saying that she would probably join the
mailing list for a project right at the start (before posting,
herself), just to see what kind of posts are going through(ganderson,
14:49:49)
Friday 30m talk from Steve on FOSS@RIT(mchua,
18:53:37)
RIT Spin group is (except for Mel) updating
http://teachingopensource.org/index.php/RIT_Remix_Project with
specs/packagelist/bookmark links(mchua,
19:01:45)
Mel is (for the RIT spin group) continuing
documentation revision work in
https://fedoraproject.org/wiki/Talk:How_to_create_and_use_a_Live_CD#Build_the_image
(to be merged with main page soon)(mchua,
19:02:09)