teachingopensource
MINUTES

#teachingopensource Meeting

Meeting started by mchua at 19:15:41 UTC (full logs).

Meeting summary

  1. Wednesday morning start (mchua, 12:32:59)
    1. http://teachingopensource.org/index.php/POSSE_RIT#Wednesday (mchua, 12:33:10)
    2. We're taking a look at TOS Planet right now. (mchua, 12:43:50)
    3. http://teachingopensource.org/index.php/Planet (mchua, 12:43:53)
    4. Mel points out that the most recent post's first paragraph *exactly* sums up what we're trying to accomplish this week. (mchua, 12:44:13)
    5. http://independentimageworks.blogspot.com/2010/06/posse-day-2.html (mchua, 12:44:16)
    6. IDEA: Sugar Labs uses openid, next time have everyone just make one instead of signing up for lots of accounts. (mchua, 12:50:23)
    7. IDEA: Keep everyone in just one community for the first day, instead of two. (mchua, 12:50:44)
    8. If you want to have persistent IRC connections (recommended), check out an irssi + screen setup. (mchua, 13:03:30)
    9. http://www.irssi.org/documentation (mchua, 13:03:33)
    10. http://quadpoint.org/articles/irssi (mchua, 13:03:44)
    11. Chris, Mel, Luke, and possibly others are willing to help folks set this up for themselves in small teams later this afternoon. (mchua, 13:04:05)
    12. X-Chat IRC client for people who like their mice :) (ganderson, 13:08:13)
    13. http://xchat.org/ (ganderson, 13:08:15)
    14. http://www.silverex.org/ (ganderson, 13:08:22)
    15. http://sourceforge.net/projects/xchataqua/ (ganderson, 13:08:27)
    16. 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)

  2. Bugtrackers! (mchua, 13:30:29)
    1. We're going to demo bugzilla and the usage of bugzilla to track an issue - and find issues. (mchua, 13:30:59)
    2. https://bugzilla.redhat.com/ (mchua, 13:31:02)
    3. http://bugzilla.redhat.com (ganderson, 13:31:02)
    4. You can build a query for the kind of bugs you're looking for. (mchua, 13:31:35)
    5. https://bugzilla.redhat.com/query.cgi (mchua, 13:31:39)
    6. We're looking at bug #499836, "keyboard does not work at the GRUB menu." (mchua, 13:34:59)
    7. https://bugzilla.redhat.com/show_bug.cgi?id=499836 (mchua, 13:35:03)
    8. 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)
    9. The bug itself is described in the description, of course. (mchua, 13:36:03)
    10. https://bugzilla.redhat.com/show_bug.cgi?id=499836#c0 (mchua, 13:36:05)
    11. 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)
    12. 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)
    13. More on bug advocacy at... (mchua, 13:37:49)
    14. http://www.kaner.com/pdfs/BugAdvocacy.pdf (mchua, 13:37:54)
    15. Some links on how to write good bug reports: (mchua, 13:38:20)
    16. http://www.softwaretestinghelp.com/how-to-write-good-bug-report/ (mchua, 13:38:23)
    17. http://www.chiark.greenend.org.uk/~sgtatham/bugs.html (mchua, 13:38:29)
    18. http://itscommonsensestupid.blogspot.com/2008/07/tips-to-write-good-bug-report.html (mchua, 13:38:37)
    19. Individual projects will sometimes have their own "how we prefer bug reports to be written" guidelines as well. (mchua, 13:38:59)
    20. http://docs.moodle.org/en/How_to_write_a_good_bug_report (mchua, 13:39:03)
    21. http://wiki.songbirdnest.com/Developer/Articles/How_To_Write_a_Good_Bug_Report (mchua, 13:39:07)
    22. https://developer.mozilla.org/en/Bug_writing_guidelines (mchua, 13:39:10)
    23. 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)
    24. 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)
    25. In Sugar, this is sugar-love. (mchua, 13:41:35)
    26. http://bugs.sugarlabs.org/query?status=accepted&status=assigned&status=new&status=reopened&order=priority&col=id&col=summary&col=priority&col=status&col=owner&col=type&col=milestone&keywords=~sugar-love (mchua, 13:41:37)
    27. In Fedora, this is StudentProject. (mchua, 13:42:44)
    28. https://bugzilla.redhat.com/buglist.cgi?keywords=StudentProject&resolution=--- (mchua, 13:42:49)
    29. 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)
    30. 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)
    31. Here's a general "fields in bugzilla" reference, too. (mchua, 13:43:48)
    32. http://tldp.org/LDP/bugzilla/Bugzilla-Guide/how.html (mchua, 13:43:52)
    33. Filing a bug is the beginning of a conversation - you can see that conversation in the comments on a bug. (mchua, 13:47:45)
    34. For instance, this comment says "hey, I have this problem too." (mchua, 13:48:12)
    35. https://bugzilla.redhat.com/show_bug.cgi?id=499836#c2 (mchua, 13:48:15)
    36. 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)
    37. 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)
    38. https://bugzilla.redhat.com/show_bug.cgi?id=499836#c7 (mchua, 13:50:16)
    39. 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)
    40. Bugs may also be closed because nobody can reproduce it, so there's no indication that there is a bug. (mchua, 13:55:20)
    41. 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)
    42. 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)
    43. 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)
    44. 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)
    45. 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)
    46. The Sugar Labs bugtracker: (mchua, 14:06:24)
    47. http://bugs.sugarlabs.org (mchua, 14:06:30)
    48. 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)
    49. there's also some nifty plugins that can be used for Trac: http://trac.edgewall.org/wiki/PluginList (ganderson, 14:14:39)
    50. Bugzilla tends to have more features useful to large FOSS projects (dependency tracking between bugs, etc) than Trac. (mchua, 14:15:03)
    51. Back briefly to bugmail - here's a good explanatory link for that: (mchua, 14:15:48)
    52. https://wiki.mozilla.org/Education/Courseware/MozillaForProfessors#Bugzilla (mchua, 14:15:52)
    53. 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)
    54. If you're starting your own FOSS project, there are places that will set up and host infrastructure for you. (mchua, 14:18:07)
    55. One example is Fedorahosted. (mchua, 14:18:12)
    56. https://fedorahosted.org/web/about (mchua, 14:18:15)
    57. 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)
    58. Other alternatives are services such as sourceforge, etc. (mchua, 14:19:13)
    59. https://fedorahosted.org/fossrit/ (RITSteve, 14:19:17)
    60. 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)
    61. 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)
    62. 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)
    63. We just decided that there are two topics we should cover tomorrow (mchua, 14:26:41)
    64. 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)
    65. 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)

  3. Intro to projects for the rest of the week (mchua, 14:29:38)
    1. Vocabulary: i18n == "internationali(z/s)ation" (saves typing *and* arguments over American vs British English!) (mchua, 14:35:08)
    2. Vocabulary: l10n = "locali(z/s)ation" (mchua, 14:35:50)

  4. How to dive into a new project: Mel's demo (mchua, 14:40:49)
    1. Diving into Audacity (ctyler, 14:41:48)
    2. audacity.sourceforge.net (ganderson, 14:42:02)
    3. Mel's looking at information on Audacity's "Get Involved" page as a 'user' (ganderson, 14:43:49)
    4. http://audacity.sourceforge.net/community/users (RITSteve, 14:44:14)
    5. Mel's discovered a mailing list and developer list. She's looking through the lists to see how active the community is. (ganderson, 14:45:07)
    6. The web site says that the language is C++ (ctyler, 14:48:11)
    7. Mel's showing Ohloh, which allows you to find information about various projects (ganderson, 14:48:37)
    8. http://www.ohloh.net/ (ganderson, 14:48:46)
    9. http://www.ohloh.net/ (RITSteve, 14:48:46)
    10. 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)
    11. http://www.ohloh.net/p/openvideochat (RITSteve, 14:50:52)
    12. IRC channel is irc://irc.freenode.net/audacity (ctyler, 14:52:01)
    13. Good to lurk on a channel for a while to see culture and main players. (ctyler, 14:52:34)
    14. Lunch! (ctyler, 15:10:49)
    15. https://dev.laptop.org/query?status=assigned&status=new&component=measure-activity&order=priority&col=id&col=summary&col=owner&col=type&col=status&col=priority&col=milestone (lmacken, 16:55:38)
    16. http://bugs.sugarlabs.org/query?component=Measure&order=priority (lmacken, 16:55:44)
    17. The Sugar Activity folks are in #sugar, for the record. We're logging there. (mchua, 17:01:11)
    18. http://teachingopensource.org/index.php/RIT_Remix_Project (posse_projector, 17:07:54)
    19. Remix folks; I'm going to start looking for people who know things about remixes in #fedora and #fedora-devel (mchua, 17:36:31)
    20. So if you want to follow, /join #fedora and /join #fedora-devel (mchua, 17:36:42)
    21. Never mind. Just #fedora-devel. (mchua, 17:38:14)
    22. https://fedoraproject.org/wiki/Classroom/Creating_Fedora_Remix (mchua, 17:49:45)
    23. http://spins.fedoraproject.org (sdziallas, 17:58:24)
    24. http://www.cyberciti.biz/tips/fedora-core-installing-package-groups-with-yum.html (mchua, 18:15:18)
    25. Tomorrow lunch == FOSSbox (mchua, 18:53:23)
    26. Friday 30m talk from Steve on FOSS@RIT (mchua, 18:53:37)
    27. 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)
    28. 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)


Meeting ended at 02:47:24 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. mchua (257)
  2. sdziallas (68)
  3. ganderson (64)
  4. RITSteve (35)
  5. ctyler (26)
  6. gary_at_RIT (23)
  7. pfroehlich (17)
  8. quaid (15)
  9. DaveS_ (15)
  10. JonathanD (11)
  11. Andrea_H (11)
  12. Jeff_S (7)
  13. zodbot (5)
  14. posse_projector (5)
  15. skuhaneck (5)
  16. ianweller (4)
  17. Dave_S (4)
  18. cras (2)
  19. gregdek (2)
  20. lmacken (2)
  21. mlutz (1)
  22. mihaela (1)
  23. mchua_afk (1)
  24. KarlieRobinson (1)
  25. paulproteus (1)
  26. RITSteve_tries_c (1)


Generated by MeetBot 0.1.4.