[02:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2010/10/15/%23ubuntu-classroom.html following the conclusion of the session.
[02:01] <nhandler> Hello everyone, and welcome to another Packaging Training Session!
[02:02] <nhandler> Today's session will most likely be relatively short, but I will be providing some tips and tricks for new developers in the Ubuntu community.
[02:02] <nhandler> These tips will be less technical in nature and more focused on processes and other common workflows/situations developers will face
[02:03] <nhandler> If you have any questions, feel free to ask at any time.
[02:03] <nhandler> Let's get started
[02:03] <nhandler> One of the most important things to remember is that Ubuntu cares a lot about the community.
[02:04] <nhandler> If you are just starting out with development, do not think that you will be working in an isolated bubble
[02:04] <nhandler> We have many development teams that group people with similar interests together so that they can collaborate and help each other
[02:06] <nhandler> For example, there is a Mozilla team that focuses on mozilla-related packages
[02:07] <nhandler> If you are unsure of which team to join, you can either try searching around yourself or ask in a channel like #ubuntu-motu. Someone will be able to point you in the right direction
[02:08] <nhandler> On a related topic, when you are starting out, I would encourage you to ask lots of questions.
[02:09] <nhandler> Development is not the easiest area to get involved with. It can be confusing at first. We all were new at some point, so don't be afraid or embarrassed to ask questions when you are unsure of something
[02:10] <nhandler> However, keep in mind, there is a difference between asking for help and asking someone to do your work for you. Developers are able to easily distinguish between the two types of requests, so please be sure to avoid the later
[02:10] <nhandler> If you are planning on eventually applying for upload rights, you will eventually need to prepare a wiki page documenting your contributions.
[02:11] <nhandler> You may find that updating a wiki page as you go will make your life easier down the road.
[02:12] <nhandler> If you decide to do this, keep track of information such as: applications you've packaged, bugs you've patched, developers you have worked with or who have sponsored your work (and what bugs/packages they reviewed for you), issues you encounter (and solutions if you find them), and any other information you think might be useful to have documented.
[02:13] <nhandler> This will save you from having to search through emails and Launchpad to find this information later on
[02:14] <nhandler> Although Ubuntu is a separate distribution, we still rely on Debian for lots of things.
[02:14] <nhandler> We pull many packages and patches from them.
[02:15] <nhandler> Therefore, it is important that we send our work back to them whenever possible
[02:17] <nhandler> If you decide to focus on particular packages in Ubuntu, I would urge you to contact the Debian Maintainer for each of the packages. You will (hopefully) be working with them a lot, and it is useful to have a good relationship with them. This tends to make it much easer to get patches and other changes made to the package as well as get help from the maintainer
[02:20] <nhandler> I know when I first got involved in development, I thought that developers were the people who packaged the applications. I didn't know about the other tasks they performed, and I thought that packaging applications was the only way I would ever gain upload privileges
[02:24] <nhandler> Developers perform many different tasks in the community (packaging being just one of them). They patch bugs reported on LP, sync/merge packages from Debian, fix packages that fail to build from source, help triage bugs and send bugs/patches upstream, as well as many other tasks.
[02:25] <nhandler> It is also important to remember that in Ubuntu, we do not have per-package maintainers. Therefore, if you package an application that not many people use, unless you help keep it patches/updated, it will soon become full of bugs and other issues.
[02:26] <nhandler> This is one reason why we try and encourage certain applications to go into Debian first (where they can then be synced into Ubuntu). Debian has per-package maintainers. This means that there is an individual or team responsible for every package in their repositories.
[02:28] <nhandler> Switching gears slightly, it is important to remember that we should avoid re-inventing the wheel whenever we can.
[02:29] <nhandler> I often see users who are simply unaware of existing tools, who try and create their own version. Before you start working on any project (whether creating a script, patching a bug, scripting a tool, or anything else), please take the couple of minutes to search and check for existing work
[02:31] <nhandler> The extra minute or two at the start will save you hours of wasted work down the road
[02:33] <nhandler> One pitfall that many developers run into at one point or another is burnout. We simply try and do more than we are capable of. Remember, quality work is better than a large quantity of work. Take it nice and easy at the start until you get a feel for how long certain tasks take and how difficult they are
[02:37] <nhandler> An important thing to remember is that this is not easy work. If you have questions or are a bit confused at first, that is perfectly normal. Try and avoid getting frustrated, read through a few guides, and ask questions when necessary. If you stick with it, you will be able to learn how to perform the various developer-related tasks (with some help from the community)
[02:41] <nhandler> Does anyone have any questions?
[02:42] <ClassBot> abgalphabet asked: what's your suggestion for a new developer to get start, e.g. what tools they need?
[02:42] <nhandler> There are lots of tools that can be useful to new developers
[02:43] <nhandler> You will need some way to test build your packages. Many developers use pbuilder for this. Some use sbuild, others use Launchpad PPAs, and others use a chroot/VM
[02:43] <nhandler> ubuntu-dev-tools and devscripts are also two useful packages
[02:44] <nhandler> They contain collections of scripts that other developers have created. They are designed to make your life easier, so I would suggest looking at them
[02:45] <nhandler> This last item isn't really a "tool", but it is still just as handy. You will want to reference the Debian Policy whenever you have questions about any aspect of a package. It is the authoritive source (although, there are a few minor divergences from it in the Ubuntu community)
[02:46] <ClassBot> abgalphabet asked: is there any pointer for new developer in the required/suggested tool chain?
[02:48] <nhandler> abgalphabet_: You will want to make sure you are building your packages on the development release of Ubuntu (i.e. once the natty repositories open up, you will want to build pacakges on natty).
[02:49] <nhandler> You don't actually need to run natty on your machine to do this. https://wiki.ubuntu.com/UsingDevelopmentReleases/OtherWays describes several options
[02:49] <nhandler> Any more questions?
[02:51] <ClassBot> There are 10 minutes remaining in the current session.
[02:52] <ClassBot> IdleOne asked: FTBFS?
[02:53] <nhandler> FTBFS means Fails To Build From Source. This means that we have a source package that we are unable to build and get a binary deb package. This might be due to certain build dependencies being unavailable, bugs in the upstream source code, or issues in the packaging (as well as other issues)
[02:54] <nhandler> http://qa.ubuntuwire.org/ftbfs/ shows packages that FTBFS
[02:54] <nhandler> Any last questions?
[02:56] <ClassBot> There are 5 minutes remaining in the current session.
[02:57] <ClassBot> amason asked: i have some applications that i wanted to package but i live in a rural area and don't have the bandwidth for pbuilder to set up it's chroot.
[02:58] <nhandler> amason: You could use PPAs to test build packages (in most cases). If you ask around, you could also probably find someone willing to give you ssh access to a machine to run pbuilder.
[03:00] <nhandler> Well, thanks for coming everyone. If you have any further questions, feel free to PM me or ask in #ubuntu-motu/#ubuntu-devel/#ubuntu-packaging (whichever is best) or on the ML.
[03:00] <nhandler> Logs will be on https://wiki.ubuntu.com/Packaging/Training/Logs
[03:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2010/10/15/%23ubuntu-classroom.html
[03:01] <nhandler> Well, that was annoying. I did !c several times instead of !q
[08:06] <stnv> .
[08:51] <michaelgraaf> join #teachingopensource
[08:52] <michaelgraaf> #join teachingopensource
[11:57] <sebsebseb> Hi
[12:59] <johann_karlsen> Is this channel empty? Are you all away?
[13:01]  * pedro3005 raises hand
[13:03] <Kvik_sverige> If ubuntu one can't sync, is there anyway i can force it?
[13:04] <persia> Kvik_sverige, This isn't a support channel.  Maybe try #ubuntuone ?
[13:05] <Kvik_sverige> persia,  sorry
[14:58] <akgraner> 2 minutes til Day 5 kicks off
[14:58] <dpm> \o/
[14:59] <akgraner> the logs of the past sessions are linked up now and linked to the time table
[15:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2010/10/15/%23ubuntu-classroom.html following the conclusion of the session.
[15:01] <akgraner> Good Morning
[15:02] <akgraner> Up first to day is David Planella with the Community team
[15:02] <akgraner> Don't for get have a survey this time for  you to give us feedback - http://www.surveymonkey.com/s/GBSK33S
[15:02] <akgraner> ok dpm if you are ready take it away
[15:02] <dpm> Thanks akgraner!
[15:03] <dpm> Hey!
[15:03] <dpm> How's everyone?
[15:03] <dpm> Welcome to another translations session this week
[15:03] <dpm> For those of you interested in our exciting translations world, don't forget to check out the logs on getting started translating Ubuntu, from last Tuesday:
[15:03] <dpm>   https://wiki.ubuntu.com/MeetingLogs/openweekMaverick/GettingStartedTranslatingUbuntu
[15:04] <dpm> I'm David Planella, I work in the Community team as Ubuntu Translations Coordinator,
[15:04] <dpm> and in the next hour I'll be talking a bit about best practices for translation teams
[15:04] <dpm> The intention is to help translation teams to make the best use of the existing resources to be effective and successful,
[15:05] <dpm> with the end goal to provide millions of people with a localized desktop in their own language.
[15:05] <dpm> Which when you look at it, it's a pretty awesome goal.
[15:05] <dpm> There will be plenty of time for questions at the end, but if you've got any at any point during the session, please feel free to ask.
[15:06] <dpm> Right, so after being done with presentations, let's get on to it, shall we?
[15:06] <dpm>  
[15:06] <dpm> I'm going to start with the two most important points I believe a translation team should concentrate on setting up first.
[15:06] <dpm> These will provide the ground work to build upon for a successful translation effort:
[15:07] <dpm> for a good team coordination and to foster team growth
[15:07] <dpm>  
[15:07] <dpm> Translation Guidelines
[15:07] <dpm> ----------------------
[15:07] <dpm> Each team should have a document that outlines the conventions used to translate into their language,
[15:07] <dpm> as well as how the team works.
[15:07] <dpm> This should include things such as:
[15:08] <dpm>  * How to join the team
[15:08] <dpm>  * The workflow for submitting and reviewing translations
[15:08] <dpm>  * [IMPORTANT] Guidelines for translation of computer programs into the team's language: grammar rules, conventions, a glossary with translations of common terms, etc.
[15:09] <dpm> I'll restate the last point: it will take a while to create the translation guidelines, but once set up,
[15:09] <dpm> they will extremely speed up the translation process and help providing a consistent and quality translation.
[15:09] <dpm> Most teams use the Ubuntu wiki to host such a document, under a page such as Ubuntu<Language>Translators.
[15:09] <dpm> Here is an example: https://wiki.ubuntu.com/UbuntuCatalanTranslators
[15:10] <dpm> One word of advice on the first two points: try to define the processes (accepting new team members, review workflow, etc.), but try not to make them too bureocratic :)
[15:10] <dpm>  * More info:
[15:10] <dpm> Here you'll find more information about guidelines for translation teams, along with some nice examples from other teams that should help you get started:
[15:11] <dpm>  https://wiki.ubuntu.com/Translations/KnowledgeBase/TranslationGuidelines
[15:11] <dpm>  
[15:11] <dpm> Communication
[15:11] <dpm> -------------
[15:11] <dpm> For a well coordinated effort and to enjoy true community work, it is also important that team members keep in touch.
[15:12] <dpm> It is not only important from a social point of view and for a healthy team,
[15:12] <dpm> but also for discussion about the translation itself: doubts about translations, organizing online or physical events for translations, etc.
[15:12] <dpm> The most common communication channel is a mailing list.
[15:13] <dpm> You can request one at https://lists.ubuntu.com/ or in Launchpad,
[15:13] <dpm> although for translation teams we recommend an Ubuntu list.
[15:13] <dpm> We've also got a global mailing list for Ubuntu Translators.
[15:13] <dpm> We ask all local team coordinators to subscribe and forward all relevant messages to their teams,
[15:14] <dpm> but anyone interested in following news about Ubuntu Translations is welcome to subscribe. Here's how:
[15:14] <dpm>  https://wiki.ubuntu.com/Translations/Contact/
[15:14] <dpm> Other useful ways of communicating are local forums and IRC channels.
[15:15] <dpm> IRC can be very useful to run meetings to discuss the translation coordination, setting goals, organize events, etc.
[15:15] <dpm> Forums can be used in a very similar way as mailing lists, but have some additional features and might be friendlier for beginners
[15:16] <dpm> It is also worth getting in touch with your local community team (LoCo) if there is one.
[15:16] <dpm> There might be people willing to help with the translation effort there.
[15:16] <dpm> You can find a LoCo nearby here:
[15:16] <dpm>  http://loco.ubuntu.com/
[15:16] <dpm>  
[15:17] <dpm> Regular Events
[15:17] <dpm> --------------
[15:17] <dpm> You'll want to keep your team alive, get people excited about translations and get new contributors for your language.
[15:17] <dpm> Running regular translations events will help you on this
[15:18] <dpm> You can organize translations jams any time. They can be, for example:
[15:18] <dpm>  * Online IRC events: where several contributors join on IRC to work together on finishing a set of translations
[15:18] <dpm>  * Physical events: where existing and new contributors meet at a place to work on translations in the same way.
[15:18] <dpm> Here are some hints to organize such an event:
[15:18] <dpm>  https://wiki.ubuntu.com/Jams/Translations
[15:19] <dpm> A very good occasion for organizing such an event is during the Ubuntu Global Jam.
[15:19] <dpm> The Global Jam happens once every release, near the end of the cycle,
[15:19] <dpm> and during this time LoCo teams from all over the world join the party to contribute to improving Ubuntu
[15:20] <dpm> using the best skills they have in particular areas
[15:20] <dpm> A key area are, of course, translations.
[15:20] <dpm> So this is a good time to join the worldwide party and organize a Translations Jam for your language
[15:20] <dpm>  * More info on the Ubuntu Global Jam:
[15:20] <dpm>  https://wiki.ubuntu.com/UbuntuGlobalJam
[15:21] <dpm> Remember to announce any event in advance, so that people know about them with enough time and have time to prepare and make arrangements.
[15:21] <dpm> You can use social networking resources (microblogs, blogs, Facebook, news sites, etc.) or any other means (e.g. regular press, flyers, etc.) to make a wide announcement.
[15:21] <dpm>  
[15:21] <dpm> Regular Meetings
[15:21] <dpm> ----------------
[15:22] <dpm> To help getting the information flowing, to coordinate the translation efforts and for more agile discussion, IRC meetings can also be extremely useful
[15:22] <dpm> Meetings are good for:
[15:22] <dpm>  * Sharing news
[15:22] <dpm>  * Getting to know or introducing new members to the team
[15:22] <dpm>  * Discussing and setting translation goals
[15:23] <dpm> Even if you don't run many meetings, it is always useful to have a couple of them in the cycle.
[15:23] <dpm> For example:
[15:23] <dpm>  * A meeting at the beginning of the cycle to discuss or announce any news in translations, and to set goals (e.g. "Finish the ubuntu-docs translation this cycle")
[15:24] <dpm>  * A meeting near the end of the cycle to discuss what's left to do and to organize any events to give a final push to translations before release
[15:24] <dpm> You can create a new IRC channel for your team on Freenode (e.g. #ubuntu-l10n-<languagecode>),
[15:24] <dpm> or reuse the one your LoCo has, if there is one.
[15:25] <dpm>  
[15:25] <dpm> Spreading the Word
[15:25] <dpm> ------------------
[15:25] <dpm> You'll also want everyone to know about your translation effort: your achievements, where you need help, etc.
[15:25] <dpm> Let the world know: this will help you build up a strong community and user base around your team and get people interested in participating
[15:26] <dpm> Use the social networks, blogs, microblogs, Facebook, etc.
[15:27] <dpm> Publish your achievements, how and where is Ubuntu used in your language, any topic related to the work that you are doing
[15:27] <dpm> Consider getting some members of the team to apply for Ubuntu membership:
[15:27] <dpm> amongst other benefits, they'll be able to post to the Ubuntu Planet and let the global community know about your translation efforts.
[15:28] <dpm> Here's how:
[15:28] <dpm>  https://wiki.ubuntu.com/Membership
[15:28] <dpm>  
[15:29] <dpm> Upstream Collaboration
[15:29] <dpm> ----------------------
[15:29] <dpm> The more you get involved in the translations process, the more you'll hear about upstreams.
[15:29] <dpm> Ubuntu, as a project, includes the best of breed Open Source software projects available.
[15:29] <dpm> Many of these are developed outside of the Ubuntu project. We call them upstreams.
[15:30] <dpm> As such, it is also common that translations in upstream projects are done outside of Launchpad, with different teams than the Ubuntu translators.
[15:31] <dpm> We import those excellent translations from upstream translators and expose them in Launchpad for the Ubuntu translation teams to complete and fix if necessary.
[15:31] <dpm> It is important for these new translations and fixes to flow back to the upstream projects,
[15:32] <dpm> so a smooth relationship with the upstream teams is the best way to achieve this.
[15:33] <dpm> In my experience, having members from the Ubuntu translation team join the upstream teams or viceversa is usually the best way to go.
[15:33] <dpm>  * You can learn more about Ubuntu and upstreams here:
[15:34] <dpm>  https://wiki.ubuntu.com/Translations/Upstream
[15:34] <dpm>  
[15:34] <dpm> Other Tips
[15:34] <dpm> ----------
[15:34] <dpm>  * If there isn't a translation team for your language, you can start one like this: https://wiki.ubuntu.com/Translations/KnowledgeBase/StartingTeam
[15:35] <dpm>  * Before accepting new members to a team, it might be worth letting them translate a few strings and mentor them in the process of becoming an Ubuntu translator
[15:35] <dpm>  * Use the Launchpad UI for translations: it will allow submitting both suggestions and translations whenever you've got time and saving them. You can go back to them, complete them or modify them at any later time
[15:36] <dpm> (so that will allow you things as submitting translations with your phone while you're waiting in the supermarket queue :)
[15:37] <dpm>  * For extra QA, make use of Launchpad's built-in review features: even if you can submit translations directly, tick the "Someone should review this translation" checkbox or use the "Reviewer mode" link and get someone else from the team to review your suggestions
[15:37] <dpm>  * Use the Ubuntu wiki or an external one to make a list of the translations that need work and to keep track who is working on them
[15:38] <dpm>  * Remember that translation templates in https://translations.launchpad.net/ubuntu are ordered by priority: the most important templates appear first on the list. You might want to concentrate on those first
[15:39] <dpm>  * You can ask any questions about Ubuntu Translations on the translators mailing list or in Launchpad: https://answers.launchpad.net/ubuntu-translations/+addquestion
[15:39] <dpm>  * We've also got a FAQ for anything related to Ubuntu Translations: https://answers.launchpad.net/ubuntu-translations/+faqs
[15:40] <dpm>  * If you are a team coordinator, here you'll also find some guidelines for you https://wiki.ubuntu.com/Translations/KnowledgeBase/TeamCoordinatorResponsibilities
[15:40] <dpm>  * If you are a team coordinator and can no longer take care of the team, or if your translation team coordinator is not responding, here are some tips for a graceful role reassignment: https://wiki.ubuntu.com/Translations/KnowledgeBase/RoleReassignmentPolicy
[15:41] <dpm>  * External resources such as http://open-tran.eu/ are also useful to check translation terminology and consistency
[15:41] <dpm>  * Check out the Ubuntu Translations Knowledge Base https://wiki.ubuntu.com/Translations/KnowledgeBase - you'll find lots of info there, don't read it at once, it's rather thought as a reference resource. Feel free to expand and modify it!
[15:41] <dpm>  
[15:41] <dpm> Q&A
[15:41] <dpm> ---
[15:41] <dpm> So that was all for the listening part :)
[15:42] <dpm> We've got some minutes left for you, please feel free to ask any questions related to translation teams or Ubuntu translations in general
[15:42] <dpm> If you are a member of an existing team, also please feel free to share your views, tips, workflow, etc.
[15:42] <dpm> (just ping me on #ubuntu-classroom-chat and we'll give you voice on this channel)
[15:42] <ClassBot> IdleOne asked: Good morning! Wanted to ask about the CoC and what the chances of seeing it translated officially so that everybody can read/sign it in their own language in time for 11.04. there is at least one unofficial French version at https://wiki.ubuntu.com/Proposed/frCodeOfConduct ?
[15:43] <dpm> There will be a session at UDS for this, and any contributions to help achieving this will be very welcome
[15:44] <dpm> Stay tuned for the scheduling of UDS sessions in the next few days
[15:44] <dpm> Any more questions?
[15:44] <ClassBot> arjunaraoc asked: Ubuntu mail archive rendering does not support  non latin scripts. can I migrate my team to google groups
[15:46] <dpm> Of course. We recommend using the Ubuntu resources, but if there are such issues, feel free to use an external resource. I'm surprised that mailman does not support non-latin scripts, though. You should probably file a bug against mailman, the software used for the Ubuntu mailing lists
[15:46] <dpm> next?
[15:46] <ClassBot> arjunaraoc asked: How is the priority of translation packages determined?
[15:47] <dpm> This will give you an insight on how the priority is defined:
[15:47] <dpm>  https://wiki.ubuntu.com/Translations/TemplatesPriority
[15:48] <dpm> we basically worked out a scheme for priorities assigning each template or group of templates a numerical value
[15:48] <dpm> and then we entered those values in Launchpad
[15:48] <andrejz> I have a suggestion about a chat room. In our case it turned out that many people (especially new ubuntu users, who are enthusiastic to help out) do not know how to use IRC. To lower the entry barrier we use a jabber chatroom, like this one. http://partychapp.appspot.com/. This means potential contributors only need to add a new contact to their gmail/jabber account (which everyone has) and start writing. It might not seem much, bu
[15:48] <andrejz> t this helps a lot.
[15:48] <dpm> Thanks andrejz, that's a good suggestion
[15:49] <ClassBot> valter asked: How to better improve upstream / launchpad integration? Release packages often contains untranslated strings due to different workflows
[15:49] <dpm> That's correct
[15:50] <dpm> The Launchpad Translations developers are currently focusing on improving upstream integration
[15:50] <dpm> The first part is import: how translations get into Launchpad for the Ubuntu project
[15:51] <dpm> Right now it is through packages, which leads to times in which translations are out of sync
[15:51] <ClassBot> There are 10 minutes remaining in the current session.
[15:51] <ClassBot> valter asked: is it possible to have a different structure to better match the different distros?
[15:51] <dpm> The plan is to import translations directly from bzr-mirrored upstream branches
[15:51] <dpm> so that translations are imported with just a few hours delay
[15:52] <dpm> valter, could you specify what you mean by a different structure?
[15:53] <dpm> in the meantime, are there any more questions or suggestions related to translation teams?
[15:55] <andrejz> i would like to add it's good to look at l10n.gnome.org/languages/ and see if gnome upstream exists for your language and coordinate with them. also do that for other teams (KDE, Debian, Translation project)
[15:56] <ClassBot> There are 5 minutes remaining in the current session.
[15:56] <dpm> yeah, good point. andrejz is the team coordinator for both GNOME and Ubuntu in Slovenian, so he knows well what he's talking about :)
[15:57] <andrejz> i am just a member of gnome translators group (also a member of translation project)
[15:57] <dpm> in any case well experienced in terms of upstream-downstream coordination :)
[15:58] <andrejz> if upstream team has difficulties with the workload don't be afraid to send, lend your members to them
[15:59] <andrejz> Question: why do not you take out firefox, debian-installer, which require other setups for proper translation/check in from launchpad or atleast make them readonly
[15:59] <dpm> let me answer this on the -chat room, as we've got no more time on this session
[15:59] <dpm> Ok, so many thanks for listening and participating, and thanks for andrejz's input as special guest :)
[15:59] <dpm> I'll now leave you in the good hands of Scott Lavender, who'll be talking about "Ubuntu Studio Q&A"
[16:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2010/10/15/%23ubuntu-classroom.html following the conclusion of the session.
[16:01] <ScottL> Hello and welcome to Ubuntu Studio: Q & A
[16:02] <ScottL> I am Scott Lavender, project lead for Ubuntu Studio and I look forward to answer any questions you might have
[16:02] <ScottL> But first I'll mention some things about Ubuntu Studio
[16:02] <ScottL>  
[16:02] <ScottL> What exactly is Ubuntu Studio?
[16:03] <ScottL> Ubuntu Studio is based on Ubuntu, it shares the same core code
[16:04] <ScottL> but we include various audio, video, and graphical applications that are not included in the typical desktop Ubuntu installation
[16:04] <ScottL> additionally, we make some changes to some system settings, which is intended to improve performance
[16:05] <ScottL> in the past we have had a tuned kernel available, as well, to improve performance
[16:06] <ScottL> and our hope to provide a tuned kernel included in a default installation in the near future (perhaps in natty)
[16:07] <ScottL> any questions so far?
[16:08] <ScottL> Right.  Moving on, I'll address some of the more common questions that I see
[16:08] <ScottL> One is network configuration
[16:09] <ScottL> Ubuntu Studio chooses to include the gnome-network-admin package for handling networking
[16:09] <ScottL> this choice was because network-manager was found to degrade performance
[16:10] <ScottL> when i say "degrade performance" in this case, it means it increased latency or cause xruns when recording audio
[16:11] <ScottL> it was found that gnome-network-admin did not cause the same performance degradation
[16:12] <ScottL> unfortunately, it was also found that gnome-network-admin had a patch applied to it that removed the configuratuion UI when network-manager was chose to handle networking in both Debian and Ubuntu, I believe
[16:13] <ScottL> while this did not prove so troubling to persons using a wired connection to a dhcp router, many users (say laptop users) found that they could not configure their connections and therefore unable to connect to the internet
[16:14] <ScottL> luckily the patch was moderated as of Maverick and Ubuntu Studio users should now be able to configure their network connections once again
[16:16] <ScottL> as a backup, however, we have been including network-manager on the dvd
[16:16] <ScottL> network-manager is not installed by default, but can be installed manually if the user chooses
[16:16] <ScottL> !q
[16:18] <ClassBot> charlie-tca asked: Studio has quite a busy login and background. For some of us, it is hard to distinguish the background black pattern and the panel. Any plans to change this?
[16:19] <ScottL> short answer is yes, we are looking to changing the art
[16:20] <ScottL> we would prefer to use art that is user created and we welcome submissions
[16:21] <ClassBot> charlie-tca asked: I guess mostly I am hoping it will become more accessible. Those with visual impairments will have some issues trying to see with the background as busy as it is.
[16:21] <ScottL> i agree
[16:22] <ScottL> i personally prefer a background with less contrast in it as the desktop become very confusing
[16:22] <ScottL> additionally, we currently lack an art lead, if anyone is interested please contact the ubuntustudio-devel mailing list
[16:23] <ScottL> https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
[16:24] <ScottL>  
[16:24] <ScottL> if anyone has questions, please ask them at any time, otherwise I will move onto other questions that are asked often
[16:25] <ScottL> Another question asked, is why the Ubuntu Studio team chooses to make an ISO rather than use the Ubuntu desktop CD and install packages from the archives or PPA?
[16:26] <ScottL> One certainly can start with a Ubuntu (or Xubuntu, Kubuntu, Lubuntu, et al) install and install packages and many do!
[16:26] <ScottL> however, as a team we choose to make an ISO for various reasons
[16:26] <ScottL> firstly, this allows us to control what does NOT get installed
[16:27] <ScottL> for example, the me-menu and other social items are excluded from the default Ubuntu Studio installation as they would general degrade performance
[16:27] <ScottL> a user may certainly install them if they wish from the repositories, and that is their choice of course
[16:28] <ScottL> there are system settings (e.g. adding user to audio group) extant in the default Ubuntu Studio installation
[16:28] <ScottL> these would need to be made manually otherwise
[16:30] <ScottL> an extremely useful benefit for a new user
[16:30] <ScottL> other reasons include using the installation disc on multiple computer or computers without an internet connection
[16:32] <ScottL> Moving on, I'll talk about some of the improvement in Ubuntu Studio for the Maverick release
[16:32] <ScottL> we now have better integration between Pulse Audio and JACK
[16:33] <ScottL> we have updated JACK from the 0.118 series to the 1.9.5 I believe
[16:33] <ScottL> the pertinent improvement in this is that JACK now uses D-BUS to negotiate with devices
[16:33] <ScottL> this allows JACK and Pulse Audio to coexist much better than before
[16:34] <ScottL> prior to this, starting JACK via qjackctl would cause Pulse Audio to suspend
[16:34] <ScottL> this is no longer the case
[16:35] <ScottL> both can be used at the same time as long as Pulse Audio and JACK are using different devices
[16:35] <ScottL> for example
[16:36] <ScottL> I would expect many (if not most) Ubuntu Studio computer to have an additional audio interface (say an MAudio delta 44) in addition to an onboard integrated sound chip
[16:36] <ScottL> in this case, one could watch a youtube video and hear the sound through the onboard audio device
[16:37] <ScottL> while playing guitar and hearing it through the delta 44
[16:40] <ClassBot> charlie-tca asked: any chance Ubuntu Studio could be made to fit a standard CD?
[16:40] <ScottL> that is both an excellent question and a laudable goal
[16:40] <ScottL> my answer would be that it is possible, but at what cost?
[16:41] <ScottL> it is possible, indeed, but we would need to see what functionality we would be eliminating
[16:41] <ScottL> we would also need to evaluate the ultimate reason to fitting on a CD
[16:42] <ScottL> if the reason is bandwidth, that might be address in a better way by evaluating the current package selection (ideally without hindering functionality)
[16:42] <ScottL> if the reason is because CD's are less expensive and more pervasive than DVD's, that certainly would be hard to be addressed in another manner
[16:43] <ScottL> again, an excellent question
[16:43] <ClassBot> charlie-tca asked: what is the IRC channel for Ubuntu Studio?
[16:43] <ScottL> the IRC channel for Ubuntu Studio is #ubuntustudio
[16:44] <ScottL> this is for most general questions about Ubuntu Studio
[16:45] <ScottL> if you wish to talk with the developers about contributing to Ubuntu Studio (e.g. artwork, themes, testing, documentation) you can read them at #ubuntustudio-devel on IRC as well
[16:45] <ScottL> users will most likely find helpful information at https://help.ubuntu.com/community/UbuntuStudio
[16:46] <ScottL> this is geared more toward helping users user Ubuntu Studio
[16:46] <ScottL> development topics are generally found at https://wiki.ubuntu.com/UbuntuStudio
[16:47] <ScottL> users can also find assistance at the ubuntustudio-users mailing list https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-users
[16:48] <ClassBot> charlie-tca asked: what are the expected changes for Natty in Ubuntu Studio? anything major known yet?
[16:48] <ScottL> There are substantial changes lined up for Natty
[16:49] <ScottL> currently we are working with the Ubuntu Kernel Team to develop and maintain a -lowlatency kernel in the official repositories
[16:49] <ScottL> the is important
[16:49] <ScottL> i mentioned before a tuned kernel, which was the -rt kernel
[16:50] <ScottL> unfortunately this kernel could not be consistently maintained in the repos and align with the -generic kernel (the -rt patch is not available for every release version)
[16:50] <ScottL> therefore, we choose the -lowlatency kernel to be the default installed kernel for Ubuntu Studio
[16:51] <ClassBot> There are 10 minutes remaining in the current session.
[16:51] <ScottL> our plan is to also provide a -realtime kernel available in PPA to those who require it (e.g. firewire audio interface users)
[16:51] <ScottL> we are also evaulating our package selection by focusing on tasks
[16:52] <ScottL> we are mapping tasks that users might want to accomplish and making sure we have a complete and effective workflow developed to support that tasks
[16:52] <ScottL> this will decided which applications are included in Ubuntu Studio
[16:53] <ScottL> users are encourage to help in this process at https://wiki.ubuntu.com/UbuntuStudio/Workflows
[16:53] <ScottL>  
[16:54] <ScottL> the task based workflows are important because this will also provide the framework for documentation and testing as well
[16:55] <ScottL> one last thing we hope to accomplish is to update the ubuntustudio.org website before natty
[16:55] <ScottL> we are currently evaluating mockups for this at the moment and hope to decide on a direction soon and start moving forward
[16:56] <ClassBot> There are 5 minutes remaining in the current session.
[16:56] <ScottL> if anyone is interested in helping with that please contact me
[16:56] <ScottL> https://launchpad.net/~slavender
[16:56] <ScottL> and if anyone is interested in helping in ANY aspect with Ubuntu Studio please do not hesitate to contact me as well :)
[16:58] <ScottL> I want to thank everyone that showed up for this class, I certainly enjoyed myself and I hope you did too
[17:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2010/10/15/%23ubuntu-classroom.html following the conclusion of the session.
[17:01] <jledbetter> Howdy everyone! My name is Jessica Ledbetter and I’m a web developer and long time user of Linux but new user of Ubuntu. My first install was in October 2009 and I’m currently using 10.10. I’m a member of the Virginia LoCo, California LoCo, and Ubuntu-Women. More information if you want it: https://wiki.ubuntu.com/jledbetter
[17:03] <jledbetter> And Cheri703 is Cheri Francis who has been using Ubuntu since 2008, but only recently begun exploring beyond the basic desktop environment. She is also a member of the Ohio LoCo and often loiters in the Ubuntu-Women IRC room. And she'll be answering your questions today. :)
[17:03] <jledbetter> One of the strengths to Ubuntu is the community. In this session, you’ll learn about the various resources to help you connect with that community to help you fix problems you may encounter while using Ubuntu.
[17:03] <jledbetter> We’ll look at how to figure out what happened, find out ways you can fix it and what to do if you can’t.
[17:04] <jledbetter> As a reminder, if you have a question, please begin it with QUESTION: in the #ubuntu-classroom-chat room. For example: QUESTION: What does the session's title mean? And then we will answer in this channel #ubuntu-classroom with the answer. It keeps the logs tidy and the channel bot happy.
[17:05] <jledbetter> Something happened! There was a crash or data went away or Tomcat and Eclipse are not working well together magically. Pause, don't panic, and put on your detective hat.
[17:05] <jledbetter> Because, no matter what, you'll need information for either yourself to help you fix the problem or for someone else to do it.
[17:05] <jledbetter> First: What happened?
[17:06] <jledbetter> What was the error message (if there was one)?
[17:06] <jledbetter> Can you get a screenshot (print screen)?  When you print screen, a box will come up and ask where you want to save it to. I usually save it to desktop because it's easy to find and easy to delete after I'm done.
[17:07] <jledbetter> A screenshot can also capture errors that don't have a message like a menu item is in the wrong spot or there's a blank window where text should be.
[17:08] <jledbetter> If you don't want to or can't get a screenshot, you can maybe copy the message into a text editor (like gedit) or write it on a piece of paper. Recording it is very helpful for later.
[17:08] <jledbetter> If you write it down, write it clearly and make sure to get symbols, punctuation and spacing correct, they can make a big difference!
[17:08] <jledbetter> If you copy it, it's easier to paste into forums or a search engine.
[17:09] <jledbetter> If it's something that isn't maybe an error message but happens during a sequence of events, you can try creating a video of your steps: gtk-recordmydesktop. I haven't tried this though. More information: http://recordmydesktop.sourceforge.net/about.php
[17:10] <jledbetter> Information that is also helpful is package information and hardware information.
[17:10] <jledbetter> Steps to find out your package information for Gnome, KDE, etc: https://wiki.ubuntu.com/Bugs/FindRightPackage
[17:11] <jledbetter> If you need to know what hardware you have (for example, sound isn't working and it might be helpful to know *what* soundcard you have): use the hardware lister command: sudo lshw > ~/Desktop/hardware.txt
[17:11] <jledbetter> This will output the list of your hardware to a file called "hardware.txt" on the Desktop. Again, where is easiest for you works here.
[17:12] <jledbetter> Another command line tool is lspci which will list the hardware connected to the PCI bus. If you're having network problems, for example, and want to see if your network card is is seen you can do this which will find all the occurrences of "Network" via the lspci command. Like this: lspci | grep Network
[17:13] <jledbetter> For those more familiar with a Windows layout, or more comfortable with a graphical program vs command line, the package "gnome-device-manager" is a GUI tool that has the information about any devices recognized as attached to the computer.
[17:13] <jledbetter> For more information on debugging applications, check out this wiki page: https://wiki.ubuntu.com/DebuggingProcedures
[17:14] <jledbetter>  
[17:14] <jledbetter> Now that you are armed with lots of clues on to why something happened, it's time to put the pieces together and find out how to fix it. First, let's try fixing it ourselves!
[17:14] <jledbetter>  
[17:15] <jledbetter> Any questions so far or shall we plow through to how to fix it?
[17:18] <Cheri703> Looks like there aren't questions at the moment. Feel free to ask as we go along though!
[17:18] <jledbetter> evdev mentioned in chat about the "apport" command. Here's how to enable it and more about how it can help you debug crashes: https://wiki.ubuntu.com/Apport  Thank you, evdev :)
[17:19] <jledbetter> Right o! Back to fixing the problems ourselves.
[17:19] <jledbetter> After recording as much information as possible about error messages and such, try rebooting the computer. This has fixed MANY things for Cheri703 after spending far too much time looking for an answer, rebooted and "oh, it's fixed" TRY THIS FIRST!
[17:19] <jledbetter> And that is why the title of this session ;)
[17:21] <jledbetter> Some common tools needed are a CD, USB, copy of ISO, Ubuntu Rescue Remix ( http://ubuntu-rescue-remix.org/ ). I haven’t needed to do this though. Usually I can fix my problems with either reinstalling the application that “went to a bad state" or by updating a config file that was just plain old wrong.
[17:21] <jledbetter> It's time to search for the solution. You can use a the search on Ubuntu's website or your favorite search engine.
[17:22] <ClassBot> charlie-tca asked: would a Ubuntu desktop image, with the live environment work?
[17:23] <Cheri703> My understanding is that yes, for many things, a regular desktop image would be helpful
[17:23] <Cheri703> the Rescue Remix has additional utilities
[17:23] <Cheri703> Recovery software
[17:24] <Cheri703> You can always try the live cd, and if that doesn't help, use the live session to get the Rescue Remix :)
[17:26] <Cheri703> Ok, jledbetter, back to searching :)
[17:27] <jledbetter> Awesome! Searching... Ah yes, there's a lot of information out there on the wild wild web. How can we phrase our search to find the right answer?
[17:28] <jledbetter> Generally starting very specific and working your way out is the easiest way to go about it. Don't add extra words if possible. "how do I get a dell xmodel# laptop to burn CDs in ubuntu" isn't likely to find a good solution. "Dell xmodel# ubuntu 10.10 cd burn" will offer more options. If nothing is found there, then taking it to "Dell xmodel# ubuntu cd burn" and so on, adjusting terms (cd drive vs burn, etc).
[17:29] <jledbetter> Searching on Ubuntu's website is done here: http://search.ubuntu.com/. This will search Ubuntu.com, Ubuntu documentation, Mailing lists and forums, Ubuntu wiki, Ubuntu Merchandise, and Canonical blog (news).
[17:29] <jledbetter> I usually go to my favorite search engine and type in my error message or my application and the version of Ubuntu. For example, I had issues with Eclipse and 10.04 so I searched "eclipse ubuntu 10.04" and found the answer within the top 2 links.
[17:30] <jledbetter>  
[17:30] <jledbetter> Another option to searching everything, is to search or use certain communities specifically. Here is a list of the ways we can get support via community: http://www.ubuntu.com/support/community
[17:30] <jledbetter> Basically, it lists web forums, mailing lists, IRC, Launchpad, and Local language support. It can be a great starting point if you don't remember the links we list in the next few minutes.
[17:31] <jledbetter> If you want to go straight to the official documentation, that's here: https://help.ubuntu.com
[17:31] <jledbetter> If you want to try the community, find your way through it here: https://help.ubuntu.com/community/
[17:31] <jledbetter> There's a signpost with some links next to it that will help guide you into the community based on your answer.
[17:32] <jledbetter> If you would like to try "real time" help, you can use IRC . You're using IRC right now to attend this classroom session.
[17:32] <jledbetter> Some good channels to join for help are:  #ubuntu (the default Ubuntu help channel), #kubuntu (of course, if you're using Kubuntu), your Local Community IRC (more to come on that) and many channels specific to applications (search "*application* IRC").
[17:33] <jledbetter> For more information on IRC, you can look at this help page: https://help.ubuntu.com/community/InternetRelayChat
[17:33] <jledbetter>  
[17:33] <jledbetter> Here are 3 quick tips on how to ask for help in IRC.
[17:34] <jledbetter> 1) Join and wait a moment. If folks are in the middle of helping someone else, let them finish. That way, your problem can be given attention instead of lots of text scrolling your screen.
[17:34] <jledbetter> 2) Be patient. Not everyone is at the keyboard 24/7. Some are at work and might be away from the keyboard for a moment before starting to answer your question or even during.
[17:35] <jledbetter> 3) Be polite. Almost all of us are volunteers and help out others because we like it. If we don't know the answer, we might know someone or another way to get the answer.
[17:36] <jledbetter> And then there's how not to ask for help. An example is here: http://ubuntuforums.org/showthread.php?t=661374  Basically, be a little more specific in your request so that others can help debug your problem with you. :)
[17:37] <jledbetter> Let's say that you have a very large error message or the application you were using output a bunch of lines with file names in them like a "stack trace," then you can use an external way to paste the information in and share it with those in the channel.
[17:38] <jledbetter> This way, it's more easily readable to all involved. This is a place you can paste your error message: http://paste.ubuntu.com/
[17:39] <jledbetter> If you would like to post your problem in a more leisurely manner and/or read through some potential solutions to your problem, you can try the forums: http://ubuntuforums.org/forumdisplay.php?f=327  The forums are great. I found an answer to a problem I was wrestling with for a few hours there last night, as a matter of fact!
[17:40] <jledbetter> A wonderful forum to start out with is "Absolute Beginner's Talk" http://ubuntuforums.org/forumdisplay.php?f=326
[17:40] <jledbetter> The usual recommendations for how to ask for help and how not to ask for help apply, of course. If you do get a solution outside of the forum, please post a reply in your thread with what worked for you. It might help out someone else! Also, it'll stop others from trying to solve the solved problem.
[17:40] <jledbetter> Any more questions so far?
[17:41] <jledbetter> Well, if you do, feel free to ask with QUESTION :)
[17:42] <jledbetter> Another way to ask for help much like a forum is via Stackexchange. And, it's new: http://askubuntu.com
[17:43] <jledbetter> And more about the project is here: http://castrojo.tumblr.com/post/1283990862/and-were-live
[17:43] <jledbetter> I highly recommend it. Just flipping through the questions and answers is fun and informative. As Jorge Castro says, "Remember people love to vote on answers with screenshots and easy to use instructions. Go get em!" And you already know how to make screenshots from a few minutes ago, right?
[17:44] <jledbetter> Sill more ways to find help are Launchpad answers (http://answers.launchpad.net/ubuntu), mailing lists  (https://lists.ubuntu.com/#Community+Support), your local Local Community (LoCo) team - (http://loco.ubuntu.com/teams/), or even your local Linux User Group (LUG) (http://www.linux.org/groups/).
[17:45] <jledbetter> With your LoCo team and Linux User Groups, you might be able to take it to the group in person. That might help.
[17:45] <jledbetter> Or just asking in your team channel might find an answer more quickly than #ubuntu. That's the order that I do it: LoCo team channel then #ubuntu.
[17:46] <jledbetter> Let's say that you went through all the previous methods to try to find solution and are still stuck. Perhaps it's an honest to goodness bug and needs to be fixed.
[17:48] <jledbetter> Here is how you can file a bug report: https://help.ubuntu.com/community/ReportingBugs
[17:48] <jledbetter> Again, if you want to see about some real-time help or have problems reporting the bug, the "Bugsquad" is in #ubuntu-bugs.
[17:48] <jledbetter> A bug report should include at least the release of Ubuntu, version of package (example: apt-cache policy firefox-3.5), what you expected to happen, and what actually happened.
[17:50] <jledbetter> If you don't want to go through finding and fixing your system, there is paid support available. And more on that is here: http://www.ubuntu.com/support/services
[17:50] <jledbetter> Any other questions?
[17:51] <ClassBot> There are 10 minutes remaining in the current session.
[17:52] <Cheri703> jledbetter: looks like we answered EVERY question anyone could possibly have! ;)
[17:52] <jledbetter> Cheri703: We're that good ;)
[17:53] <jledbetter> Today we were reminded of one of the strengths to Ubuntu: its community. Hopefully, you've seen how easy it is to find many different ways to connect to the knowledge base of the community and how to get help fixing problems.  Also, you saw what to do if all else fails and you need to file a bug report.
[17:54] <jledbetter> And, speaking of bug reports, up next is hggdh,  one of the members of the Bug Squad, to talk about "Bug Triaging: Do's and Do not's."
[17:56] <ClassBot> There are 5 minutes remaining in the current session.
[18:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2010/10/15/%23ubuntu-classroom.html following the conclusion of the session.
[18:01] <hggdh> Hello. My name is Carlos de-Avillez. I am one of the administrators for the BugSquad and BugControl teams on Ubuntu. I have been around bugs for pretty much all my professional life -- causing them, or finding them, or fixing them (or all three in sequence ;-).
[18:01] <hggdh> I started with Ubuntu in 2006, when I was trying to find a Linux distribution that I felt more confortable with, and that did not need me to spend a lot of time tweaking the kernel, etc. And guess what... Ubuntu won! :-). I then joined the community, and started being active beginning of 2007.
[18:02] <hggdh> Now, as usual, questions should be asked on the #ubuntu-classroom-chat channel. If you want to ask a question, write it there, and precede it with 'QUESTION:'. For example:
[18:02] <hggdh>  QUESTION: what does 'hggdh' mean?
[18:02] <hggdh> Let's get into the class now.
[18:02] <hggdh> First, who we are (https://wiki.ubuntu.com/BugSquad)
[18:03] <hggdh> The BugSquad is the team responsible for *triaging* bugs opened against Ubuntu and its packages. The term 'triage' is pretty much taken from medicine --  determining the priority of treatments based on the severity of a condition  (see http://en.wikipedia.org/wiki/Triage).
[18:03] <hggdh> Different from medical triage, though, we do not expect human death as a consequence of delayed treatment.
[18:04] <hggdh> But we still need to triage: there are many more bugs than triagers; we have to be able to prioritise the bugs; we _should_ be able to address _all_ bugs eventually.
[18:05] <hggdh> For us, then, triage is the process of analysing a bug, collecting enough data to completely describe it, marking the bug 'Triaged', and give it an importance.
[18:05] <hggdh> Triage ends there -- it is not our responsibility to *solve* the bug: once the issue is identified, and all necessary and sufficient documentation has been added to the bug, triaging *ENDS*, and the bug goes on to a developer/maintainer to be worked on.
[18:06] <ClassBot> sebsebseb asked: Why do Ubuntu developers hardly ever, if ever,  fix upstream bugs?
[18:07] <hggdh> We do... ideally our corrections/patches should be submitted to the upstream for analysis and acceptance. Sometime, though, we do not have the time or expertise to deal with it
[18:07] <hggdh> and we, then, rely on upstream's knowledge to solve it
[18:09] <hggdh> also, a lot of times we end up submitting our fixes upstream without any indication it was fixed by Ubuntu contributors -- which causes others to think we do nothing :-(
[18:09] <hggdh> sebsebseb,  did it help?
[18:10] <hggdh> Back to the class: Again: triaging *ends* when a bug status is set to Triaged (see https://wiki.ubuntu.com/Bugs/Status).
[18:10] <hggdh> This does not mean we do not solve bugs ourselves. Most of us wear a lot of hats, on (possibly) more than one project. But _triaging_ ends when the bug is set to Triaged.
[18:10] <hggdh> sebsebseb, ^heh ;-)
[18:11] <hggdh> Now, another important point is being able to differentiate between bugs (errors in a programme/package) and support issues (how to use a programme/package, how to set up something). We only deal with *bugs*.
[18:11] <hggdh> Support requests should be redirected to one of the appropriate fora: http://askubuntu.com/, https://answers.launchpad.net/, http://ubuntuforums.org/, an appropriate IRC channel, etc.
[18:11] <ClassBot> jledbetter asked: Can anyone triage? Say, for example, I see a bug that is new can I -- random user -- 'confirm' it? Anything I can do to help?
[18:12] <hggdh> yes, anyone can help (and we *do* hope we will have help)
[18:13] <hggdh> if one can confirm a bug -- exact same scenario, reproduced/reproducible, then marking the bug confirmed will help
[18:13] <hggdh> also, please add a comment stating how you reached the conclusion that you could confirm
[18:14] <hggdh> With that in mind...
[18:14] <hggdh> DO: follow the advices and recommendations from jledbetter's class (that just ended): they can be used not only for finding more about your own issues, but *ALSO* for triaging somebody else's bugs.
[18:15] <hggdh> DO: read https://wiki.ubuntu.com/BugSquad/KnowledgeBase. Really. No kidding.
[18:15] <hggdh> These pages give us a summary of all we learned during all the time we worked on triaging, what can be done, etc
[18:16] <hggdh> DO: read the Code of Conduct (http://www.ubuntu.com/community/conduct).  A nice exposition of the CoC is also at https://wiki.ubuntu.com/CodeOfConductGuidelines.
[18:16] <hggdh> (if you wish to be a member of the BugSquad, we require that you sign it.)
[18:17] <hggdh> This -- the CoC -- is perhaps the major difference between Ubuntu and other projects: we try very hard to live by it. *NOT* signing it does not free one from been required to be civil. So...
[18:18] <hggdh> DO: be nice. Say 'please', and 'thank you'. It does help, a lot. Follow the Golden Rule (http://en.wikipedia.org/wiki/The_Golden_Rule), *always*.
[18:19] <hggdh> DO: keep in mind that English is the official language on https://bugs.launchpad.net, but _many_ UBuntu bug reporters are *not* native speakers of English. This means that many times we will get bugs that are badly written in English (or not in English at all).
[18:20] <hggdh> DO: Try to understand. Ask for someone else to translate it if you do not speak (er, read) the language (hint: the #ubuntu-translators and #ubuntu-bug channels will probably have someone able to translate). Be nice -- always. "I cannot understand you" is, most of the times, *not* nice ;-)
[18:21] <hggdh> But, if you really cannot understand state something like: "I am sorry, but I cannot understand <whatever>, could you please expand on yadda yadda and so on?"
[18:22] <hggdh> (notice the "I am sorry", "please", etc)
[18:22] <hggdh> Of course, "I am sorry, but you are an <expletive> " does NOT do the trick.
[18:23] <hggdh> DO: ask for help on how to deal with a bug if you are unsure. Nobody knows it all, and we all started ignorant on bug triaging (and, pretty much, on everything else ;-). We have a mailing list (Ubuntu-bugsquad@lists.ubuntu.com), and we are always at the #ubuntu-bugs channel on freenode.
[18:24] <hggdh> We will be more than happy to help out on procedures and requirements.
[18:24] <hggdh> Please note that we do not _triage_ bugs there -- we will answer and help on procedures and requirements. We will, though, point out deficiencies and missing data, and suggest actions.
[18:25] <hggdh> DO: _understand_ the problem. A lot of times we see a bug where a _consequence_ is described, but not the _cause_. The triager should do her/his best to understand which is which, and act accordingly. This may mean changing the bug's package, or rewriting the description, etc.
[18:26] <hggdh> But... if we do not understand what is the problem, then how can we correct it?
[18:26] <hggdh> There are many ways to do that; most will require learning ;-)
[18:27] <hggdh> most, also have never been really ported/adapted to computing (differential diagnosis -- medicine --, fault trees -- nuclear reactors, rockets --, etc). So... right now, the best way is to learn more. To keep on learning. With time you will be able to _intuitively_ see a consequence.
[18:27] <hggdh> -> keep in mind that *correlation is not causation* (see http://en.wikipedia.org/wiki/Correlation_does_not_imply_causation).
[18:28] <hggdh> DO: Try to ask and find answers for some questions: WHAT did happen? WHY did it happen? WHICH COMPONENTS are involved? HOW did it happen? HOW can it be REPEATED? What has CHANGED (if it worked before)?
[18:29] <hggdh> So... you go on, aks the questions you fell pertinent, change the bug status (to Incomplete/New/Confirmed/Whatever). Now:
[18:30] <hggdh> DO: add a comment on every action you take on the bug (changing status, importance, package, etc). Although for you it may be crystal-clear the reasons for taking an action, this may not be true for others (in fact, a lot of times it is not clear, at all...).
[18:30] <hggdh> On the other hand...
[18:30] <hggdh> DO NOT: add comments like "me too", "I also have it", "also a problem here", etc. These comments just pollute the bug, making it more difficult to find out what happened, where we are, and what is the next step.  INSTEAD:
[18:31] <hggdh> DO: just mark the bug as "affects me too" (and subscribe to it, if you wish to know when the issue is resolved).
[18:32] <hggdh> DO: if you are starting on triage, browse the open bugs (there are about 80,000 of them) and look for one you feel _comfortable_ with (or less uncomfortable ;-). Ideally, you should be able to reproduce it. It does help if you start with bugs on packages you yourself use.
[18:32] <hggdh> And
[18:33] <hggdh> DO: get on to #ubuntu-bugs, and ask for help there when in doubt. We do not bite... :-)
[18:33] <hggdh> Oh, since we are here:
[18:33] <hggdh> DO NOT: change a Triaged bug to New/Incomplete/Confirmed -- a triaged bug is OUT OF SCOPE for triaging. It is not our problem anymore (while wearing the triager's hat).
[18:34] <hggdh> (or course, if I am the developer/maintainer of a package affected by a bug, I can move it out of Triaged if I understand the bug is missing critical data)
[18:35] <hggdh> DO NOT: assign yourself (or any other person) to a bug. Bug assignment is a clear, official, signal that "the assignee is actively working on resolving this issue". Nobody else -- including the developers/maintainers -- will touch this bug anymore. Instead...
[18:35] <hggdh> DO: so... if you are triaging, and have asked a question/requested action from the OP (Original Poster), *subscribe* to the bug. Nothing is worse than a fire-and-forget action.
[18:36] <hggdh> DO NOT: confirm your own bugs. The fact that you see/experience a bug does not necessarily _make_ it a real bug. It may be something on your setup...
[18:36] <hggdh> DO: follow suggested actions. For some packages we have more detailed 'howtos'. These are described under the https://wiki.ubuntu.com/DebuggingProcedures page. It is always a good idea to check them (and update/correct as needed).
[18:37] <hggdh> Now, a lot of the packages we offer on Ubuntu come from different projects -- Debian, Gnome, GNU, etc. We call these projects -- where real development usually takes place -- "upstream". By the same reasoning, we say we are "downstream" from them.
[18:37] <hggdh> The ideal scenario is we have our packages identical to what upstream provide, no local patches (except, probably, for packaging details).
[18:38] <hggdh> Having local changes increases the delta (the difference between what we provide and what upstream provides), and makes updates/upgrades more costly. So our patches, ideally, should be provided to the upstream project, and discussed there (and hopefully accepted).
[18:39] <hggdh> Bugs affecting upstream projects have to be communicated upstream. This usually means doing a similar triage as we do here for a specific upstream (looking for an identical bug on the upstream project, and opening one if none is found). So.
[18:40] <hggdh> DO: Look upstream, and open a new bug if needed; then *link* this upstream bug to ours (and ours to theirs).
[18:40] <hggdh> For example, for Gnome applications, the upstream BTS (Bug Tracking System) is at http://bugzilla.gnome.org.
[18:41] <hggdh> Many upstreams have different rules on how to open/work with/close a bug. Ergo,
[18:42] <hggdh> DO: follow upstream's processes when working upstream (in an old saying, "when you enter a community, abide by its laws").
[18:43] <hggdh> Please note that this goes hand-in-hand with the CoC/Golden Rule. The fact that (in my original country) I could get to the beach wearing a speedo, does not make it nice (or even accepted) in the US (where I live).
[18:44] <ClassBot> autif asked: absolutely silly question, bust asking just because you have not covered it in your chat - what bugs are you talking about - Ubuntu bugs? Do they include other derivatives like xubuntu, kubuntu etc? Where are the stored?
[18:45] <hggdh> I am talking primarily about Ubuntu bugs; but, of course, all official Ubuntu derivatives (i.e., those that have the BTS on https://launchpad.net) would be dealt in the same way
[18:46] <hggdh> this applies, for example, to Xubuntu, Mythbuntu, Kubuntu, etc. But some of those derivatives may have their own particular way of dealing with bugs
[18:47] <hggdh> IIRC, for a while (at least) Kubuntu suggested opening K* bugs directly upstream.
[18:48] <hggdh> But, even if they have special procedures, all I am stating here still applies in *full*. These DO/DONOT are really generic
[18:49] <hggdh> Any other questions? I am almost done...
[18:50] <hggdh> autif -- for some of the derivatives, you "assign" a bug to it by adding the project to the bug (for example, with Mythbuntu)
[18:50] <ClassBot> IdleOne asked: IF we are affected by a bug that has been open for a long time and there doesn't seem to be any work going on with it, what can we do?
[18:51] <ClassBot> There are 10 minutes remaining in the current session.
[18:51] <hggdh> First, the short answer: *help*
[18:51] <hggdh> Now, the longer one:
[18:52] <hggdh> there are many more bugs than there are triagers. We need all help we can get. So, triaging an old bug (even if on self-interest) _still_ helps
[18:52] <hggdh> checking upstream, opening upstream, etc. Confirming it is still present on the current Development/ or last published Stable release helps
[18:53] <hggdh> but, please not something like "I am tired of waiting for you slackers to get this resolved"
[18:53] <hggdh> This will not really help. No real new data, confirmation it still happens, etc.
[18:54] <hggdh> and indeed, a comment on a bug will bring it back up to those subscribed to it (I, for example, subscribe to all server packages)
[18:54] <hggdh> and there was a old one that has just being brought back to my attention this way
[18:55] <hggdh> with this said, and no more questions...
[18:55] <hggdh> Thank you. I am glad you were here, and I hope you help us out. And we are always (er, at least there is always someone logged it, we also have a life) available to help and discuss triaging work.
[18:56] <ClassBot> There are 5 minutes remaining in the current session.
[19:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2010/10/15/%23ubuntu-classroom.html
[19:03] <sebsebseb> Well no feedback session this time, so I want to provide some here :)  I enjoyed the sessions I asked questions in (more than one).  Accessability, Ubuntu in Education, Have you tried turning it off and on again, I also found very good.  Seemed we had a lack of people this time, so lack of questions for some of the sessions, which was ashame.
[19:04] <pleia2> sebsebseb: there is a survey floating around, care to fill that out?
[19:04] <akgraner> sebsebseb, thank you for your feed back - but can you fill this out as well - http://www.surveymonkey.com/s/GBSK33S
[19:04] <sebsebseb> pleia2: I know there is, but I don't want to fill that in as such.
[19:04] <hggdh> slacker... ;-)
[19:04] <sebsebseb> akgraner: I might
[19:04] <akgraner> it's only 10 questions and it will ensure all those involved will get your feedback
[19:05] <pleia2> well, it would help us a lot if you did, it's hard to process a lot of people tossing suggestions are way :)
[19:05] <pleia2> surveys++
[19:05] <akgraner> sebsebseb, and everyone else who participated this week - thanks in advance for taking time to fill out the survey...  Much appreciated!
[19:06] <sebsebseb> akgraner: you highlighted me with that, was that the idea?
[19:06] <sebsebseb> ah I see
[19:06] <sebsebseb> now
[19:06] <akgraner> thanks everyone till next Ubuntu Week :-)
[19:07] <charlie-tca> akgraner: thanks for setting this up
[19:07] <sebsebseb> akgraner: well theres user days coming up before then I guess :)
[19:07] <sebsebseb> pleia2: When is user days likely to be by the way?
[19:07] <pleia2> probably january
[19:08] <sebsebseb> pleia2: yeah every three months or so isn't it?
[19:08] <pleia2> november and december just get too hard with all the holidays in the US
[19:08] <sebsebseb> every three months after a release or something like that, isn't it?
[19:08] <pleia2> it's variable, we're shooting for once per cycle though
[19:08] <sebsebseb> ok :)
[19:11] <sebsebseb> akgraner: i'll second charlie-tca thanks for setting this up
[19:13] <akgraner> Thanks! I just helped  - :-)  Many thanks also need to go to jcastro, nhandler, nigelb, pleia2, Pendulum and the rest of the Classroom and Community teams.
[19:14] <sebsebseb> akgraner: also I obviously look forward to the next Open Week and User Days :)
[19:14] <akgraner> as do I :-)
[19:14] <akgraner> gotta run - catch everyone later
[19:14] <sebsebseb> akgraner: ok  bye bye
[19:15] <jcastro> \o/
[19:15] <jcastro> great job akgraner
[19:16] <sebsebseb> Yep thanks for setting up Open Week people who did that,  plus to those that ran the sessions :)
[19:17] <charlie-tca> thank you to all the people who set this week up. You put in a lot of work, and it is appreciated!
[19:18] <sebsebseb> pleia2: uh ok I think i'll fill in the survey this time
[19:18] <pleia2> thank you :)
[19:19] <sebsebseb> pleia2: aimed at me I assume,  anyway I can skip most of it :D
[19:20] <pleia2> well, anyone really who was wondering about whether they should ;)
[19:21] <sebsebseb> I mean I don't  need to fill in session speaker stuff, since didn't do that.
[21:01] <jledbetter> pleia2: What are all the different days/weeks? Developer Week? App Developer Week? User Day(s)? Open Week?
[21:05] <akgraner> jledbetter, Ubuntu Developer Week, Ubuntu App Developer Week, Ubuntu Open Week, Ubuntu User Days, Ubuntu LoCo days
[21:06] <jledbetter> akgraner: Is there a list of them with schedule? I don't remember LoCo days.
[21:06] <akgraner> Various Packaging Days, Kernel Triage Summits and other classes as people some up with ideas
[21:06] <akgraner> yep one secv
[21:06] <akgraner> sec
[21:07] <akgraner> jledbetter, as they are scheduled they will show up on this Calendar - http://ubuntu-news.org/calendars/classroom/
[21:07] <jledbetter> I saw something on the learning fridge? calendar that said a python session is this weekend but it's part 5 or somesuch.
[21:07] <akgraner> yep
[21:07] <jledbetter> Ah ok. Thanks :) But what /are/ LoCo days?
[21:20] <akgraner> jledbetter, they are new ones so I am not exactly sure let me get you the wiki page link
[21:21] <sebsebseb> akgraner: About to submit the survey
[21:21] <akgraner> sebsebseb, thanks!
[21:21] <akgraner> jledbetter, https://wiki.ubuntu.com/Classroom  it's not on here yet but I am sure it will be soon - if the LoCo days are still a go
[21:23] <jledbetter> akgraner: Understood. Thank you :)
[21:36] <serfus> akgraner, jcastro and everyone else who were involved in this week - great job! i learned allot. so thank you and keep up the good work :)
[21:36] <akgraner> thank you!
[21:38] <jcastro> it was mostly akgraner and the rest of the -classroom team!
[21:40] <akgraner> jcastro, is our safety net
[21:58] <sebsebseb> akgraner: Ok submitted, took me a little longer than planned, since  editing text and so on, but yep done.
[22:00] <jledbetter> akgraner: Do the session leaders get feedback from the surveys?
[22:01] <sebsebseb> jledbetter: apparently so
[22:03] <jledbetter> sebsebseb: Great!
[22:05] <sebsebseb> jledbetter: Hope they liked my survey response,  pretty good feedback I did I think,  plus said who it was from, even though I didn't have to.
[22:07] <jledbetter> sebsebseb: Great. :) Thank you. I know I love feedback.
[22:13] <sebsebseb> Oh something I didn't mention in the survey is that Open Week should probably be advertised better next time, so more people turn up,  using #ubuntu would be one way to do it.