From noreply at ubuntu.com Sat Nov 2 07:02:55 2013 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Sat, 02 Nov 2013 07:02:55 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22DebuggingTouchpadDetection=22_by?= =?utf-8?q?_penalvch?= Message-ID: <20131102070255.23211.44376@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "DebuggingTouchpadDetection" page has been changed by penalvch: http://wiki.ubuntu.com/DebuggingTouchpadDetection?action=diff&rev1=36&rev2=37 Comment: RM'ed = Known bugs = section as they are all Fixed Released and are a point of confusion for original reporters (ex. LP#1188965). ↳ TouchPad id=6 [slave pointer (2)] }}} Then, type: {{{ xinput --list-props 6 }}} - = Known bugs = - - *[[https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/308191|Synaptics Touchpad Multitouch]] - *[[https://bugs.edge.launchpad.net/xorg-driver-synaptics/+bug/365943|Jumpy cursor]] - *[[https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/565543|Synaptics Touchpad is incorrectly detected by kernel]] - * [[https://bugs.launchpad.net/ubuntu/+source/linux/+bug/565543|AlPS touchpad misdetected as PS/2 mouse in sony VAIO E series and some ACER laptops]] - ---- CategoryBugSquad CategoryDebugging CategoryCleanup From jff at jff-webhosting.net Mon Nov 4 13:31:04 2013 From: jff at jff-webhosting.net (=?ISO-8859-1?Q?J=F6rg_Frings-F=FCrst?=) Date: Mon, 04 Nov 2013 14:31:04 +0100 Subject: Thanks Message-ID: <1383571864.6573.7.camel@merkur> Hi, thank you for membership in the team. To a good cooperation with you .. Jörg PS. Sorry for my bad english. Its a little bit "rusty". -- Jörg Frings-Fürst Friedhofstraße 2 54526 Niederkail Tel.: +49 6575 6219054 Fax: +49 6575 6219055 PGP-Fingerprint: 13E3 4D4A 3228 D138 8511 EA5A 08AC AF02 3C6D 750A Key-Server: hkp://keys.gnupg.net ######### S/MINE (X.509) Zertificat von CACert SN 0D:9A:12 SHA1-Fingerprint: 35:DC:C9:EA:4B:38:DA:AB:70:6C:AD:3D:03:B9:4D:A3:EE:2C:EF:43 MD5-Fingerabdruck: 0E:E8:5D:31:84:4D:4B:14:43:E0:C0:38:95:F2:30:DD Verschlüsselte EMails sind gerne gesehen. Ausschlusserklärung: Diese E-Mail nebst Anlagen kann vertrauliche und/oder rechtlich geschützte Informationen enthalten. Der Inhalt dieser E-Mail ist ausschließlich an einen bestimmten Empfänger bzw. Empfängerkreis gerichtet. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte umgehend den Absender der Nachricht. Die Nutzung, das Kopieren sowie die unbefugte Weitergabe dieser E-Mail sind nicht gestattet. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3707 bytes Desc: not available URL: From es20490446e at gmail.com Mon Nov 4 13:40:49 2013 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Mon, 04 Nov 2013 14:40:49 +0100 Subject: Thanks In-Reply-To: <1383571864.6573.7.camel@merkur> References: <1383571864.6573.7.camel@merkur> Message-ID: <5277A3E1.2030607@gmail.com> Thanks to you. El 04/11/13 14:31, Jörg Frings-Fürst escribió: > Hi, > > thank you for membership in the team. > To a good cooperation with you .. > > Jörg > > PS. Sorry for my bad english. Its a little bit "rusty". > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2260 bytes Desc: Firma criptográfica S/MIME URL: From ag.restringere at gmail.com Mon Nov 4 19:03:36 2013 From: ag.restringere at gmail.com (AG Restringere) Date: Mon, 4 Nov 2013 14:03:36 -0500 Subject: A proposal to combine quality and bugsquad teams In-Reply-To: <527154F8.4050309@canonical.com> References: <5268173E.4000104@canonical.com> <20131029163906.GU23498@murraytwins.com> <527154F8.4050309@canonical.com> Message-ID: Hello Q/A and Bug Control teams, This is the first time I post to this list so hello! Because Bug Control is being restructured I was hoping that some of my ideas and experiences could find their way into the blueprint and be discussed at the next UDS: In my experience in - when I dabbled in some bug control work as part of the Ubuntu-X team - the Bug Triage process is still very tedious and lacks sufficient automation. Most of the time and effort I spent doing bug control work was spent browsing Launchpad and reading through hundreds of bug-emails in order to find bugs to work on. Most of my time was spent searching for bugs but very little of my time was spent actively working on bugs and being productive. Also, many times I saw bugs that had comments from Bug Control members but it was never clear who was working on the bug or what they wanted to do with it. This often lead me to add comments when they weren't necessary or not contribute when a bug actually needed attention. As a result I don't think the current process as it stands should be re-introduced into the new combined Q/A and Bug Control as is i without some modifications. Modifications I would make to the Bug Triage process: 1. Assignment and eliminating redundancy: When a Bug Triager begins working on a bug they should assign themselves to the bug on Launchpad if they intend to actively work on it. Only one Bug Triage member should be assigned and actively working on a bug at any given time and they should effectively "own" that bug and be responsible for it. The only other people who should be working on that specific bug should be Reporters, Testers and Developers. Assignment would help other Bug Triage people to know "this bug is actively owned by another member" and know to move on to other bugs and leave that one alone. It would be even better if Launchpad could filter out the bugs that were actively assigned to Bug Control members so people could find those that nobody was working on and needed attention. Sufficient criteria for finding new bugs could be as simple as "Confirmed"+"Unassigned". I think this sort of assignment scheme makes sense given that the new Bug Control restructuring effort involves making roles very specific and eliminating redundancy. 2. Email volume reduction: Bug Triage members should only receive emails about bugs they're actively assigned to. It's really time consuming to sort through hundreds of bug-mails that involve bugs that are not relevant to ones currently being worked on. This applies to all roles such as Testers, Reporters and others as well. The only general emails that should be received should be from the discussion or developer mailing lists. 3. Auto-assignment process queue: Similar to a tech-support ticket system the next step in this process would be to introduce a process queue with auto-assignment of bugs to Bug Triage members. I don't know how this would work but some status change in the bug would have to trigger it's submission it into the process queue such as reaching a Confirmed status or increased Reporter activity at some threshold level. The distribution of the bugs would have to take into account the work-load of the Bug Triage members and distribute them evenly but perhaps that's a bit too complicated to do in code. Maybe random assignment would be better or it could based on the package selection preferences of individual members. Perhaps there could even be some senior Bug Control members who would manually assign the bugs from the queue. This would eliminate the need for Bug Triage members to even need to go to Launchpad to search for bugs unless they're doing some extra research. Bugs would be sent to them via email automatically when they're ready to be triaged and auto-assigned without any extra steps needed. Conclusion: If the above steps were implemented or some equivalent processes I think the Bug Triage would be streamlined, eliminate redundancy and get faster turn-around times. Bug Triage members would be more focused and successful. Newer Bug Triage members would be able to be "plugged in" to a standardized process and this would improve retention because people would see results faster with less effort. Hopefully my feedback and comments had some value and will be considered for the upcoming changes to the Bug Control team and it's processes. If there are any other ways I can help the newly combined Q/A and Bug Control please let me know. Thank you for your time and attention. Best regards, AG On Wed, Oct 30, 2013 at 2:50 PM, Nicholas Skaggs < nicholas.skaggs at canonical.com> wrote: > Thanks to everyone for the feedback. Given the positive responses I would > like to move forward with the change. To help facilitate all the little > odds and ends of transitioning, I've created a blueprint for the upcoming > UDS: > > https://blueprints.launchpad.net/ubuntu/+spec/community- > 1311-quality-bugsquad > > We'll discuss how to transition lp teams, responsibilities, documentation > and wiki issues, etc. Please add anything that needs to be discussed to the > whiteboard on the blueprint. Seriously, have at it! Edit away! > > In the interim, please feel free to participate in bugsquad and quality > activities as a member of either team :-) I know several bugsquadders have > introduced themselves to the quality list -- thank you! > > Nicholas > > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ag.restringere at gmail.com Mon Nov 4 20:40:12 2013 From: ag.restringere at gmail.com (AG Restringere) Date: Mon, 4 Nov 2013 15:40:12 -0500 Subject: A proposal to combine quality and bugsquad teams In-Reply-To: <38E7A34A-1C1D-4C60-B919-009AC8F0F392@trekweb.org> References: <5268173E.4000104@canonical.com> <20131029163906.GU23498@murraytwins.com> <527154F8.4050309@canonical.com> <38E7A34A-1C1D-4C60-B919-009AC8F0F392@trekweb.org> Message-ID: Thomas, Thank you for the information. I was previously unaware that they were two separate groups. In that case where should I direct this feedback to improve Bug Triage processes and what are the next steps I should take? Best regards, AG On Mon, Nov 4, 2013 at 3:19 PM, Thomas Ward wrote: > Ummm... I may be nitpicking but this is important... I think you're > confusing Bug Squad with Bug Control, AG... > > In my discussions with Nicholas on IRC, we discussed the separation of Bug > Squad and Bug Control. Bug Squad has no specific rules to be a member. It > also does not give any special bug permissions to an individual. > > Bug Control is a separate group with a specific application procedure and > has more permissions with bugs. Given that, I had mentioned with Nicholas > about the distinction and it was generally agreed that Bug Control would be > left alone and separate from this 'merging' of Bug Squad and QA. > > Unless I missed further discussion on this, which would probably have > landed on the Bug Control mailing list, that 'general understanding' still > stood strong... > > (I want to make sure that you understand the distinction there, AG, that > Bug Squad and Bug Control are different groups all bound to the same > trialling rules, but with substantially different permission sets and > application procedures.) > > On Nov 4, 2013, at 2:03 PM, AG Restringere > wrote: > > Hello Q/A and Bug Control teams, > > This is the first time I post to this list so hello! > > Because Bug Control is being restructured I was hoping that some of my > ideas and experiences could find their way into the blueprint and be > discussed at the next UDS: > > In my experience in - when I dabbled in some bug control work as part of > the Ubuntu-X team - the Bug Triage process is still very tedious and lacks > sufficient automation. Most of the time and effort I spent doing bug > control work was spent browsing Launchpad and reading through hundreds of > bug-emails in order to find bugs to work on. Most of my time was spent > searching for bugs but very little of my time was spent actively working on > bugs and being productive. Also, many times I saw bugs that had comments > from Bug Control members but it was never clear who was working on the bug > or what they wanted to do with it. This often lead me to add comments when > they weren't necessary or not contribute when a bug actually needed > attention. As a result I don't think the current process as it stands > should be re-introduced into the new combined Q/A and Bug Control as is i > without some modifications. > > Modifications I would make to the Bug Triage process: > > 1. Assignment and eliminating redundancy: > > When a Bug Triager begins working on a bug they should assign themselves > to the bug on Launchpad if they intend to actively work on it. Only one > Bug Triage member should be assigned and actively working on a bug at any > given time and they should effectively "own" that bug and be responsible > for it. The only other people who should be working on that specific bug > should be Reporters, Testers and Developers. Assignment would help other > Bug Triage people to know "this bug is actively owned by another member" > and know to move on to other bugs and leave that one alone. It would be > even better if Launchpad could filter out the bugs that were actively > assigned to Bug Control members so people could find those that nobody was > working on and needed attention. Sufficient criteria for finding new bugs > could be as simple as "Confirmed"+"Unassigned". I think this sort of > assignment scheme makes sense given that the new Bug Control restructuring > effort involves making roles very specific and eliminating redundancy. > > 2. Email volume reduction: > > Bug Triage members should only receive emails about bugs they're actively > assigned to. It's really time consuming to sort through hundreds of > bug-mails that involve bugs that are not relevant to ones currently being > worked on. This applies to all roles such as Testers, Reporters and others > as well. The only general emails that should be received should be from > the discussion or developer mailing lists. > > 3. Auto-assignment process queue: > > Similar to a tech-support ticket system the next step in this process > would be to introduce a process queue with auto-assignment of bugs to Bug > Triage members. I don't know how this would work but some status change in > the bug would have to trigger it's submission it into the process queue > such as reaching a Confirmed status or increased Reporter activity at some > threshold level. The distribution of the bugs would have to take into > account the work-load of the Bug Triage members and distribute them evenly > but perhaps that's a bit too complicated to do in code. Maybe random > assignment would be better or it could based on the package selection > preferences of individual members. Perhaps there could even be some senior > Bug Control members who would manually assign the bugs from the queue. > This would eliminate the need for Bug Triage members to even need to go to > Launchpad to search for bugs unless they're doing some extra research. > Bugs would be sent to them via email automatically when they're ready to > be triaged and auto-assigned without any extra steps needed. > > Conclusion: > > If the above steps were implemented or some equivalent processes I think > the Bug Triage would be streamlined, eliminate redundancy and get faster > turn-around times. Bug Triage members would be more focused and > successful. Newer Bug Triage members would be able to be "plugged in" to a > standardized process and this would improve retention because people would > see results faster with less effort. > > Hopefully my feedback and comments had some value and will be considered > for the upcoming changes to the Bug Control team and it's processes. If > there are any other ways I can help the newly combined Q/A and Bug Control > please let me know. Thank you for your time and attention. > > Best regards, > AG > > > > > > > > On Wed, Oct 30, 2013 at 2:50 PM, Nicholas Skaggs < > nicholas.skaggs at canonical.com> wrote: > >> Thanks to everyone for the feedback. Given the positive responses I would >> like to move forward with the change. To help facilitate all the little >> odds and ends of transitioning, I've created a blueprint for the upcoming >> UDS: >> >> https://blueprints.launchpad.net/ubuntu/+spec/community- >> 1311-quality-bugsquad >> >> We'll discuss how to transition lp teams, responsibilities, documentation >> and wiki issues, etc. Please add anything that needs to be discussed to the >> whiteboard on the blueprint. Seriously, have at it! Edit away! >> >> In the interim, please feel free to participate in bugsquad and quality >> activities as a member of either team :-) I know several bugsquadders have >> introduced themselves to the quality list -- thank you! >> >> Nicholas >> >> >> -- >> Ubuntu-bugsquad mailing list >> Ubuntu-bugsquad at lists.ubuntu.com >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad >> > > -- > Ubuntu-quality mailing list > Ubuntu-quality at lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at ubuntu.com Sun Nov 3 22:02:08 2013 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Sun, 03 Nov 2013 22:02:08 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Kernel/Debugging/Backlight=22_by?= =?utf-8?q?_penalvch?= Message-ID: <20131103220208.12746.59497@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "Kernel/Debugging/Backlight" page has been changed by penalvch: http://wiki.ubuntu.com/Kernel/Debugging/Backlight?action=diff&rev1=23&rev2=24 Comment: Due to LP#1159771 and others, clarified this article is for debugging backlight not working by default, not after a suspend/hibernate. <> ||<>|| + + If you have an issue where backlight stops working after suspend or hibernation, please see their respective debugging article. Otherwise, please continue with the below mentioned information. There are a lot of different issues with backlight control which can be generally put into these classes: From teward at trekweb.org Mon Nov 4 20:19:25 2013 From: teward at trekweb.org (Thomas Ward) Date: Mon, 4 Nov 2013 15:19:25 -0500 Subject: A proposal to combine quality and bugsquad teams In-Reply-To: References: <5268173E.4000104@canonical.com> <20131029163906.GU23498@murraytwins.com> <527154F8.4050309@canonical.com> Message-ID: <38E7A34A-1C1D-4C60-B919-009AC8F0F392@trekweb.org> Ummm... I may be nitpicking but this is important... I think you're confusing Bug Squad with Bug Control, AG... In my discussions with Nicholas on IRC, we discussed the separation of Bug Squad and Bug Control. Bug Squad has no specific rules to be a member. It also does not give any special bug permissions to an individual. Bug Control is a separate group with a specific application procedure and has more permissions with bugs. Given that, I had mentioned with Nicholas about the distinction and it was generally agreed that Bug Control would be left alone and separate from this 'merging' of Bug Squad and QA. Unless I missed further discussion on this, which would probably have landed on the Bug Control mailing list, that 'general understanding' still stood strong... (I want to make sure that you understand the distinction there, AG, that Bug Squad and Bug Control are different groups all bound to the same trialling rules, but with substantially different permission sets and application procedures.) > On Nov 4, 2013, at 2:03 PM, AG Restringere wrote: > > Hello Q/A and Bug Control teams, > > This is the first time I post to this list so hello! > > Because Bug Control is being restructured I was hoping that some of my ideas and experiences could find their way into the blueprint and be discussed at the next UDS: > > In my experience in - when I dabbled in some bug control work as part of the Ubuntu-X team - the Bug Triage process is still very tedious and lacks sufficient automation. Most of the time and effort I spent doing bug control work was spent browsing Launchpad and reading through hundreds of bug-emails in order to find bugs to work on. Most of my time was spent searching for bugs but very little of my time was spent actively working on bugs and being productive. Also, many times I saw bugs that had comments from Bug Control members but it was never clear who was working on the bug or what they wanted to do with it. This often lead me to add comments when they weren't necessary or not contribute when a bug actually needed attention. As a result I don't think the current process as it stands should be re-introduced into the new combined Q/A and Bug Control as is i without some modifications. > > Modifications I would make to the Bug Triage process: > > 1. Assignment and eliminating redundancy: > > When a Bug Triager begins working on a bug they should assign themselves to the bug on Launchpad if they intend to actively work on it. Only one Bug Triage member should be assigned and actively working on a bug at any given time and they should effectively "own" that bug and be responsible for it. The only other people who should be working on that specific bug should be Reporters, Testers and Developers. Assignment would help other Bug Triage people to know "this bug is actively owned by another member" and know to move on to other bugs and leave that one alone. It would be even better if Launchpad could filter out the bugs that were actively assigned to Bug Control members so people could find those that nobody was working on and needed attention. Sufficient criteria for finding new bugs could be as simple as "Confirmed"+"Unassigned". I think this sort of assignment scheme makes sense given that the new Bug Control restructuring effort involves making roles very specific and eliminating redundancy. > > 2. Email volume reduction: > > Bug Triage members should only receive emails about bugs they're actively assigned to. It's really time consuming to sort through hundreds of bug-mails that involve bugs that are not relevant to ones currently being worked on. This applies to all roles such as Testers, Reporters and others as well. The only general emails that should be received should be from the discussion or developer mailing lists. > > 3. Auto-assignment process queue: > > Similar to a tech-support ticket system the next step in this process would be to introduce a process queue with auto-assignment of bugs to Bug Triage members. I don't know how this would work but some status change in the bug would have to trigger it's submission it into the process queue such as reaching a Confirmed status or increased Reporter activity at some threshold level. The distribution of the bugs would have to take into account the work-load of the Bug Triage members and distribute them evenly but perhaps that's a bit too complicated to do in code. Maybe random assignment would be better or it could based on the package selection preferences of individual members. Perhaps there could even be some senior Bug Control members who would manually assign the bugs from the queue. This would eliminate the need for Bug Triage members to even need to go to Launchpad to search for bugs unless they're doing some extra research. Bugs would be sent to them via email automatically when they're ready to be triaged and auto-assigned without any extra steps needed. > > Conclusion: > > If the above steps were implemented or some equivalent processes I think the Bug Triage would be streamlined, eliminate redundancy and get faster turn-around times. Bug Triage members would be more focused and successful. Newer Bug Triage members would be able to be "plugged in" to a standardized process and this would improve retention because people would see results faster with less effort. > > Hopefully my feedback and comments had some value and will be considered for the upcoming changes to the Bug Control team and it's processes. If there are any other ways I can help the newly combined Q/A and Bug Control please let me know. Thank you for your time and attention. > > Best regards, > AG > > > > > > > >> On Wed, Oct 30, 2013 at 2:50 PM, Nicholas Skaggs wrote: >> Thanks to everyone for the feedback. Given the positive responses I would like to move forward with the change. To help facilitate all the little odds and ends of transitioning, I've created a blueprint for the upcoming UDS: >> >> https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-bugsquad >> >> We'll discuss how to transition lp teams, responsibilities, documentation and wiki issues, etc. Please add anything that needs to be discussed to the whiteboard on the blueprint. Seriously, have at it! Edit away! >> >> In the interim, please feel free to participate in bugsquad and quality activities as a member of either team :-) I know several bugsquadders have introduced themselves to the quality list -- thank you! >> >> Nicholas >> >> >> -- >> Ubuntu-bugsquad mailing list >> Ubuntu-bugsquad at lists.ubuntu.com >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > -- > Ubuntu-quality mailing list > Ubuntu-quality at lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2326 bytes Desc: not available URL: From teward at ubuntu.com Mon Nov 4 20:43:33 2013 From: teward at ubuntu.com (Thomas Ward) Date: Mon, 4 Nov 2013 15:43:33 -0500 Subject: A proposal to combine quality and bugsquad teams In-Reply-To: References: <5268173E.4000104@canonical.com> <20131029163906.GU23498@murraytwins.com> <527154F8.4050309@canonical.com> <38E7A34A-1C1D-4C60-B919-009AC8F0F392@trekweb.org> Message-ID: AG, You are correct in proposing triage procedures here to the Bug Squad mailing list, but that should be made as a separate thread, in my opinion. As it stands, the bug squad and QA are still separate right now, but ultimately any changes in triage procedure affect every group working with Ubuntu bugs, including the Server Team. Bug Control and Bug Squad work collectively on triage procedures, and the people in charge of bug triage (namely the bug god, Brian) do look at recommendations, so I recommend splitting your suggestions off the chain for the QA/BugSquad merger discussion and into its own thread on the bugsquad mailing list for now. ----- Thomas On Mon, Nov 4, 2013 at 3:40 PM, AG Restringere wrote: > Thomas, > > Thank you for the information. I was previously unaware that they were two > separate groups. In that case where should I direct this feedback to improve > Bug Triage processes and what are the next steps I should take? > > Best regards, > AG > > > On Mon, Nov 4, 2013 at 3:19 PM, Thomas Ward wrote: >> >> Ummm... I may be nitpicking but this is important... I think you're >> confusing Bug Squad with Bug Control, AG... >> >> In my discussions with Nicholas on IRC, we discussed the separation of Bug >> Squad and Bug Control. Bug Squad has no specific rules to be a member. It >> also does not give any special bug permissions to an individual. >> >> Bug Control is a separate group with a specific application procedure and >> has more permissions with bugs. Given that, I had mentioned with Nicholas >> about the distinction and it was generally agreed that Bug Control would be >> left alone and separate from this 'merging' of Bug Squad and QA. >> >> Unless I missed further discussion on this, which would probably have >> landed on the Bug Control mailing list, that 'general understanding' still >> stood strong... >> >> (I want to make sure that you understand the distinction there, AG, that >> Bug Squad and Bug Control are different groups all bound to the same >> trialling rules, but with substantially different permission sets and >> application procedures.) >> >> On Nov 4, 2013, at 2:03 PM, AG Restringere >> wrote: >> >> Hello Q/A and Bug Control teams, >> >> This is the first time I post to this list so hello! >> >> Because Bug Control is being restructured I was hoping that some of my >> ideas and experiences could find their way into the blueprint and be >> discussed at the next UDS: >> >> In my experience in - when I dabbled in some bug control work as part of >> the Ubuntu-X team - the Bug Triage process is still very tedious and lacks >> sufficient automation. Most of the time and effort I spent doing bug control >> work was spent browsing Launchpad and reading through hundreds of bug-emails >> in order to find bugs to work on. Most of my time was spent searching for >> bugs but very little of my time was spent actively working on bugs and being >> productive. Also, many times I saw bugs that had comments from Bug Control >> members but it was never clear who was working on the bug or what they >> wanted to do with it. This often lead me to add comments when they weren't >> necessary or not contribute when a bug actually needed attention. As a >> result I don't think the current process as it stands should be >> re-introduced into the new combined Q/A and Bug Control as is i without some >> modifications. >> >> Modifications I would make to the Bug Triage process: >> >> 1. Assignment and eliminating redundancy: >> >> When a Bug Triager begins working on a bug they should assign themselves >> to the bug on Launchpad if they intend to actively work on it. Only one Bug >> Triage member should be assigned and actively working on a bug at any given >> time and they should effectively "own" that bug and be responsible for it. >> The only other people who should be working on that specific bug should be >> Reporters, Testers and Developers. Assignment would help other Bug Triage >> people to know "this bug is actively owned by another member" and know to >> move on to other bugs and leave that one alone. It would be even better if >> Launchpad could filter out the bugs that were actively assigned to Bug >> Control members so people could find those that nobody was working on and >> needed attention. Sufficient criteria for finding new bugs could be as >> simple as "Confirmed"+"Unassigned". I think this sort of assignment scheme >> makes sense given that the new Bug Control restructuring effort involves >> making roles very specific and eliminating redundancy. >> >> 2. Email volume reduction: >> >> Bug Triage members should only receive emails about bugs they're actively >> assigned to. It's really time consuming to sort through hundreds of >> bug-mails that involve bugs that are not relevant to ones currently being >> worked on. This applies to all roles such as Testers, Reporters and others >> as well. The only general emails that should be received should be from the >> discussion or developer mailing lists. >> >> 3. Auto-assignment process queue: >> >> Similar to a tech-support ticket system the next step in this process >> would be to introduce a process queue with auto-assignment of bugs to Bug >> Triage members. I don't know how this would work but some status change in >> the bug would have to trigger it's submission it into the process queue such >> as reaching a Confirmed status or increased Reporter activity at some >> threshold level. The distribution of the bugs would have to take into >> account the work-load of the Bug Triage members and distribute them evenly >> but perhaps that's a bit too complicated to do in code. Maybe random >> assignment would be better or it could based on the package selection >> preferences of individual members. Perhaps there could even be some senior >> Bug Control members who would manually assign the bugs from the queue. This >> would eliminate the need for Bug Triage members to even need to go to >> Launchpad to search for bugs unless they're doing some extra research. Bugs >> would be sent to them via email automatically when they're ready to be >> triaged and auto-assigned without any extra steps needed. >> >> Conclusion: >> >> If the above steps were implemented or some equivalent processes I think >> the Bug Triage would be streamlined, eliminate redundancy and get faster >> turn-around times. Bug Triage members would be more focused and successful. >> Newer Bug Triage members would be able to be "plugged in" to a standardized >> process and this would improve retention because people would see results >> faster with less effort. >> >> Hopefully my feedback and comments had some value and will be considered >> for the upcoming changes to the Bug Control team and it's processes. If >> there are any other ways I can help the newly combined Q/A and Bug Control >> please let me know. Thank you for your time and attention. >> >> Best regards, >> AG >> >> >> >> >> >> >> >> On Wed, Oct 30, 2013 at 2:50 PM, Nicholas Skaggs >> wrote: >>> >>> Thanks to everyone for the feedback. Given the positive responses I would >>> like to move forward with the change. To help facilitate all the little odds >>> and ends of transitioning, I've created a blueprint for the upcoming UDS: >>> >>> >>> https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-bugsquad >>> >>> We'll discuss how to transition lp teams, responsibilities, documentation >>> and wiki issues, etc. Please add anything that needs to be discussed to the >>> whiteboard on the blueprint. Seriously, have at it! Edit away! >>> >>> In the interim, please feel free to participate in bugsquad and quality >>> activities as a member of either team :-) I know several bugsquadders have >>> introduced themselves to the quality list -- thank you! >>> >>> Nicholas >>> >>> >>> -- >>> Ubuntu-bugsquad mailing list >>> Ubuntu-bugsquad at lists.ubuntu.com >>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad >> >> >> -- >> Ubuntu-quality mailing list >> Ubuntu-quality at lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality > > From ag.restringere at gmail.com Mon Nov 4 20:46:11 2013 From: ag.restringere at gmail.com (AG Restringere) Date: Mon, 4 Nov 2013 15:46:11 -0500 Subject: A proposal to combine quality and bugsquad teams In-Reply-To: References: <5268173E.4000104@canonical.com> <20131029163906.GU23498@murraytwins.com> <527154F8.4050309@canonical.com> <38E7A34A-1C1D-4C60-B919-009AC8F0F392@trekweb.org> Message-ID: Thomas, Okay, I'll create a separate subject and thread for this...thanks... Best, AG On Mon, Nov 4, 2013 at 3:43 PM, Thomas Ward wrote: > AG, > > You are correct in proposing triage procedures here to the Bug Squad > mailing list, but that should be made as a separate thread, in my > opinion. As it stands, the bug squad and QA are still separate right > now, but ultimately any changes in triage procedure affect every group > working with Ubuntu bugs, including the Server Team. > > Bug Control and Bug Squad work collectively on triage procedures, and > the people in charge of bug triage (namely the bug god, Brian) do look > at recommendations, so I recommend splitting your suggestions off the > chain for the QA/BugSquad merger discussion and into its own thread on > the bugsquad mailing list for now. > > ----- > Thomas > > On Mon, Nov 4, 2013 at 3:40 PM, AG Restringere > wrote: > > Thomas, > > > > Thank you for the information. I was previously unaware that they were > two > > separate groups. In that case where should I direct this feedback to > improve > > Bug Triage processes and what are the next steps I should take? > > > > Best regards, > > AG > > > > > > On Mon, Nov 4, 2013 at 3:19 PM, Thomas Ward wrote: > >> > >> Ummm... I may be nitpicking but this is important... I think you're > >> confusing Bug Squad with Bug Control, AG... > >> > >> In my discussions with Nicholas on IRC, we discussed the separation of > Bug > >> Squad and Bug Control. Bug Squad has no specific rules to be a member. > It > >> also does not give any special bug permissions to an individual. > >> > >> Bug Control is a separate group with a specific application procedure > and > >> has more permissions with bugs. Given that, I had mentioned with > Nicholas > >> about the distinction and it was generally agreed that Bug Control > would be > >> left alone and separate from this 'merging' of Bug Squad and QA. > >> > >> Unless I missed further discussion on this, which would probably have > >> landed on the Bug Control mailing list, that 'general understanding' > still > >> stood strong... > >> > >> (I want to make sure that you understand the distinction there, AG, that > >> Bug Squad and Bug Control are different groups all bound to the same > >> trialling rules, but with substantially different permission sets and > >> application procedures.) > >> > >> On Nov 4, 2013, at 2:03 PM, AG Restringere > >> wrote: > >> > >> Hello Q/A and Bug Control teams, > >> > >> This is the first time I post to this list so hello! > >> > >> Because Bug Control is being restructured I was hoping that some of my > >> ideas and experiences could find their way into the blueprint and be > >> discussed at the next UDS: > >> > >> In my experience in - when I dabbled in some bug control work as part of > >> the Ubuntu-X team - the Bug Triage process is still very tedious and > lacks > >> sufficient automation. Most of the time and effort I spent doing bug > control > >> work was spent browsing Launchpad and reading through hundreds of > bug-emails > >> in order to find bugs to work on. Most of my time was spent searching > for > >> bugs but very little of my time was spent actively working on bugs and > being > >> productive. Also, many times I saw bugs that had comments from Bug > Control > >> members but it was never clear who was working on the bug or what they > >> wanted to do with it. This often lead me to add comments when they > weren't > >> necessary or not contribute when a bug actually needed attention. As a > >> result I don't think the current process as it stands should be > >> re-introduced into the new combined Q/A and Bug Control as is i without > some > >> modifications. > >> > >> Modifications I would make to the Bug Triage process: > >> > >> 1. Assignment and eliminating redundancy: > >> > >> When a Bug Triager begins working on a bug they should assign themselves > >> to the bug on Launchpad if they intend to actively work on it. Only > one Bug > >> Triage member should be assigned and actively working on a bug at any > given > >> time and they should effectively "own" that bug and be responsible for > it. > >> The only other people who should be working on that specific bug should > be > >> Reporters, Testers and Developers. Assignment would help other Bug > Triage > >> people to know "this bug is actively owned by another member" and know > to > >> move on to other bugs and leave that one alone. It would be even > better if > >> Launchpad could filter out the bugs that were actively assigned to Bug > >> Control members so people could find those that nobody was working on > and > >> needed attention. Sufficient criteria for finding new bugs could be as > >> simple as "Confirmed"+"Unassigned". I think this sort of assignment > scheme > >> makes sense given that the new Bug Control restructuring effort involves > >> making roles very specific and eliminating redundancy. > >> > >> 2. Email volume reduction: > >> > >> Bug Triage members should only receive emails about bugs they're > actively > >> assigned to. It's really time consuming to sort through hundreds of > >> bug-mails that involve bugs that are not relevant to ones currently > being > >> worked on. This applies to all roles such as Testers, Reporters and > others > >> as well. The only general emails that should be received should be > from the > >> discussion or developer mailing lists. > >> > >> 3. Auto-assignment process queue: > >> > >> Similar to a tech-support ticket system the next step in this process > >> would be to introduce a process queue with auto-assignment of bugs to > Bug > >> Triage members. I don't know how this would work but some status > change in > >> the bug would have to trigger it's submission it into the process queue > such > >> as reaching a Confirmed status or increased Reporter activity at some > >> threshold level. The distribution of the bugs would have to take into > >> account the work-load of the Bug Triage members and distribute them > evenly > >> but perhaps that's a bit too complicated to do in code. Maybe random > >> assignment would be better or it could based on the package selection > >> preferences of individual members. Perhaps there could even be some > senior > >> Bug Control members who would manually assign the bugs from the queue. > This > >> would eliminate the need for Bug Triage members to even need to go to > >> Launchpad to search for bugs unless they're doing some extra research. > Bugs > >> would be sent to them via email automatically when they're ready to be > >> triaged and auto-assigned without any extra steps needed. > >> > >> Conclusion: > >> > >> If the above steps were implemented or some equivalent processes I think > >> the Bug Triage would be streamlined, eliminate redundancy and get faster > >> turn-around times. Bug Triage members would be more focused and > successful. > >> Newer Bug Triage members would be able to be "plugged in" to a > standardized > >> process and this would improve retention because people would see > results > >> faster with less effort. > >> > >> Hopefully my feedback and comments had some value and will be considered > >> for the upcoming changes to the Bug Control team and it's processes. If > >> there are any other ways I can help the newly combined Q/A and Bug > Control > >> please let me know. Thank you for your time and attention. > >> > >> Best regards, > >> AG > >> > >> > >> > >> > >> > >> > >> > >> On Wed, Oct 30, 2013 at 2:50 PM, Nicholas Skaggs > >> wrote: > >>> > >>> Thanks to everyone for the feedback. Given the positive responses I > would > >>> like to move forward with the change. To help facilitate all the > little odds > >>> and ends of transitioning, I've created a blueprint for the upcoming > UDS: > >>> > >>> > >>> > https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-bugsquad > >>> > >>> We'll discuss how to transition lp teams, responsibilities, > documentation > >>> and wiki issues, etc. Please add anything that needs to be discussed > to the > >>> whiteboard on the blueprint. Seriously, have at it! Edit away! > >>> > >>> In the interim, please feel free to participate in bugsquad and quality > >>> activities as a member of either team :-) I know several bugsquadders > have > >>> introduced themselves to the quality list -- thank you! > >>> > >>> Nicholas > >>> > >>> > >>> -- > >>> Ubuntu-bugsquad mailing list > >>> Ubuntu-bugsquad at lists.ubuntu.com > >>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > >> > >> > >> -- > >> Ubuntu-quality mailing list > >> Ubuntu-quality at lists.ubuntu.com > >> Modify settings or unsubscribe at: > >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ag.restringere at gmail.com Mon Nov 4 20:54:55 2013 From: ag.restringere at gmail.com (AG Restringere) Date: Mon, 4 Nov 2013 15:54:55 -0500 Subject: Bug Triage processes need some improvement and automation... Message-ID: Re-posting my message to this list to create a new thread about Bug Triage procedures. I've outlined some ideas that I think would really improve the efficiency and clarity of Bug Triage operations. -------------------------------- In my experience in - when I dabbled in some bug control work as part of the Ubuntu-X team - the Bug Triage process is still very tedious and lacks sufficient automation. Most of the time and effort I spent doing bug control work was spent browsing Launchpad and reading through hundreds of bug-emails in order to find bugs to work on. Most of my time was spent searching for bugs but very little of my time was spent actively working on bugs and being productive. Also, many times I saw bugs that had comments from Bug Control members but it was never clear who was working on the bug or what they wanted to do with it. This often lead me to add comments when they weren't needed or not contribute when a bug actually needed attention and action. Modifications I would make to the Bug Triage process: 1. Assignment and eliminating redundancy: When a Bug Triager begins working on a bug they should assign themselves to the bug on Launchpad if they intend to actively work on it. Only one Bug Triage member should be assigned and actively working on a bug at any given time and they should effectively "own" that bug and be responsible for it. The only other people who should be working on that specific bug should be Reporters, Testers and Developers. Assignment would help other Bug Triage people to know "this bug is actively owned by another member" and know to move on to other bugs and leave that one alone. It would be even better if Launchpad could filter out the bugs that were actively assigned to Bug Control members so people could find those that nobody was working on and needed attention. Sufficient criteria for finding new bugs could be as simple as "Confirmed"+"Unassigned". 2. Email volume reduction: Bug Triage members should only receive emails about bugs they're actively assigned to. It's really time consuming to sort through hundreds of bug-mails that involve bugs that are not relevant to ones currently being worked on. This applies to all roles such as Testers, Reporters and others as well. The only general emails that should be received should be from the discussion or developer mailing lists. 3. Auto-assignment process queue: Similar to a tech-support ticket system the next step in this process would be to introduce a process queue with auto-assignment of bugs to Bug Triage members. I don't know how this would work but some status change in the bug would have to trigger it's submission it into the process queue such as reaching a Confirmed status or increased Reporter activity at some threshold level. The distribution of the bugs would have to take into account the work-load of the Bug Triage members and distribute them evenly but perhaps that's a bit too complicated to do in code. Maybe random assignment would be better or it could based on the package selection preferences of individual members. Perhaps there could even be some senior Bug Control members who would manually assign the bugs from the queue. This would eliminate the need for Bug Triage members to even need to go to Launchpad to search for bugs unless they're doing some extra research. Bugs would be sent to them via email automatically when they're ready to be triaged and auto-assigned without any extra steps needed. Conclusion: If the above steps were implemented or some equivalent processes I think the Bug Triage would be streamlined, eliminate redundancy and get faster turn-around times. Bug Triage members would be more focused and successful. Newer Bug Triage members would be able to be "plugged in" to a standardized process and this would improve retention because people would see results faster with less effort. -------------------------------- Hopefully the feedback and ideas above can be tested in some form and implemented. Best regards, AG -------------- next part -------------- An HTML attachment was scrubbed... URL: From teward at ubuntu.com Mon Nov 4 21:15:11 2013 From: teward at ubuntu.com (Thomas Ward) Date: Mon, 4 Nov 2013 16:15:11 -0500 Subject: Bug Triage processes need some improvement and automation... In-Reply-To: References: Message-ID: Hey, AG, thanks for splitting this off into a separate discussion. On Mon, Nov 4, 2013 at 3:54 PM, AG Restringere wrote: > Re-posting my message to this list to create a new thread about Bug Triage > procedures. I've outlined some ideas that I think would really improve the > efficiency and clarity of Bug Triage operations. > > -------------------------------- > > In my experience in - when I dabbled in some bug control work as part of the > Ubuntu-X team - the Bug Triage process is still very tedious and lacks > sufficient automation. Most of the time and effort I spent doing bug control > work was spent browsing Launchpad and reading through hundreds of bug-emails > in order to find bugs to work on. Most of my time was spent searching for > bugs but very little of my time was spent actively working on bugs and being > productive. Also, many times I saw bugs that had comments from Bug Control > members but it was never clear who was working on the bug or what they > wanted to do with it. This often lead me to add comments when they weren't > needed or not contribute when a bug actually needed attention and action. > > Modifications I would make to the Bug Triage process: > > 1. Assignment and eliminating redundancy: > > When a Bug Triager begins working on a bug they should assign themselves to > the bug on Launchpad if they intend to actively work on it. Only one Bug > Triage member should be assigned and actively working on a bug at any given > time and they should effectively "own" that bug and be responsible for it. > The only other people who should be working on that specific bug should be > Reporters, Testers and Developers. Assignment would help other Bug Triage > people to know "this bug is actively owned by another member" and know to > move on to other bugs and leave that one alone. It would be even better if > Launchpad could filter out the bugs that were actively assigned to Bug > Control members so people could find those that nobody was working on and > needed attention. Sufficient criteria for finding new bugs could be as > simple as "Confirmed"+"Unassigned". I am against this suggestion as it stands, maybe because I do not understand your reasoning for it or the potential execution of this, but also because there needs to be made a distinction, in my opinion, between the role of Bug Triager and the role of "Package Fixer" (for lack of a better term, this would be someone with the package knowledge and development knowledge to fix the bugs once they're "Triaged"). A triager may help get the bug from New to Triaged or New to Confirmed, but ultimately someone with developer knowledge of the package, or the knowledge to patch the package, is going to be the one the bug is "assigned" to for the work item. As well, a single individiual triager may have to collaborate with other triagers in order to get the package to the "Triaged" state. I myself have collaborated with other bug controllers and bug triagers in order to get bugs moved along to a point where a developer can work on the bugs, and in most cases, I quite like that collaboration. That collaboration would then, in a sense, mean that all the triagers who have collaborated on it are "owners" of the bug for a triaging sense. Assigning one "triage owner" for a bug defeats the general idea of that collaboration of which myself and others are so fond of. Also, unless you're proposing changing the bug system to have an additional "Triage Owner" role and field on the bug and restricting "Triage Owner" to bug controllers who actually have the access that Bug Squad does not have (i.e. to set the "Triaged" state and the bug importance, as well as other bug-control specific tasks), the "Assigned To" field on bugs is used to identify who the work on fixing the bug is assigned to, not the triager. I still stand by this, because as one of the people primarily working on the nginx package now, I have seen people assign themselves to bugs and fix them, or assign themselves, and then hand me the work later, and reassigning it to me as the person who will fix it or SRU it or whatever. > > 2. Email volume reduction: > > Bug Triage members should only receive emails about bugs they're actively > assigned to. It's really time consuming to sort through hundreds of > bug-mails that involve bugs that are not relevant to ones currently being > worked on. This applies to all roles such as Testers, Reporters and others > as well. The only general emails that should be received should be from the > discussion or developer mailing lists. I'm confused here. As a Bug Squad member, I have received exactly 0 email addresses for subscribed bugs, in that the Bug Squad isn't subscribed to any bugs by default. As a Bug Control member, I see some crash bug data for which bugcontrol is subscribed to, or is a member of one of the teams subscribed. In comparison with the packages' bugs which I am specifically subscribed to, I've seen very few bug-control subscribed bug stuff, so I'm a little confused with this modification or concern. > > 3. Auto-assignment process queue: > > Similar to a tech-support ticket system the next step in this process would > be to introduce a process queue with auto-assignment of bugs to Bug Triage > members. I don't know how this would work but some status change in the bug > would have to trigger it's submission it into the process queue such as > reaching a Confirmed status or increased Reporter activity at some threshold > level. The distribution of the bugs would have to take into account the > work-load of the Bug Triage members and distribute them evenly but perhaps > that's a bit too complicated to do in code. Maybe random assignment would be > better or it could based on the package selection preferences of individual > members. Perhaps there could even be some senior Bug Control members who > would manually assign the bugs from the queue. This would eliminate the > need for Bug Triage members to even need to go to Launchpad to search for > bugs unless they're doing some extra research. Bugs would be sent to them > via email automatically when they're ready to be triaged and auto-assigned > without any extra steps needed. > > Conclusion: > > If the above steps were implemented or some equivalent processes I think the > Bug Triage would be streamlined, eliminate redundancy and get faster > turn-around times. Bug Triage members would be more focused and successful. > Newer Bug Triage members would be able to be "plugged in" to a standardized > process and this would improve retention because people would see results > faster with less effort. > > -------------------------------- > > Hopefully the feedback and ideas above can be tested in some form and > implemented. > > Best regards, > AG > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > ------ Thomas From ag.restringere at gmail.com Mon Nov 4 22:32:17 2013 From: ag.restringere at gmail.com (AG Restringere) Date: Mon, 4 Nov 2013 17:32:17 -0500 Subject: Bug Triage processes need some improvement and automation... In-Reply-To: References: Message-ID: > > Bug Squad does not have (i.e. to set the "Triaged" state and the bug > importance, as well as other bug-control specific tasks), the > "Assigned To" field on bugs is used to identify who the work on fixing > the bug is assigned to, not the triager. Sorry, I didn't understand just how specific the usage of the term "Assigned To:" is in Ubuntu. Given that in Ubuntu the "Assigned To:" term/status is used specifically for Developers and Packagers that will fix the bug then I am not using a correct term. In that case a new term is needed to avoid confusion. The better term would be a "Managed By:" status because the Bug Triage person is managing the bug but not fixing it. This would work in a similar way to "Assigned To:" but it would apply to Bug Squad and Bug Control members and not Developers or Packagers. The new status would make it crystal clear which Bug Squad/Control member is managing the bug and whether it's being actively managed. The Launchpad bug-menu and search filters would have to be modified to accommodate this and only Bug Squad/Control members could have permissions over it is so the public wouldn't use it by mistake. > Assigning one "triage owner" for a bug defeats the general idea of > that collaboration of which myself and others are so fond of. > Collaboration could still be possible but there would be a more systematic approach. Just because a bug is "Managed By:" a single Bug Triage person and doesn't mean that they can't ask other Bug Triage members for help, advice, to look at a log, agree that a two bugs are duplicates, etc...It just means that in the end of the day one single Bug Triage person is making comments on the bug and that one person is responsible for triaging it. Just take the number of open non-triaged bugs and divide them by the number of Bug Triage "staff" currently available, you'll most likely get a very large quantity. Given the high level of interest that OEM's and games developers have in Ubuntu you'll probably want to ensure Bug Triage is as fast as possible. Unfortunately Bug Triage is a limited resource, the team only has so much time to work on a large number of bugs, so you'll have streamline the process to make it faster. I'm confused here...(...)...In comparison with the > packages' bugs which I am specifically subscribed to, I've seen very > few bug-control subscribed bug stuff, so I'm a little confused with > this modification or concern. Then this is something team specific that I will have to bring to the attention of the Ubuntu-X team and I'll have to see if there's a way they can tone down their bug volume or if I can turn off my bug-mail for that specific team. All in all I don't know how "workable" these suggestions are at this point and it is certainly a long-term process of improvement that will have to be taken in small incremental stage. The most important item in my view is to implement the "Managed By:" tool/status and the "one bug one Triager" system. Best regards, AG On Mon, Nov 4, 2013 at 4:15 PM, Thomas Ward wrote: > Hey, AG, thanks for splitting this off into a separate discussion. > > On Mon, Nov 4, 2013 at 3:54 PM, AG Restringere > wrote: > > Re-posting my message to this list to create a new thread about Bug > Triage > > procedures. I've outlined some ideas that I think would really improve > the > > efficiency and clarity of Bug Triage operations. > > > > -------------------------------- > > > > In my experience in - when I dabbled in some bug control work as part of > the > > Ubuntu-X team - the Bug Triage process is still very tedious and lacks > > sufficient automation. Most of the time and effort I spent doing bug > control > > work was spent browsing Launchpad and reading through hundreds of > bug-emails > > in order to find bugs to work on. Most of my time was spent searching > for > > bugs but very little of my time was spent actively working on bugs and > being > > productive. Also, many times I saw bugs that had comments from Bug > Control > > members but it was never clear who was working on the bug or what they > > wanted to do with it. This often lead me to add comments when they > weren't > > needed or not contribute when a bug actually needed attention and action. > > > > Modifications I would make to the Bug Triage process: > > > > 1. Assignment and eliminating redundancy: > > > > When a Bug Triager begins working on a bug they should assign themselves > to > > the bug on Launchpad if they intend to actively work on it. Only one Bug > > Triage member should be assigned and actively working on a bug at any > given > > time and they should effectively "own" that bug and be responsible for > it. > > The only other people who should be working on that specific bug should > be > > Reporters, Testers and Developers. Assignment would help other Bug > Triage > > people to know "this bug is actively owned by another member" and know to > > move on to other bugs and leave that one alone. It would be even better > if > > Launchpad could filter out the bugs that were actively assigned to Bug > > Control members so people could find those that nobody was working on and > > needed attention. Sufficient criteria for finding new bugs could be as > > simple as "Confirmed"+"Unassigned". > > I am against this suggestion as it stands, maybe because I do not > understand your reasoning for it or the potential execution of this, > but also because there needs to be made a distinction, in my opinion, > between the role of Bug Triager and the role of "Package Fixer" (for > lack of a better term, this would be someone with the package > knowledge and development knowledge to fix the bugs once they're > "Triaged"). > > A triager may help get the bug from New to Triaged or New to > Confirmed, but ultimately someone with developer knowledge of the > package, or the knowledge to patch the package, is going to be the one > the bug is "assigned" to for the work item. As well, a single > individiual triager may have to collaborate with other triagers in > order to get the package to the "Triaged" state. I myself have > collaborated with other bug controllers and bug triagers in order to > get bugs moved along to a point where a developer can work on the > bugs, and in most cases, I quite like that collaboration. That > collaboration would then, in a sense, mean that all the triagers who > have collaborated on it are "owners" of the bug for a triaging sense. > Assigning one "triage owner" for a bug defeats the general idea of > that collaboration of which myself and others are so fond of. > > Also, unless you're proposing changing the bug system to have an > additional "Triage Owner" role and field on the bug and restricting > "Triage Owner" to bug controllers who actually have the access that > Bug Squad does not have (i.e. to set the "Triaged" state and the bug > importance, as well as other bug-control specific tasks), the > "Assigned To" field on bugs is used to identify who the work on fixing > the bug is assigned to, not the triager. I still stand by this, > because as one of the people primarily working on the nginx package > now, I have seen people assign themselves to bugs and fix them, or > assign themselves, and then hand me the work later, and reassigning it > to me as the person who will fix it or SRU it or whatever. > > > > > 2. Email volume reduction: > > > > Bug Triage members should only receive emails about bugs they're actively > > assigned to. It's really time consuming to sort through hundreds of > > bug-mails that involve bugs that are not relevant to ones currently being > > worked on. This applies to all roles such as Testers, Reporters and > others > > as well. The only general emails that should be received should be from > the > > discussion or developer mailing lists. > > I'm confused here. As a Bug Squad member, I have received exactly 0 > email addresses for subscribed bugs, in that the Bug Squad isn't > subscribed to any bugs by default. As a Bug Control member, I see > some crash bug data for which bugcontrol is subscribed to, or is a > member of one of the teams subscribed. In comparison with the > packages' bugs which I am specifically subscribed to, I've seen very > few bug-control subscribed bug stuff, so I'm a little confused with > this modification or concern. > > > > > 3. Auto-assignment process queue: > > > > Similar to a tech-support ticket system the next step in this process > would > > be to introduce a process queue with auto-assignment of bugs to Bug > Triage > > members. I don't know how this would work but some status change in the > bug > > would have to trigger it's submission it into the process queue such as > > reaching a Confirmed status or increased Reporter activity at some > threshold > > level. The distribution of the bugs would have to take into account the > > work-load of the Bug Triage members and distribute them evenly but > perhaps > > that's a bit too complicated to do in code. Maybe random assignment > would be > > better or it could based on the package selection preferences of > individual > > members. Perhaps there could even be some senior Bug Control members who > > would manually assign the bugs from the queue. This would eliminate the > > need for Bug Triage members to even need to go to Launchpad to search for > > bugs unless they're doing some extra research. Bugs would be sent to > them > > via email automatically when they're ready to be triaged and > auto-assigned > > without any extra steps needed. > > > > Conclusion: > > > > If the above steps were implemented or some equivalent processes I think > the > > Bug Triage would be streamlined, eliminate redundancy and get faster > > turn-around times. Bug Triage members would be more focused and > successful. > > Newer Bug Triage members would be able to be "plugged in" to a > standardized > > process and this would improve retention because people would see results > > faster with less effort. > > > > -------------------------------- > > > > Hopefully the feedback and ideas above can be tested in some form and > > implemented. > > > > Best regards, > > AG > > > > -- > > Ubuntu-bugsquad mailing list > > Ubuntu-bugsquad at lists.ubuntu.com > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > > > ------ > Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From es20490446e at gmail.com Tue Nov 5 11:45:30 2013 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Tue, 05 Nov 2013 12:45:30 +0100 Subject: Bug Triage processes need some improvement and automation... In-Reply-To: References: Message-ID: <5278DA5A.7010401@gmail.com> I have to (constructively) disagree with these suggestions: - With the first one because, although it's an improvement, it's just a *distraction* of what is really important now. - With the second one because of putting *barriers* in front of collaboration, one key of success. - With the point of view in general because forgetting *simplicity*, the ultimate goal of any system. El 04/11/13 23:32, AG Restringere escribió: > > Bug Squad does not have (i.e. to set the "Triaged" state and the bug > importance, as well as other bug-control specific tasks), the > "Assigned To" field on bugs is used to identify who the work on fixing > the bug is assigned to, not the triager. > > > Sorry, I didn't understand just how specific the usage of the term > "Assigned To:" is in Ubuntu. Given that in Ubuntu the "Assigned To:" > term/status is used specifically for Developers and Packagers that > will fix the bug then I am not using a correct term. In that case a > new term is needed to avoid confusion. The better term would be a > "Managed By:" status because the Bug Triage person is managing the bug > but not fixing it. This would work in a similar way to "Assigned To:" > but it would apply to Bug Squad and Bug Control members and not > Developers or Packagers. The new status would make it crystal clear > which Bug Squad/Control member is managing the bug and whether it's > being actively managed. The Launchpad bug-menu and search filters > would have to be modified to accommodate this and only Bug > Squad/Control members could have permissions over it is so the public > wouldn't use it by mistake. > > Assigning one "triage owner" for a bug defeats the general idea of > that collaboration of which myself and others are so fond of. > > > Collaboration could still be possible but there would be a more > systematic approach. Just because a bug is "Managed By:" a single Bug > Triage person and doesn't mean that they can't ask other Bug Triage > members for help, advice, to look at a log, agree that a two bugs are > duplicates, etc...It just means that in the end of the day one single > Bug Triage person is making comments on the bug and that one person is > responsible for triaging it. Just take the number of open non-triaged > bugs and divide them by the number of Bug Triage "staff" currently > available, you'll most likely get a very large quantity. Given the > high level of interest that OEM's and games developers have in Ubuntu > you'll probably want to ensure Bug Triage is as fast as possible. > Unfortunately Bug Triage is a limited resource, the team only has so > much time to work on a large number of bugs, so you'll have streamline > the process to make it faster. > > I'm confused here...(...)...In comparison with the > packages' bugs which I am specifically subscribed to, I've seen very > few bug-control subscribed bug stuff, so I'm a little confused with > this modification or concern. > > > Then this is something team specific that I will have to bring to the > attention of the Ubuntu-X team and I'll have to see if there's a way > they can tone down their bug volume or if I can turn off my bug-mail > for that specific team. > > All in all I don't know how "workable" these suggestions are at this > point and it is certainly a long-term process of improvement that will > have to be taken in small incremental stage. The most important item > in my view is to implement the "Managed By:" tool/status and the "one > bug one Triager" system. > > Best regards, > AG > > > On Mon, Nov 4, 2013 at 4:15 PM, Thomas Ward > wrote: > > Hey, AG, thanks for splitting this off into a separate discussion. > > On Mon, Nov 4, 2013 at 3:54 PM, AG Restringere > > wrote: > > Re-posting my message to this list to create a new thread about > Bug Triage > > procedures. I've outlined some ideas that I think would really > improve the > > efficiency and clarity of Bug Triage operations. > > > > -------------------------------- > > > > In my experience in - when I dabbled in some bug control work as > part of the > > Ubuntu-X team - the Bug Triage process is still very tedious and > lacks > > sufficient automation. Most of the time and effort I spent doing > bug control > > work was spent browsing Launchpad and reading through hundreds > of bug-emails > > in order to find bugs to work on. Most of my time was spent > searching for > > bugs but very little of my time was spent actively working on > bugs and being > > productive. Also, many times I saw bugs that had comments from > Bug Control > > members but it was never clear who was working on the bug or > what they > > wanted to do with it. This often lead me to add comments when > they weren't > > needed or not contribute when a bug actually needed attention > and action. > > > > Modifications I would make to the Bug Triage process: > > > > 1. Assignment and eliminating redundancy: > > > > When a Bug Triager begins working on a bug they should assign > themselves to > > the bug on Launchpad if they intend to actively work on it. > Only one Bug > > Triage member should be assigned and actively working on a bug > at any given > > time and they should effectively "own" that bug and be > responsible for it. > > The only other people who should be working on that specific bug > should be > > Reporters, Testers and Developers. Assignment would help other > Bug Triage > > people to know "this bug is actively owned by another member" > and know to > > move on to other bugs and leave that one alone. It would be > even better if > > Launchpad could filter out the bugs that were actively assigned > to Bug > > Control members so people could find those that nobody was > working on and > > needed attention. Sufficient criteria for finding new bugs > could be as > > simple as "Confirmed"+"Unassigned". > > I am against this suggestion as it stands, maybe because I do not > understand your reasoning for it or the potential execution of this, > but also because there needs to be made a distinction, in my opinion, > between the role of Bug Triager and the role of "Package Fixer" (for > lack of a better term, this would be someone with the package > knowledge and development knowledge to fix the bugs once they're > "Triaged"). > > A triager may help get the bug from New to Triaged or New to > Confirmed, but ultimately someone with developer knowledge of the > package, or the knowledge to patch the package, is going to be the one > the bug is "assigned" to for the work item. As well, a single > individiual triager may have to collaborate with other triagers in > order to get the package to the "Triaged" state. I myself have > collaborated with other bug controllers and bug triagers in order to > get bugs moved along to a point where a developer can work on the > bugs, and in most cases, I quite like that collaboration. That > collaboration would then, in a sense, mean that all the triagers who > have collaborated on it are "owners" of the bug for a triaging sense. > Assigning one "triage owner" for a bug defeats the general idea of > that collaboration of which myself and others are so fond of. > > Also, unless you're proposing changing the bug system to have an > additional "Triage Owner" role and field on the bug and restricting > "Triage Owner" to bug controllers who actually have the access that > Bug Squad does not have (i.e. to set the "Triaged" state and the bug > importance, as well as other bug-control specific tasks), the > "Assigned To" field on bugs is used to identify who the work on fixing > the bug is assigned to, not the triager. I still stand by this, > because as one of the people primarily working on the nginx package > now, I have seen people assign themselves to bugs and fix them, or > assign themselves, and then hand me the work later, and reassigning it > to me as the person who will fix it or SRU it or whatever. > > > > > 2. Email volume reduction: > > > > Bug Triage members should only receive emails about bugs they're > actively > > assigned to. It's really time consuming to sort through hundreds of > > bug-mails that involve bugs that are not relevant to ones > currently being > > worked on. This applies to all roles such as Testers, Reporters > and others > > as well. The only general emails that should be received should > be from the > > discussion or developer mailing lists. > > I'm confused here. As a Bug Squad member, I have received exactly 0 > email addresses for subscribed bugs, in that the Bug Squad isn't > subscribed to any bugs by default. As a Bug Control member, I see > some crash bug data for which bugcontrol is subscribed to, or is a > member of one of the teams subscribed. In comparison with the > packages' bugs which I am specifically subscribed to, I've seen very > few bug-control subscribed bug stuff, so I'm a little confused with > this modification or concern. > > > > > 3. Auto-assignment process queue: > > > > Similar to a tech-support ticket system the next step in this > process would > > be to introduce a process queue with auto-assignment of bugs to > Bug Triage > > members. I don't know how this would work but some status > change in the bug > > would have to trigger it's submission it into the process queue > such as > > reaching a Confirmed status or increased Reporter activity at > some threshold > > level. The distribution of the bugs would have to take into > account the > > work-load of the Bug Triage members and distribute them evenly > but perhaps > > that's a bit too complicated to do in code. Maybe random > assignment would be > > better or it could based on the package selection preferences of > individual > > members. Perhaps there could even be some senior Bug Control > members who > > would manually assign the bugs from the queue. This would > eliminate the > > need for Bug Triage members to even need to go to Launchpad to > search for > > bugs unless they're doing some extra research. Bugs would be > sent to them > > via email automatically when they're ready to be triaged and > auto-assigned > > without any extra steps needed. > > > > Conclusion: > > > > If the above steps were implemented or some equivalent processes > I think the > > Bug Triage would be streamlined, eliminate redundancy and get faster > > turn-around times. Bug Triage members would be more focused and > successful. > > Newer Bug Triage members would be able to be "plugged in" to a > standardized > > process and this would improve retention because people would > see results > > faster with less effort. > > > > -------------------------------- > > > > Hopefully the feedback and ideas above can be tested in some > form and > > implemented. > > > > Best regards, > > AG > > > > -- > > Ubuntu-bugsquad mailing list > > Ubuntu-bugsquad at lists.ubuntu.com > > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > > > ------ > Thomas > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2260 bytes Desc: Firma criptográfica S/MIME URL: From nicholas.skaggs at canonical.com Tue Nov 5 15:22:43 2013 From: nicholas.skaggs at canonical.com (Nicholas Skaggs) Date: Tue, 05 Nov 2013 10:22:43 -0500 Subject: vUDS Sessions Message-ID: <52790D43.2020704@canonical.com> Just a reminder, here are the currently scheduled vUDS sessions relating to quality. If you have a topic for a session, please propose it and reply to this thread. Be quick however, the timeline is closing to add a session! Quality sessions typically will occur on the community track. http://uds.ubuntu.com/getinvolved/propose-a-session/ And the list: A community inspired session on tweaking usb startup creator for trusty; https://blueprints.launchpad.net/ubuntu/+spec/community-1311-ubuntu-usb-startup-creator A blueprint for us to work out the details on merging bugsquad and qa community teams; https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-bugsquad QA Community Roundtable, talking about the roles change, our big projects, and other things :-) https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-defining-workflows Please add to the agenda's on any of the blueprints, or simply respond with your comments and I will add them. Most of all, try and make the sessions ;-) Thanks everyone! Nicholas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ag.restringere at gmail.com Tue Nov 5 16:01:21 2013 From: ag.restringere at gmail.com (AG Restringere) Date: Tue, 5 Nov 2013 11:01:21 -0500 Subject: Bug Triage processes need some improvement and automation... In-Reply-To: <5278DA5A.7010401@gmail.com> References: <5278DA5A.7010401@gmail.com> Message-ID: > > I have to (constructively) disagree with these suggestions: > - With the first one because, although it's an improvement, it's just a > *distraction* of what is really important now. > - With the second one because of putting *barriers* in front of > collaboration, one key of success. > - With the point of view in general because forgetting *simplicity*, the > ultimate goal of any system. Got it, understood, you don't want to alter the current processes, adding a "Managed By:" field and using it doesn't mean altering processes, it just provides additional information that reduces some uncertainty. Let's look at this recent bug I submitted to Launchpad: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1221304 Right now there are some bug comments from Stephen M. Webb (Bregma) indicating some sort of triage activity but there's nothing on the bug report letting me know if it's being actively triaged and by who. This information should be clearly displayed on the bug report header. Here's a quick mock-up of that clearly describes what I would like to see on a bug report. --------------------------------------------------------- Bug #1221304 "Global app-menu is missing from panel..." *Reported by:* AG Restringere on 2013-09-05 /* who reported the bug? */ Affects: (the package information below) *Assigned to:* (Developers, Packagers, etc...to fix...) /* which developer or packager is fixing the bug? */ *Managed by:* Stephen M. Webb, Alberto Salvia Novella /* who is triaging the bug right now? */ --------------------------------------------------------- The addition of this field would in no way alter current Bug Triage processes or methods that are currently in place, those would remain the same. This would just make it simple and clear what is going on with the bug without having to analyze comments. Then members could use the Launchpad search filters to find bugs don't have anyone managing them removing unnecessary complexity from the bug search process. This tool would simply be for informational purposes and everyone would still have access to the bug and be able to help triage it if they wanted to. Best regards, AG On Tue, Nov 5, 2013 at 6:45 AM, Alberto Salvia Novella < es20490446e at gmail.com> wrote: > I have to (constructively) disagree with these suggestions: > > - With the first one because, although it's an improvement, it's just a > *distraction* of what is really important now. > - With the second one because of putting *barriers* in front of > collaboration, one key of success. > - With the point of view in general because forgetting *simplicity*, the > ultimate goal of any system. > > > El 04/11/13 23:32, AG Restringere escribió: > > Bug Squad does not have (i.e. to set the "Triaged" state and the bug >> importance, as well as other bug-control specific tasks), the >> "Assigned To" field on bugs is used to identify who the work on fixing >> the bug is assigned to, not the triager. > > > Sorry, I didn't understand just how specific the usage of the term > "Assigned To:" is in Ubuntu. Given that in Ubuntu the "Assigned To:" > term/status is used specifically for Developers and Packagers that will fix > the bug then I am not using a correct term. In that case a new term is > needed to avoid confusion. The better term would be a "Managed By:" status > because the Bug Triage person is managing the bug but not fixing it. This > would work in a similar way to "Assigned To:" but it would apply to Bug > Squad and Bug Control members and not Developers or Packagers. The new > status would make it crystal clear which Bug Squad/Control member is > managing the bug and whether it's being actively managed. The Launchpad > bug-menu and search filters would have to be modified to accommodate this > and only Bug Squad/Control members could have permissions over it is so the > public wouldn't use it by mistake. > > >> Assigning one "triage owner" for a bug defeats the general idea of >> that collaboration of which myself and others are so fond of. >> > > Collaboration could still be possible but there would be a more > systematic approach. Just because a bug is "Managed By:" a single Bug > Triage person and doesn't mean that they can't ask other Bug Triage members > for help, advice, to look at a log, agree that a two bugs are duplicates, > etc...It just means that in the end of the day one single Bug Triage person > is making comments on the bug and that one person is responsible for > triaging it. Just take the number of open non-triaged bugs and divide them > by the number of Bug Triage "staff" currently available, you'll most likely > get a very large quantity. Given the high level of interest that OEM's and > games developers have in Ubuntu you'll probably want to ensure Bug Triage > is as fast as possible. Unfortunately Bug Triage is a limited resource, > the team only has so much time to work on a large number of bugs, so you'll > have streamline the process to make it faster. > > I'm confused here...(...)...In comparison with the >> packages' bugs which I am specifically subscribed to, I've seen very >> few bug-control subscribed bug stuff, so I'm a little confused with >> this modification or concern. > > > Then this is something team specific that I will have to bring to the > attention of the Ubuntu-X team and I'll have to see if there's a way they > can tone down their bug volume or if I can turn off my bug-mail for that > specific team. > > All in all I don't know how "workable" these suggestions are at this > point and it is certainly a long-term process of improvement that will have > to be taken in small incremental stage. The most important item in my view > is to implement the "Managed By:" tool/status and the "one bug one Triager" > system. > > Best regards, > AG > > > On Mon, Nov 4, 2013 at 4:15 PM, Thomas Ward wrote: > >> Hey, AG, thanks for splitting this off into a separate discussion. >> >> On Mon, Nov 4, 2013 at 3:54 PM, AG Restringere >> wrote: >> > Re-posting my message to this list to create a new thread about Bug >> Triage >> > procedures. I've outlined some ideas that I think would really improve >> the >> > efficiency and clarity of Bug Triage operations. >> > >> > -------------------------------- >> > >> > In my experience in - when I dabbled in some bug control work as part >> of the >> > Ubuntu-X team - the Bug Triage process is still very tedious and lacks >> > sufficient automation. Most of the time and effort I spent doing bug >> control >> > work was spent browsing Launchpad and reading through hundreds of >> bug-emails >> > in order to find bugs to work on. Most of my time was spent searching >> for >> > bugs but very little of my time was spent actively working on bugs and >> being >> > productive. Also, many times I saw bugs that had comments from Bug >> Control >> > members but it was never clear who was working on the bug or what they >> > wanted to do with it. This often lead me to add comments when they >> weren't >> > needed or not contribute when a bug actually needed attention and >> action. >> > >> > Modifications I would make to the Bug Triage process: >> > >> > 1. Assignment and eliminating redundancy: >> > >> > When a Bug Triager begins working on a bug they should assign >> themselves to >> > the bug on Launchpad if they intend to actively work on it. Only one >> Bug >> > Triage member should be assigned and actively working on a bug at any >> given >> > time and they should effectively "own" that bug and be responsible for >> it. >> > The only other people who should be working on that specific bug should >> be >> > Reporters, Testers and Developers. Assignment would help other Bug >> Triage >> > people to know "this bug is actively owned by another member" and know >> to >> > move on to other bugs and leave that one alone. It would be even >> better if >> > Launchpad could filter out the bugs that were actively assigned to Bug >> > Control members so people could find those that nobody was working on >> and >> > needed attention. Sufficient criteria for finding new bugs could be as >> > simple as "Confirmed"+"Unassigned". >> >> I am against this suggestion as it stands, maybe because I do not >> understand your reasoning for it or the potential execution of this, >> but also because there needs to be made a distinction, in my opinion, >> between the role of Bug Triager and the role of "Package Fixer" (for >> lack of a better term, this would be someone with the package >> knowledge and development knowledge to fix the bugs once they're >> "Triaged"). >> >> A triager may help get the bug from New to Triaged or New to >> Confirmed, but ultimately someone with developer knowledge of the >> package, or the knowledge to patch the package, is going to be the one >> the bug is "assigned" to for the work item. As well, a single >> individiual triager may have to collaborate with other triagers in >> order to get the package to the "Triaged" state. I myself have >> collaborated with other bug controllers and bug triagers in order to >> get bugs moved along to a point where a developer can work on the >> bugs, and in most cases, I quite like that collaboration. That >> collaboration would then, in a sense, mean that all the triagers who >> have collaborated on it are "owners" of the bug for a triaging sense. >> Assigning one "triage owner" for a bug defeats the general idea of >> that collaboration of which myself and others are so fond of. >> >> Also, unless you're proposing changing the bug system to have an >> additional "Triage Owner" role and field on the bug and restricting >> "Triage Owner" to bug controllers who actually have the access that >> Bug Squad does not have (i.e. to set the "Triaged" state and the bug >> importance, as well as other bug-control specific tasks), the >> "Assigned To" field on bugs is used to identify who the work on fixing >> the bug is assigned to, not the triager. I still stand by this, >> because as one of the people primarily working on the nginx package >> now, I have seen people assign themselves to bugs and fix them, or >> assign themselves, and then hand me the work later, and reassigning it >> to me as the person who will fix it or SRU it or whatever. >> >> > >> > 2. Email volume reduction: >> > >> > Bug Triage members should only receive emails about bugs they're >> actively >> > assigned to. It's really time consuming to sort through hundreds of >> > bug-mails that involve bugs that are not relevant to ones currently >> being >> > worked on. This applies to all roles such as Testers, Reporters and >> others >> > as well. The only general emails that should be received should be >> from the >> > discussion or developer mailing lists. >> >> I'm confused here. As a Bug Squad member, I have received exactly 0 >> email addresses for subscribed bugs, in that the Bug Squad isn't >> subscribed to any bugs by default. As a Bug Control member, I see >> some crash bug data for which bugcontrol is subscribed to, or is a >> member of one of the teams subscribed. In comparison with the >> packages' bugs which I am specifically subscribed to, I've seen very >> few bug-control subscribed bug stuff, so I'm a little confused with >> this modification or concern. >> >> > >> > 3. Auto-assignment process queue: >> > >> > Similar to a tech-support ticket system the next step in this process >> would >> > be to introduce a process queue with auto-assignment of bugs to Bug >> Triage >> > members. I don't know how this would work but some status change in >> the bug >> > would have to trigger it's submission it into the process queue such as >> > reaching a Confirmed status or increased Reporter activity at some >> threshold >> > level. The distribution of the bugs would have to take into account the >> > work-load of the Bug Triage members and distribute them evenly but >> perhaps >> > that's a bit too complicated to do in code. Maybe random assignment >> would be >> > better or it could based on the package selection preferences of >> individual >> > members. Perhaps there could even be some senior Bug Control members who >> > would manually assign the bugs from the queue. This would eliminate the >> > need for Bug Triage members to even need to go to Launchpad to search >> for >> > bugs unless they're doing some extra research. Bugs would be sent to >> them >> > via email automatically when they're ready to be triaged and >> auto-assigned >> > without any extra steps needed. >> > >> > Conclusion: >> > >> > If the above steps were implemented or some equivalent processes I >> think the >> > Bug Triage would be streamlined, eliminate redundancy and get faster >> > turn-around times. Bug Triage members would be more focused and >> successful. >> > Newer Bug Triage members would be able to be "plugged in" to a >> standardized >> > process and this would improve retention because people would see >> results >> > faster with less effort. >> > >> > -------------------------------- >> > >> > Hopefully the feedback and ideas above can be tested in some form and >> > implemented. >> > >> > Best regards, >> > AG >> > >> > -- >> > Ubuntu-bugsquad mailing list >> > Ubuntu-bugsquad at lists.ubuntu.com >> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad >> > >> >> ------ >> Thomas >> > > > > > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From teward at trekweb.org Tue Nov 5 16:53:08 2013 From: teward at trekweb.org (Thomas Ward) Date: Tue, 5 Nov 2013 11:53:08 -0500 Subject: Bug Triage processes need some improvement and automation... In-Reply-To: References: <5278DA5A.7010401@gmail.com> Message-ID: *Sent from my iPhone. Please excuse any typos, as they are likely to happen by accident.* On Nov 5, 2013, at 11:01 AM, AG Restringere wrote: >> I have to (constructively) disagree with these suggestions: >> - With the first one because, although it's an improvement, it's just a distraction of what is really important now. >> - With the second one because of putting barriers in front of collaboration, one key of success. >> - With the point of view in general because forgetting simplicity, the ultimate goal of any system. > > Got it, understood, you don't want to alter the current processes, adding a "Managed By:" field and using it doesn't mean altering processes, it just provides additional information that reduces some uncertainty. > > Let's look at this recent bug I submitted to Launchpad: > https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1221304 > > Right now there are some bug comments from Stephen M. Webb (Bregma) indicating some sort of triage activity but there's nothing on the bug report letting me know if it's being actively triaged and by who. As it should be. Triaging is *not* managed by a single individual for a bug, it's a community effort with everyone working together to get the bug to where it can be worked on. Take any individual nginx bug in which I have had sponsored-uploaded fixes for as an example, security bugs included, or is currently marked as Triaged. Back when Debian maintainers were working on it in Ubuntu, they were OK with it, but were stumbling along on the triage process, and fixing bugs like in Debian, but getting hung up on the 'version is stuck here' stuff and not fixing all the bugs in Precise and other releases. Then I come around and provide the Bug Squad knowledge needed. That shifted the active triage to me from the Debian maintainers. But I by no means am the only one triaging nginx bugs, there are a few people who work on the bugs and add information or request information. And there are times where I do hand off the bug to Debian for them to fix, which means Debian is triaging it then, and not myself. And while my name is likely on the debdiff I was likely not the one who developed the fix. > This information should be clearly displayed on the bug report header. Here's a quick mock-up of that clearly describes what I would like to see on a bug report. > > --------------------------------------------------------- > Bug #1221304 > > "Global app-menu is missing from panel..." > > Reported by: AG Restringere on 2013-09-05 /* who reported the bug? */ > > Affects: (the package information below) > Assigned to: (Developers, Packagers, etc...to fix...) /* which developer or packager is fixing the bug? */ > > Managed by: Stephen M. Webb, Alberto Salvia Novella /* who is triaging the bug right now? */ Additional useless cruft because this cannot be auto assigned if, say, twenty people comment on it. The system won't be able to determine who is actually doing triage and who is just putting "This affects me" and stuff, case in point any of a thousand kernel bugs with such cases. > > --------------------------------------------------------- > > The addition of this field would in no way alter current Bug Triage processes or methods that are currently in place, those would remain the same. This would just make it simple and clear what is going on with the bug without having to analyze comments. Then members could use the Launchpad search filters to find bugs don't have anyone managing them removing unnecessary complexity from the bug search process. This tool would simply be for informational purposes and everyone would still have access to the bug and be able to help triage it if they wanted to. But how would this improve the system? This just sounds like a way to add more 'Minor feature request' stuff to the Launchpad devs, and they more than likely are already inundated with minor things that are being trumped by more major things. As well, the comments are there for a reason. A bug's 'state' of being actively worked on hinges on comments and activity, not a list of triagers. A sign of a good bug is a bug in which those affected, those helping to triage, and those who can fix it are all collaborating, and in those cases it wouldn't work to have a list of those who are "triaging" the bug because it'd add more work for bug supervisors to figure out who actually *is* triaging while others are just commenting. This also adds to the complexity of the process of triaging whether you personally think it does or not. The only way to logically and feasibly apply this is if the 'triaged by' role only picks up on comments by people on bug squad or bug control, and ignores the others, or if the process is manually done and bug controllers (who already have elevated permissions) are the only ones who can set the status of who is triaging the bug, and that too adds additional work to an already-pretty-simplistic system. > > Best regards, > AG > > >> On Tue, Nov 5, 2013 at 6:45 AM, Alberto Salvia Novella wrote: >> I have to (constructively) disagree with these suggestions: >> >> - With the first one because, although it's an improvement, it's just a distraction of what is really important now. >> - With the second one because of putting barriers in front of collaboration, one key of success. >> - With the point of view in general because forgetting simplicity, the ultimate goal of any system. >> >> >> El 04/11/13 23:32, AG Restringere escribió: >>>> Bug Squad does not have (i.e. to set the "Triaged" state and the bug >>>> importance, as well as other bug-control specific tasks), the >>>> "Assigned To" field on bugs is used to identify who the work on fixing >>>> the bug is assigned to, not the triager. >>> >>> Sorry, I didn't understand just how specific the usage of the term "Assigned To:" is in Ubuntu. Given that in Ubuntu the "Assigned To:" term/status is used specifically for Developers and Packagers that will fix the bug then I am not using a correct term. In that case a new term is needed to avoid confusion. The better term would be a "Managed By:" status because the Bug Triage person is managing the bug but not fixing it. This would work in a similar way to "Assigned To:" but it would apply to Bug Squad and Bug Control members and not Developers or Packagers. The new status would make it crystal clear which Bug Squad/Control member is managing the bug and whether it's being actively managed. The Launchpad bug-menu and search filters would have to be modified to accommodate this and only Bug Squad/Control members could have permissions over it is so the public wouldn't use it by mistake. >>> >>>> Assigning one "triage owner" for a bug defeats the general idea of >>>> that collaboration of which myself and others are so fond of. >>> >>> Collaboration could still be possible but there would be a more systematic approach. Just because a bug is "Managed By:" a single Bug Triage person and doesn't mean that they can't ask other Bug Triage members for help, advice, to look at a log, agree that a two bugs are duplicates, etc...It just means that in the end of the day one single Bug Triage person is making comments on the bug and that one person is responsible for triaging it. Just take the number of open non-triaged bugs and divide them by the number of Bug Triage "staff" currently available, you'll most likely get a very large quantity. Given the high level of interest that OEM's and games developers have in Ubuntu you'll probably want to ensure Bug Triage is as fast as possible. Unfortunately Bug Triage is a limited resource, the team only has so much time to work on a large number of bugs, so you'll have streamline the process to make it faster. >>> >>>> I'm confused here...(...)...In comparison with the >>>> packages' bugs which I am specifically subscribed to, I've seen very >>>> few bug-control subscribed bug stuff, so I'm a little confused with >>>> this modification or concern. >>> >>> Then this is something team specific that I will have to bring to the attention of the Ubuntu-X team and I'll have to see if there's a way they can tone down their bug volume or if I can turn off my bug-mail for that specific team. >>> >>> All in all I don't know how "workable" these suggestions are at this point and it is certainly a long-term process of improvement that will have to be taken in small incremental stage. The most important item in my view is to implement the "Managed By:" tool/status and the "one bug one Triager" system. >>> >>> Best regards, >>> AG >>> >>> >>>> On Mon, Nov 4, 2013 at 4:15 PM, Thomas Ward wrote: >>>> Hey, AG, thanks for splitting this off into a separate discussion. >>>> >>>> On Mon, Nov 4, 2013 at 3:54 PM, AG Restringere wrote: >>>> > Re-posting my message to this list to create a new thread about Bug Triage >>>> > procedures. I've outlined some ideas that I think would really improve the >>>> > efficiency and clarity of Bug Triage operations. >>>> > >>>> > -------------------------------- >>>> > >>>> > In my experience in - when I dabbled in some bug control work as part of the >>>> > Ubuntu-X team - the Bug Triage process is still very tedious and lacks >>>> > sufficient automation. Most of the time and effort I spent doing bug control >>>> > work was spent browsing Launchpad and reading through hundreds of bug-emails >>>> > in order to find bugs to work on. Most of my time was spent searching for >>>> > bugs but very little of my time was spent actively working on bugs and being >>>> > productive. Also, many times I saw bugs that had comments from Bug Control >>>> > members but it was never clear who was working on the bug or what they >>>> > wanted to do with it. This often lead me to add comments when they weren't >>>> > needed or not contribute when a bug actually needed attention and action. >>>> > >>>> > Modifications I would make to the Bug Triage process: >>>> > >>>> > 1. Assignment and eliminating redundancy: >>>> > >>>> > When a Bug Triager begins working on a bug they should assign themselves to >>>> > the bug on Launchpad if they intend to actively work on it. Only one Bug >>>> > Triage member should be assigned and actively working on a bug at any given >>>> > time and they should effectively "own" that bug and be responsible for it. >>>> > The only other people who should be working on that specific bug should be >>>> > Reporters, Testers and Developers. Assignment would help other Bug Triage >>>> > people to know "this bug is actively owned by another member" and know to >>>> > move on to other bugs and leave that one alone. It would be even better if >>>> > Launchpad could filter out the bugs that were actively assigned to Bug >>>> > Control members so people could find those that nobody was working on and >>>> > needed attention. Sufficient criteria for finding new bugs could be as >>>> > simple as "Confirmed"+"Unassigned". >>>> >>>> I am against this suggestion as it stands, maybe because I do not >>>> understand your reasoning for it or the potential execution of this, >>>> but also because there needs to be made a distinction, in my opinion, >>>> between the role of Bug Triager and the role of "Package Fixer" (for >>>> lack of a better term, this would be someone with the package >>>> knowledge and development knowledge to fix the bugs once they're >>>> "Triaged"). >>>> >>>> A triager may help get the bug from New to Triaged or New to >>>> Confirmed, but ultimately someone with developer knowledge of the >>>> package, or the knowledge to patch the package, is going to be the one >>>> the bug is "assigned" to for the work item. As well, a single >>>> individiual triager may have to collaborate with other triagers in >>>> order to get the package to the "Triaged" state. I myself have >>>> collaborated with other bug controllers and bug triagers in order to >>>> get bugs moved along to a point where a developer can work on the >>>> bugs, and in most cases, I quite like that collaboration. That >>>> collaboration would then, in a sense, mean that all the triagers who >>>> have collaborated on it are "owners" of the bug for a triaging sense. >>>> Assigning one "triage owner" for a bug defeats the general idea of >>>> that collaboration of which myself and others are so fond of. >>>> >>>> Also, unless you're proposing changing the bug system to have an >>>> additional "Triage Owner" role and field on the bug and restricting >>>> "Triage Owner" to bug controllers who actually have the access that >>>> Bug Squad does not have (i.e. to set the "Triaged" state and the bug >>>> importance, as well as other bug-control specific tasks), the >>>> "Assigned To" field on bugs is used to identify who the work on fixing >>>> the bug is assigned to, not the triager. I still stand by this, >>>> because as one of the people primarily working on the nginx package >>>> now, I have seen people assign themselves to bugs and fix them, or >>>> assign themselves, and then hand me the work later, and reassigning it >>>> to me as the person who will fix it or SRU it or whatever. >>>> >>>> > >>>> > 2. Email volume reduction: >>>> > >>>> > Bug Triage members should only receive emails about bugs they're actively >>>> > assigned to. It's really time consuming to sort through hundreds of >>>> > bug-mails that involve bugs that are not relevant to ones currently being >>>> > worked on. This applies to all roles such as Testers, Reporters and others >>>> > as well. The only general emails that should be received should be from the >>>> > discussion or developer mailing lists. >>>> >>>> I'm confused here. As a Bug Squad member, I have received exactly 0 >>>> email addresses for subscribed bugs, in that the Bug Squad isn't >>>> subscribed to any bugs by default. As a Bug Control member, I see >>>> some crash bug data for which bugcontrol is subscribed to, or is a >>>> member of one of the teams subscribed. In comparison with the >>>> packages' bugs which I am specifically subscribed to, I've seen very >>>> few bug-control subscribed bug stuff, so I'm a little confused with >>>> this modification or concern. >>>> >>>> > >>>> > 3. Auto-assignment process queue: >>>> > >>>> > Similar to a tech-support ticket system the next step in this process would >>>> > be to introduce a process queue with auto-assignment of bugs to Bug Triage >>>> > members. I don't know how this would work but some status change in the bug >>>> > would have to trigger it's submission it into the process queue such as >>>> > reaching a Confirmed status or increased Reporter activity at some threshold >>>> > level. The distribution of the bugs would have to take into account the >>>> > work-load of the Bug Triage members and distribute them evenly but perhaps >>>> > that's a bit too complicated to do in code. Maybe random assignment would be >>>> > better or it could based on the package selection preferences of individual >>>> > members. Perhaps there could even be some senior Bug Control members who >>>> > would manually assign the bugs from the queue. This would eliminate the >>>> > need for Bug Triage members to even need to go to Launchpad to search for >>>> > bugs unless they're doing some extra research. Bugs would be sent to them >>>> > via email automatically when they're ready to be triaged and auto-assigned >>>> > without any extra steps needed. >>>> > >>>> > Conclusion: >>>> > >>>> > If the above steps were implemented or some equivalent processes I think the >>>> > Bug Triage would be streamlined, eliminate redundancy and get faster >>>> > turn-around times. Bug Triage members would be more focused and successful. >>>> > Newer Bug Triage members would be able to be "plugged in" to a standardized >>>> > process and this would improve retention because people would see results >>>> > faster with less effort. >>>> > >>>> > -------------------------------- >>>> > >>>> > Hopefully the feedback and ideas above can be tested in some form and >>>> > implemented. >>>> > >>>> > Best regards, >>>> > AG >>>> > >>>> > -- >>>> > Ubuntu-bugsquad mailing list >>>> > Ubuntu-bugsquad at lists.ubuntu.com >>>> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad >>>> > >>>> >>>> ------ >>>> Thomas >> >> >> -- >> Ubuntu-bugsquad mailing list >> Ubuntu-bugsquad at lists.ubuntu.com >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad I'm with Alberto on this, I disagree with all of these suggestions. Especially since none of these suggestions, from my point of view, add anything to the system and if anything add work for the triagers and also adds more work for the LP devs just to implement this. ----- Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2326 bytes Desc: not available URL: From teward at trekweb.org Tue Nov 5 18:46:39 2013 From: teward at trekweb.org (Thomas Ward) Date: Tue, 5 Nov 2013 13:46:39 -0500 Subject: This is a requested test message Message-ID: This message is a test sent at the request of one of the mailing list's admins, you may safely ignore this message. From andraz.bradesko at yahoo.com Tue Nov 5 20:43:25 2013 From: andraz.bradesko at yahoo.com (=?utf-8?B?QW5kcmHFviBCcmFkZcWha28=?=) Date: Tue, 5 Nov 2013 12:43:25 -0800 (PST) Subject: Bug Triage processes need some imwwwwpwrovement and automation... In-Reply-To: Message-ID: <1383684205.50535.YahooMailAndroidMobile@web140101.mail.bf1.yahoo.com> Sent from Yahoo Mail on Android -------------- next part -------------- An HTML attachment was scrubbed... URL: From ag.restringere at gmail.com Tue Nov 5 23:45:35 2013 From: ag.restringere at gmail.com (AG Restringere) Date: Tue, 5 Nov 2013 18:45:35 -0500 Subject: Bug Triage processes need some improvement and automation... Message-ID: Thomas, Let's look at that bug one more time: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1221304 Question: Who's triaging the bug right now? It could be: AG Restringere, Stephen Webb, Dave Vree, Stefan Sudin, Dan, John de Waal, Michael Madjic. I don't know from a quick glance at the bug. There's also no information telling me whether the bug is being actively triaged. You have the experience and knowledge to this answer immediately but those who are a new or not on the Bug Control/Squad team can't easily tell. This creates confusion and lack of clarity. Most of the time what stops me from working on a bug is that I can't immediately whose managing that bug and what they intend on doing with it. The Bug Triage person's intent is very important, because I don't know if that person intends on triaging the bug completely or they're just handling it temporarily and waiting for someone to finish it for them. Once again what I mean by "managing" is doing Bug Control/Squad related things with the bug and not fixing it or solving it. We can pretty easily know via the "Assigned To:" field which Developer, Maintainer or Packager is fixing a bug but we still don't have a field that tells us which Bug Control/Squad people are triaging that bug and what they're doing with it. Concerns: - How can it be made more obvious which Bug Control/Squad members are working on a bug? - How can some sort of status like "triaging" be made so it's known wether it's being actively triaged? - What filters can be put into Launchpad so a person can find bugs that are currently not being triaged by anyone on the team and whether it's being actively triaged? Once again thank you for taking these issues into consideration. Best regards, AG -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.park at canonical.com Wed Nov 6 00:12:17 2013 From: robert.park at canonical.com (Robert Park) Date: Tue, 5 Nov 2013 16:12:17 -0800 Subject: Bug Triage processes need some improvement and automation... In-Reply-To: References: Message-ID: On Tue, Nov 5, 2013 at 3:45 PM, AG Restringere wrote: > Question: Who's triaging the bug right now? Answer: You are *massively* overthinking the complexity of the bug triage process. > Most of the time what > stops me from working on a bug is that I can't immediately whose managing > that bug and what they intend on doing with it. The Bug Triage person's > intent is very important, because I don't know if that person intends on > triaging the bug completely or they're just handling it temporarily and > waiting for someone to finish it for them. I think you are absolutely 100% safe to assume in all cases that everybody is just handling it temporarily and it's safe for you to do the triage work on any bug you happen to find. This isn't like development work where if two people start writing code at the same time, then their branches will have merge conflicts when they go to submit their work. Bug triage is just a simple matter of "can I reproduce this? No? Set it to Incomplete and ask for more information then." It's quick, easy, anybody can do it, and we rely on the graciousness of volunteers. We don't want to burden them with extra meaningless paperwork here. There's no real measurable harm from two people triaging the same bug at the same time. > We can pretty easily know via the "Assigned To:" field which Developer, > Maintainer or Packager is fixing a bug but we still don't have a field that > tells us which Bug Control/Squad people are triaging that bug and what > they're doing with it. Trying to keep a 'Managed By' field up-to-date on our already-strained volunteer resources is just pointless busywork that will discourage people from contributing in helpful ways. > Concerns: > > How can it be made more obvious which Bug Control/Squad members are working > on a bug? > How can some sort of status like "triaging" be made so it's known wether > it's being actively triaged? > What filters can be put into Launchpad so a person can find bugs that are > currently not being triaged by anyone on the team and whether it's being > actively triaged? Don't worry about any of that, just triage the bug as if you are the #1 guy who can make a difference, because you are. From es20490446e at gmail.com Wed Nov 6 11:40:00 2013 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Wed, 06 Nov 2013 12:40:00 +0100 Subject: Bug Triage processes need some improvement and automation... In-Reply-To: References: Message-ID: <527A2A90.9070709@gmail.com> I will resume this: * On one hand is useful figuring if someone is working in the bug right now, for focusing in bugs which aren't having much attention. * On the other, you can always make great contribution to bugs that have people already working on it. El 06/11/13 01:12, Robert Park escribió: > On Tue, Nov 5, 2013 at 3:45 PM, AG Restringere wrote: >> Question: Who's triaging the bug right now? > Answer: You are *massively* overthinking the complexity of the bug > triage process. > >> Most of the time what >> stops me from working on a bug is that I can't immediately whose managing >> that bug and what they intend on doing with it. The Bug Triage person's >> intent is very important, because I don't know if that person intends on >> triaging the bug completely or they're just handling it temporarily and >> waiting for someone to finish it for them. > I think you are absolutely 100% safe to assume in all cases that > everybody is just handling it temporarily and it's safe for you to do > the triage work on any bug you happen to find. > > This isn't like development work where if two people start writing > code at the same time, then their branches will have merge conflicts > when they go to submit their work. Bug triage is just a simple matter > of "can I reproduce this? No? Set it to Incomplete and ask for more > information then." It's quick, easy, anybody can do it, and we rely on > the graciousness of volunteers. We don't want to burden them with > extra meaningless paperwork here. > > There's no real measurable harm from two people triaging the same bug > at the same time. > >> We can pretty easily know via the "Assigned To:" field which Developer, >> Maintainer or Packager is fixing a bug but we still don't have a field that >> tells us which Bug Control/Squad people are triaging that bug and what >> they're doing with it. > Trying to keep a 'Managed By' field up-to-date on our already-strained > volunteer resources is just pointless busywork that will discourage > people from contributing in helpful ways. > >> Concerns: >> >> How can it be made more obvious which Bug Control/Squad members are working >> on a bug? >> How can some sort of status like "triaging" be made so it's known wether >> it's being actively triaged? >> What filters can be put into Launchpad so a person can find bugs that are >> currently not being triaged by anyone on the team and whether it's being >> actively triaged? > Don't worry about any of that, just triage the bug as if you are the > #1 guy who can make a difference, because you are. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2260 bytes Desc: Firma criptográfica S/MIME URL: From nicholas.skaggs at canonical.com Wed Nov 6 18:16:17 2013 From: nicholas.skaggs at canonical.com (Nicholas Skaggs) Date: Wed, 06 Nov 2013 13:16:17 -0500 Subject: Quality vUDS Sessions In-Reply-To: <52790D43.2020704@canonical.com> References: <52790D43.2020704@canonical.com> Message-ID: <527A8771.3010000@canonical.com> Just a reminder, here are the currently scheduled vUDS sessions relating to quality. Quality sessions typically will occur on the community track. It was pointed out to me my original agenda for the roundtable was shall we say, "ambitous". So I pulled out almost all of the items into seperate sessions, so now we have several more. Here's the full list broken down by interest :-) *For folks involved with core apps;* Core apps test review, checking out what tests we have and what is still needed for each core app https://blueprints.launchpad.net/ubuntu/+spec/appdev-1311-core-apps-test-review Core apps testing workflow review; how can we keep tests green and running reliably? https://blueprints.launchpad.net/ubuntu/+spec/community-1311-coreapps-testing *For test writers;* Autopilot roundtable session, talking about what's new and what we need for ap 1.5, etc https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-autopilot-roundtable Let's get ubiquity autopilot tests running well this cycle and ensure the release process changes to incorporate them too! https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-autopilot-image-testing *For testers;* Let's talk about revamping calls for testing to let everyone in the community schedule there own :-) https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-calls-for-testing We want to be exploratory testing this cycle on all devices (pc, phone, tablet, etc)! https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-community-exploratory-testing *For developers;* Let's talk about papercuts for trusty! https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-papercuts A community inspired session on tweaking usb startup creator for trusty https://blueprints.launchpad.net/ubuntu/+spec/community-1311-ubuntu-usb-startup-creator *For everyone;* QA Community Roundtable, talking about the roles change, our big projects, and other things :-) https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-defining-workflows A blueprint for us to work out the details on merging bugsquad and qa community teams https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-bugsquad Nicholas -------------- next part -------------- An HTML attachment was scrubbed... URL: From es20490446e at gmail.com Wed Nov 6 11:36:07 2013 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Wed, 06 Nov 2013 12:36:07 +0100 Subject: Bug Triage processes need some improvement and automation... In-Reply-To: References: <5278DA5A.7010401@gmail.com> Message-ID: <527A29A7.9040403@gmail.com> If this feature is implemented, it can be done by just listing the members of specific teams that recently entered the bug; from teams like BugControl or administrator of the mother project. El 06/11/13 00:42, AG Restringere escribió: > Thomas, > > Let's look at that bug one more time: > https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1221304 > > Question: Who's triaging the bug right now? > > It could be: AG Restringere, Stephen Webb, Dave Vree, Stefan Sudin, > Dan, John de Waal, Michael Madjic. I don't know from a quick glance > at the bug. There's also no information telling me whether the bug is > being actively triaged. You have the experience and knowledge to this > answer immediately but those who are a new or not on the Bug > Control/Squad team can't easily tell. This creates confusion and lack > of clarity. Most of the time what stops me from working on a bug is > that I can't immediately whose managing that bug and what they intend > on doing with it. The Bug Triage person's intent is very important, > because I don't know if that person intends on triaging the bug > completely or they're just handling it temporarily and waiting for > someone to finish it for them. Once again what I mean by "managing" > is doing Bug Control/Squad related things with the bug and not fixing > it or solving it. > > We can pretty easily know via the "Assigned To:" field which > Developer, Maintainer or Packager is fixing a bug but we still don't > have a field that tells us which Bug Control/Squad people are triaging > that bug and what they're doing with it. > > Concerns: > > * How can it be made more obvious which Bug Control/Squad members > are working on a bug? > * How can some sort of status like "triaging" be made so it's known > wether it's being actively triaged? > * What filters can be put into Launchpad so a person can find bugs > that are currently not being triaged by anyone on the team and > whether it's being actively triaged? > > Once again thank you for taking these issues into consideration. > > Best regards, > AG > > > > > > > > > > > > > > > > > > On Tue, Nov 5, 2013 at 11:53 AM, Thomas Ward > wrote: > > > > > > *Sent from my iPhone. Please excuse any typos, as they are likely > to happen by accident.* > > On Nov 5, 2013, at 11:01 AM, AG Restringere > > wrote: > >> I have to (constructively) disagree with these suggestions: >> - With the first one because, although it's an improvement, >> it's just a *distraction* of what is really important now. >> - With the second one because of putting *barriers* in front >> of collaboration, one key of success. >> - With the point of view in general because forgetting >> *simplicity*, the ultimate goal of any system. >> >> >> Got it, understood, you don't want to alter the current >> processes, adding a "Managed By:" field and using it doesn't mean >> altering processes, it just provides additional information that >> reduces some uncertainty. >> >> Let's look at this recent bug I submitted to Launchpad: >> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1221304 >> >> Right now there are some bug comments from Stephen M. Webb >> (Bregma) indicating some sort of triage activity but there's >> nothing on the bug report letting me know if it's being actively >> triaged and by who. > > As it should be. Triaging is *not* managed by a single individual > for a bug, it's a community effort with everyone working together > to get the bug to where it can be worked on. > > Take any individual nginx bug in which I have had > sponsored-uploaded fixes for as an example, security bugs > included, or is currently marked as Triaged. Back when Debian > maintainers were working on it in Ubuntu, they were OK with it, > but were stumbling along on the triage process, and fixing bugs > like in Debian, but getting hung up on the 'version is stuck here' > stuff and not fixing all the bugs in Precise and other releases. > Then I come around and provide the Bug Squad knowledge needed. > That shifted the active triage to me from the Debian maintainers. > But I by no means am the only one triaging nginx bugs, there are > a few people who work on the bugs and add information or request > information. And there are times where I do hand off the bug to > Debian for them to fix, which means Debian is triaging it then, > and not myself. And while my name is likely on the debdiff I was > likely not the one who developed the fix. > >> This information should be clearly displayed on the bug report >> header. Here's a quick mock-up of that clearly describes what I >> would like to see on a bug report. >> >> --------------------------------------------------------- >> Bug #1221304 >> >> "Global app-menu is missing from panel..." >> >> *Reported by:* AG Restringere on 2013-09-05 /* >> who reported the bug? */ >> * >> * >> Affects: (the package information below) >> *Assigned to:* (Developers, Packagers, etc...to fix...) /* >> which developer or packager is fixing the bug? */ >> >> *Managed by:* Stephen M. Webb, Alberto Salvia Novella /* who is >> triaging the bug right now? */ > > Additional useless cruft because this cannot be auto assigned if, > say, twenty people comment on it. The system won't be able to > determine who is actually doing triage and who is just putting > "This affects me" and stuff, case in point any of a thousand > kernel bugs with such cases. > >> >> --------------------------------------------------------- >> >> The addition of this field would in no way alter current Bug >> Triage processes or methods that are currently in place, those >> would remain the same. This would just make it simple and clear >> what is going on with the bug without having to analyze comments. >> Then members could use the Launchpad search filters to find bugs >> don't have anyone managing them removing unnecessary complexity >> from the bug search process. This tool would simply be for >> informational purposes and everyone would still have access to >> the bug and be able to help triage it if they wanted to. > > But how would this improve the system? This just sounds like a > way to add more 'Minor feature request' stuff to the Launchpad > devs, and they more than likely are already inundated with minor > things that are being trumped by more major things. > > As well, the comments are there for a reason. A bug's 'state' of > being actively worked on hinges on comments and activity, not a > list of triagers. A sign of a good bug is a bug in which those > affected, those helping to triage, and those who can fix it are > all collaborating, and in those cases it wouldn't work to have a > list of those who are "triaging" the bug because it'd add more > work for bug supervisors to figure out who actually *is* triaging > while others are just commenting. > > This also adds to the complexity of the process of triaging > whether you personally think it does or not. The only way to > logically and feasibly apply this is if the 'triaged by' role only > picks up on comments by people on bug squad or bug control, and > ignores the others, or if the process is manually done and bug > controllers (who already have elevated permissions) are the only > ones who can set the status of who is triaging the bug, and that > too adds additional work to an already-pretty-simplistic system. > >> >> Best regards, >> AG >> >> >> On Tue, Nov 5, 2013 at 6:45 AM, Alberto Salvia Novella >> > wrote: >> >> I have to (constructively) disagree with these suggestions: >> >> - With the first one because, although it's an improvement, >> it's just a *distraction* of what is really important now. >> - With the second one because of putting *barriers* in front >> of collaboration, one key of success. >> - With the point of view in general because forgetting >> *simplicity*, the ultimate goal of any system. >> >> >> El 04/11/13 23:32, AG Restringere escribió: >>> >>> Bug Squad does not have (i.e. to set the "Triaged" state >>> and the bug >>> importance, as well as other bug-control specific >>> tasks), the >>> "Assigned To" field on bugs is used to identify who the >>> work on fixing >>> the bug is assigned to, not the triager. >>> >>> >>> Sorry, I didn't understand just how specific the usage of >>> the term "Assigned To:" is in Ubuntu. Given that in Ubuntu >>> the "Assigned To:" term/status is used specifically for >>> Developers and Packagers that will fix the bug then I am not >>> using a correct term. In that case a new term is needed to >>> avoid confusion. The better term would be a "Managed By:" >>> status because the Bug Triage person is managing the bug but >>> not fixing it. This would work in a similar way to "Assigned >>> To:" but it would apply to Bug Squad and Bug Control members >>> and not Developers or Packagers. The new status would make >>> it crystal clear which Bug Squad/Control member is managing >>> the bug and whether it's being actively managed. The >>> Launchpad bug-menu and search filters would have to be >>> modified to accommodate this and only Bug Squad/Control >>> members could have permissions over it is so the public >>> wouldn't use it by mistake. >>> >>> Assigning one "triage owner" for a bug defeats the >>> general idea of >>> that collaboration of which myself and others are so >>> fond of. >>> >>> >>> Collaboration could still be possible but there would be a >>> more systematic approach. Just because a bug is "Managed >>> By:" a single Bug Triage person and doesn't mean that they >>> can't ask other Bug Triage members for help, advice, to look >>> at a log, agree that a two bugs are duplicates, etc...It >>> just means that in the end of the day one single Bug Triage >>> person is making comments on the bug and that one person is >>> responsible for triaging it. Just take the number of open >>> non-triaged bugs and divide them by the number of Bug Triage >>> "staff" currently available, you'll most likely get a very >>> large quantity. Given the high level of interest that OEM's >>> and games developers have in Ubuntu you'll probably want to >>> ensure Bug Triage is as fast as possible. Unfortunately Bug >>> Triage is a limited resource, the team only has so much time >>> to work on a large number of bugs, so you'll have streamline >>> the process to make it faster. >>> >>> I'm confused here...(...)...In comparison with the >>> packages' bugs which I am specifically subscribed to, >>> I've seen very >>> few bug-control subscribed bug stuff, so I'm a little >>> confused with >>> this modification or concern. >>> >>> >>> Then this is something team specific that I will have to >>> bring to the attention of the Ubuntu-X team and I'll have to >>> see if there's a way they can tone down their bug volume or >>> if I can turn off my bug-mail for that specific team. >>> >>> All in all I don't know how "workable" these suggestions are >>> at this point and it is certainly a long-term process of >>> improvement that will have to be taken in small incremental >>> stage. The most important item in my view is to implement >>> the "Managed By:" tool/status and the "one bug one Triager" >>> system. >>> >>> Best regards, >>> AG >>> >>> >>> On Mon, Nov 4, 2013 at 4:15 PM, Thomas Ward >>> > wrote: >>> >>> Hey, AG, thanks for splitting this off into a separate >>> discussion. >>> >>> On Mon, Nov 4, 2013 at 3:54 PM, AG Restringere >>> >> > wrote: >>> > Re-posting my message to this list to create a new >>> thread about Bug Triage >>> > procedures. I've outlined some ideas that I think >>> would really improve the >>> > efficiency and clarity of Bug Triage operations. >>> > >>> > -------------------------------- >>> > >>> > In my experience in - when I dabbled in some bug >>> control work as part of the >>> > Ubuntu-X team - the Bug Triage process is still very >>> tedious and lacks >>> > sufficient automation. Most of the time and effort I >>> spent doing bug control >>> > work was spent browsing Launchpad and reading through >>> hundreds of bug-emails >>> > in order to find bugs to work on. Most of my time was >>> spent searching for >>> > bugs but very little of my time was spent actively >>> working on bugs and being >>> > productive. Also, many times I saw bugs that had >>> comments from Bug Control >>> > members but it was never clear who was working on the >>> bug or what they >>> > wanted to do with it. This often lead me to add >>> comments when they weren't >>> > needed or not contribute when a bug actually needed >>> attention and action. >>> > >>> > Modifications I would make to the Bug Triage process: >>> > >>> > 1. Assignment and eliminating redundancy: >>> > >>> > When a Bug Triager begins working on a bug they should >>> assign themselves to >>> > the bug on Launchpad if they intend to actively work >>> on it. Only one Bug >>> > Triage member should be assigned and actively working >>> on a bug at any given >>> > time and they should effectively "own" that bug and be >>> responsible for it. >>> > The only other people who should be working on that >>> specific bug should be >>> > Reporters, Testers and Developers. Assignment would >>> help other Bug Triage >>> > people to know "this bug is actively owned by another >>> member" and know to >>> > move on to other bugs and leave that one alone. It >>> would be even better if >>> > Launchpad could filter out the bugs that were actively >>> assigned to Bug >>> > Control members so people could find those that nobody >>> was working on and >>> > needed attention. Sufficient criteria for finding new >>> bugs could be as >>> > simple as "Confirmed"+"Unassigned". >>> >>> I am against this suggestion as it stands, maybe because >>> I do not >>> understand your reasoning for it or the potential >>> execution of this, >>> but also because there needs to be made a distinction, >>> in my opinion, >>> between the role of Bug Triager and the role of "Package >>> Fixer" (for >>> lack of a better term, this would be someone with the >>> package >>> knowledge and development knowledge to fix the bugs once >>> they're >>> "Triaged"). >>> >>> A triager may help get the bug from New to Triaged or New to >>> Confirmed, but ultimately someone with developer >>> knowledge of the >>> package, or the knowledge to patch the package, is going >>> to be the one >>> the bug is "assigned" to for the work item. As well, a >>> single >>> individiual triager may have to collaborate with other >>> triagers in >>> order to get the package to the "Triaged" state. I >>> myself have >>> collaborated with other bug controllers and bug triagers >>> in order to >>> get bugs moved along to a point where a developer can >>> work on the >>> bugs, and in most cases, I quite like that >>> collaboration. That >>> collaboration would then, in a sense, mean that all the >>> triagers who >>> have collaborated on it are "owners" of the bug for a >>> triaging sense. >>> Assigning one "triage owner" for a bug defeats the >>> general idea of >>> that collaboration of which myself and others are so >>> fond of. >>> >>> Also, unless you're proposing changing the bug system to >>> have an >>> additional "Triage Owner" role and field on the bug and >>> restricting >>> "Triage Owner" to bug controllers who actually have the >>> access that >>> Bug Squad does not have (i.e. to set the "Triaged" state >>> and the bug >>> importance, as well as other bug-control specific >>> tasks), the >>> "Assigned To" field on bugs is used to identify who the >>> work on fixing >>> the bug is assigned to, not the triager. I still stand >>> by this, >>> because as one of the people primarily working on the >>> nginx package >>> now, I have seen people assign themselves to bugs and >>> fix them, or >>> assign themselves, and then hand me the work later, and >>> reassigning it >>> to me as the person who will fix it or SRU it or whatever. >>> >>> > >>> > 2. Email volume reduction: >>> > >>> > Bug Triage members should only receive emails about >>> bugs they're actively >>> > assigned to. It's really time consuming to sort >>> through hundreds of >>> > bug-mails that involve bugs that are not relevant to >>> ones currently being >>> > worked on. This applies to all roles such as Testers, >>> Reporters and others >>> > as well. The only general emails that should be >>> received should be from the >>> > discussion or developer mailing lists. >>> >>> I'm confused here. As a Bug Squad member, I have >>> received exactly 0 >>> email addresses for subscribed bugs, in that the Bug >>> Squad isn't >>> subscribed to any bugs by default. As a Bug Control >>> member, I see >>> some crash bug data for which bugcontrol is subscribed >>> to, or is a >>> member of one of the teams subscribed. In comparison >>> with the >>> packages' bugs which I am specifically subscribed to, >>> I've seen very >>> few bug-control subscribed bug stuff, so I'm a little >>> confused with >>> this modification or concern. >>> >>> > >>> > 3. Auto-assignment process queue: >>> > >>> > Similar to a tech-support ticket system the next step >>> in this process would >>> > be to introduce a process queue with auto-assignment >>> of bugs to Bug Triage >>> > members. I don't know how this would work but some >>> status change in the bug >>> > would have to trigger it's submission it into the >>> process queue such as >>> > reaching a Confirmed status or increased Reporter >>> activity at some threshold >>> > level. The distribution of the bugs would have to take >>> into account the >>> > work-load of the Bug Triage members and distribute >>> them evenly but perhaps >>> > that's a bit too complicated to do in code. Maybe >>> random assignment would be >>> > better or it could based on the package selection >>> preferences of individual >>> > members. Perhaps there could even be some senior Bug >>> Control members who >>> > would manually assign the bugs from the queue. This >>> would eliminate the >>> > need for Bug Triage members to even need to go to >>> Launchpad to search for >>> > bugs unless they're doing some extra research. Bugs >>> would be sent to them >>> > via email automatically when they're ready to be >>> triaged and auto-assigned >>> > without any extra steps needed. >>> > >>> > Conclusion: >>> > >>> > If the above steps were implemented or some equivalent >>> processes I think the >>> > Bug Triage would be streamlined, eliminate redundancy >>> and get faster >>> > turn-around times. Bug Triage members would be more >>> focused and successful. >>> > Newer Bug Triage members would be able to be "plugged >>> in" to a standardized >>> > process and this would improve retention because >>> people would see results >>> > faster with less effort. >>> > >>> > -------------------------------- >>> > >>> > Hopefully the feedback and ideas above can be tested >>> in some form and >>> > implemented. >>> > >>> > Best regards, >>> > AG >>> > >>> > -- >>> > Ubuntu-bugsquad mailing list >>> > Ubuntu-bugsquad at lists.ubuntu.com >>> >>> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad >>> > >>> >>> ------ >>> Thomas >>> >>> >>> >>> >> >> >> -- >> Ubuntu-bugsquad mailing list >> Ubuntu-bugsquad at lists.ubuntu.com >> >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad >> >> >> -- >> Ubuntu-bugsquad mailing list >> Ubuntu-bugsquad at lists.ubuntu.com >> >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > I'm with Alberto on this, I disagree with all of these suggestions. > > Especially since none of these suggestions, from my point of view, > add anything to the system and if anything add work for the > triagers and also adds more work for the LP devs just to implement > this. > > ----- > Thomas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2260 bytes Desc: Firma criptográfica S/MIME URL: From ag.restringere at gmail.com Wed Nov 6 18:50:34 2013 From: ag.restringere at gmail.com (AG Restringere) Date: Wed, 6 Nov 2013 13:50:34 -0500 Subject: Bug triage activity summary on bug reports (Launchpad)... Message-ID: Robert Park: Thank you for the point by point response, yes now I'll feel free to jump in on as many bugs as I can even if others are currently working on them. I'll know the help is always appreciated. Bug-triage is a more free-flowing collaborative process that just builds. Got it. > Alberto Salvia Novella: > > If this feature is implemented, it can be done by just listing the members > of specific teams that recently entered the bug; from teams like BugControl > or administrator of the mother project. > Exactly, like a "Bug Triage" activity report summary: Whenever a person on the Bug Control/Squad team is creating activity on a bug-report Launchpad should automatically write few brief notes somewhere about this and if activity dies down for a while like for 15 or 30 days it should say "no recent activity". It should also provide a list of names of the people "triaging" the bug. This should be searchable so we could find bugs that have low Bug Triage activity and need attention. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ubuntu at treblig.org Wed Nov 6 18:39:01 2013 From: ubuntu at treblig.org (Dr. David Alan Gilbert) Date: Wed, 6 Nov 2013 18:39:01 +0000 Subject: Bug triage activity summary on bug reports (Launchpad)... In-Reply-To: References: Message-ID: <20131106183901.GB8258@gallifrey> * AG Restringere (ag.restringere at gmail.com) wrote: > Robert Park: Thank you for the point by point response, yes now I'll feel > free to jump in on as many bugs as I can even if others are currently > working on them. I'll know the help is always appreciated. Bug-triage is a > more free-flowing collaborative process that just builds. Got it. The only thing I'd be careful of is to try not to confuse the reporter; if a triager has asked the reporter to do something then I'd be a little bit more careful - i.e. I might ask 'can you also get this at the same time' but I'd be careful not to confuse things. I'd also not generally go changing statuses if it was assigned to someone. > > Alberto Salvia Novella: > > > > If this feature is implemented, it can be done by just listing the members > > of specific teams that recently entered the bug; from teams like BugControl > > or administrator of the mother project. > > > Exactly, like a "Bug Triage" activity report summary: > > Whenever a person on the Bug Control/Squad team is creating activity on a > bug-report Launchpad should automatically write few brief notes somewhere > about this and if activity dies down for a while like for 15 or 30 days it > should say "no recent activity". It should also provide a list of names of > the people "triaging" the bug. This should be searchable so we could find > bugs that have low Bug Triage activity and need attention. It already creates a full history. Dave -- -----Open up your eyes, open up your mind, open up your code ------- / Dr. David Alan Gilbert | Running GNU/Linux | Happy \ \ gro.gilbert @ treblig.org | | In Hex / \ _________________________|_____ http://www.treblig.org |_______/ From ag.restringere at gmail.com Wed Nov 6 19:08:02 2013 From: ag.restringere at gmail.com (AG Restringere) Date: Wed, 6 Nov 2013 14:08:02 -0500 Subject: Bug triage activity summary on bug reports (Launchpad)... In-Reply-To: <20131106183901.GB8258@gallifrey> References: <20131106183901.GB8258@gallifrey> Message-ID: > > It [Launchpad] already creates a full history. There are some drawbacks to that: 1. It doesn't tell me which Bug Control/Squad team members are creating activity on the bug. 2. The "summary" button is at the bottom of the page and on really long bug reports I wont even notice it's there, it also opens up to a separate web-page which takes me away from the bug-report. 3. It provides too much information, when all I needed was a brief summary. 4. It doesn't create anything useful that can be made searchable. The "activity summary" would: 1. Tell me which Bug Control/Squad team members are creating activity on the bug. 2. Be located at the very top of of the bug report in the header on top side-bar so I can see it immediately, it would be on the same page as the bug-report. 3. Provide just a brief summary of triage activity, not a full list of actions. 4. Create bug triage activity data that can be searchable via Launchpad so I can find bugs that aren't getting enough attention. This is also really valuable for other reasons like analysis and getting an overall visualization on bug activity. On Wed, Nov 6, 2013 at 1:39 PM, Dr. David Alan Gilbert wrote: > * AG Restringere (ag.restringere at gmail.com) wrote: > > Robert Park: Thank you for the point by point response, yes now I'll feel > > free to jump in on as many bugs as I can even if others are currently > > working on them. I'll know the help is always appreciated. Bug-triage > is a > > more free-flowing collaborative process that just builds. Got it. > > The only thing I'd be careful of is to try not to confuse the reporter; > if a triager has asked the reporter to do something then I'd be a little > bit more careful - i.e. I might ask 'can you also get this at the same > time' > but I'd be careful not to confuse things. > > I'd also not generally go changing statuses if it was assigned to someone. > > > > Alberto Salvia Novella: > > > > > > If this feature is implemented, it can be done by just listing the > members > > > of specific teams that recently entered the bug; from teams like > BugControl > > > or administrator of the mother project. > > > > > Exactly, like a "Bug Triage" activity report summary: > > > > Whenever a person on the Bug Control/Squad team is creating activity on a > > bug-report Launchpad should automatically write few brief notes somewhere > > about this and if activity dies down for a while like for 15 or 30 days > it > > should say "no recent activity". It should also provide a list of names > of > > the people "triaging" the bug. This should be searchable so we could > find > > bugs that have low Bug Triage activity and need attention. > > It already creates a full history. > > Dave > > -- > -----Open up your eyes, open up your mind, open up your code ------- > / Dr. David Alan Gilbert | Running GNU/Linux | Happy \ > \ gro.gilbert @ treblig.org | | In Hex / > \ _________________________|_____ http://www.treblig.org |_______/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ubuntu at treblig.org Wed Nov 6 19:41:01 2013 From: ubuntu at treblig.org (Dr. David Alan Gilbert) Date: Wed, 6 Nov 2013 19:41:01 +0000 Subject: Bug triage activity summary on bug reports (Launchpad)... In-Reply-To: References: <20131106183901.GB8258@gallifrey> Message-ID: <20131106194101.GC8258@gallifrey> * AG Restringere (ag.restringere at gmail.com) wrote: > > > > It [Launchpad] already creates a full history. > > > There are some drawbacks to that: > > 1. It doesn't tell me which Bug Control/Squad team members are creating > activity on the bug. > 2. The "summary" button is at the bottom of the page and on really long > bug reports I wont even notice it's there, it also opens up to a separate > web-page which takes me away from the bug-report. > 3. It provides too much information, when all I needed was a brief > summary. > 4. It doesn't create anything useful that can be made searchable. So you're saying too little and too much information? It sure looks like it contains a full list of activity; now I admit maybe it would be nice to change the icons to show if they're BC/BS members? The activity log seems to show up to search engines, so that's about as good search as you get. > The "activity summary" would: > > 1. Tell me which Bug Control/Squad team members are creating activity on > the bug. > 2. Be located at the very top of of the bug report in the header on top > side-bar so I can see it immediately, it would be on the same page as the > bug-report. > 3. Provide just a brief summary of triage activity, not a full list of > actions. > 4. Create bug triage activity data that can be searchable via Launchpad > so I can find bugs that aren't getting enough attention. This is also > really valuable for other reasons like analysis and getting an overall > visualization on bug activity. You seem to be asking for something specific to your preferences. If you want this functionality I suggest you file a bug against LP itself, specifying what you want and let it get triaged by the LP guys; mention the bug number and we can add comments if people agree etc. (I think you'll find they tell you LP is in maintenance only) - of course you could try submitting a patch. Dave -- -----Open up your eyes, open up your mind, open up your code ------- / Dr. David Alan Gilbert | Running GNU/Linux | Happy \ \ gro.gilbert @ treblig.org | | In Hex / \ _________________________|_____ http://www.treblig.org |_______/ From es20490446e at gmail.com Wed Nov 6 20:02:56 2013 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Wed, 06 Nov 2013 21:02:56 +0100 Subject: Bug triage activity summary on bug reports (Launchpad)... In-Reply-To: References: <20131106183901.GB8258@gallifrey> Message-ID: <527AA070.7030706@gmail.com> If it brief, perhaps it isn't that bad. El 06/11/13 20:08, AG Restringere escribió: > > It [Launchpad] already creates a full history. > > > There are some drawbacks to that: > > 1. It doesn't tell me which Bug Control/Squad team members are > creating activity on the bug. > 2. The "summary" button is at the bottom of the page and on really > long bug reports I wont even notice it's there, it also opens up > to a separate web-page which takes me away from the bug-report. > 3. It provides too much information, when all I needed was a brief > summary. > 4. It doesn't create anything useful that can be made searchable. > > The "activity summary" would: > > 1. Tell me which Bug Control/Squad team members are creating activity > on the bug. > 2. Be located at the very top of of the bug report in the header on > top side-bar so I can see it immediately, it would be on the same > page as the bug-report. > 3. Provide just a brief summary of triage activity, not a full list > of actions. > 4. Create bug triage activity data that can be searchable via > Launchpad so I can find bugs that aren't getting enough attention. > This is also really valuable for other reasons like analysis and > getting an overall visualization on bug activity. > > > > > On Wed, Nov 6, 2013 at 1:39 PM, Dr. David Alan Gilbert > > wrote: > > * AG Restringere (ag.restringere at gmail.com > ) wrote: > > Robert Park: Thank you for the point by point response, yes now > I'll feel > > free to jump in on as many bugs as I can even if others are > currently > > working on them. I'll know the help is always appreciated. > Bug-triage is a > > more free-flowing collaborative process that just builds. Got it. > > The only thing I'd be careful of is to try not to confuse the > reporter; > if a triager has asked the reporter to do something then I'd be a > little > bit more careful - i.e. I might ask 'can you also get this at the > same time' > but I'd be careful not to confuse things. > > I'd also not generally go changing statuses if it was assigned to > someone. > > > > Alberto Salvia Novella: > > > > > > If this feature is implemented, it can be done by just listing > the members > > > of specific teams that recently entered the bug; from teams > like BugControl > > > or administrator of the mother project. > > > > > Exactly, like a "Bug Triage" activity report summary: > > > > Whenever a person on the Bug Control/Squad team is creating > activity on a > > bug-report Launchpad should automatically write few brief notes > somewhere > > about this and if activity dies down for a while like for 15 or > 30 days it > > should say "no recent activity". It should also provide a list > of names of > > the people "triaging" the bug. This should be searchable so we > could find > > bugs that have low Bug Triage activity and need attention. > > It already creates a full history. > > Dave > > -- > -----Open up your eyes, open up your mind, open up your code ------- > / Dr. David Alan Gilbert | Running GNU/Linux | Happy \ > \ gro.gilbert @ treblig.org | > | In Hex / > \ _________________________|_____ http://www.treblig.org |_______/ > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2260 bytes Desc: Firma criptográfica S/MIME URL: From ag.restringere at gmail.com Wed Nov 6 21:39:22 2013 From: ag.restringere at gmail.com (AG Restringere) Date: Wed, 6 Nov 2013 16:39:22 -0500 Subject: Bug triage activity summary on bug reports (Launchpad)... Message-ID: > > If it brief, perhaps it isn't that bad. *1. Bug triage activity summary in bug reports:* It would be very brief, just a listing the Bug Control/Squad members and brief summary with just a few words located at the top of the report: reference: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1221304 > *Bug Squad/Control: bregma , ag-restringere > **Triage activity: *3 days ago, > "recent" If the bug hasn't had any triage activity for at least 30 days and it needs attention from the Bug Squad/Control the field will change to this: > *Bug Squad/Control: bregma , ag-restringere > **Triage activity: *36 days ago,* > "*needs attention" *2. Launchpad bug search additions:* In the Launchpad Bug Search tool, you would see a single additional item the search options in the Advanced Search menu: reference: https://bugs.launchpad.net/ubuntu/+bugs?advanced=1 > *Bug Control/Squad:**[] "needs attention"* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ag.restringere at gmail.com Wed Nov 6 21:44:53 2013 From: ag.restringere at gmail.com (AG Restringere) Date: Wed, 6 Nov 2013 16:44:53 -0500 Subject: Bug triage activity summary on bug reports (Launchpad)... In-Reply-To: References: Message-ID: REPOST: gmail formatting got messed up by the mailing list software and many people using non-gmail systems may see it as really messed up, sorry. If it brief, perhaps it isn't that bad. *1. Bug triage activity summary in bug reports:* It would be very brief, just a listing the Bug Control/Squad members and brief summary with just a few words located at the top of the report: reference: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1221304 *Bug Squad/Control: *bregma, ag-restringere // These would be hyperlinked to their Launchpad-ID page *Triage activity: *3 days ago, "recent" If the bug hasn't had any triage activity for at least 30 days and it needs attention from the Bug Squad/Control the field will change to this: *Bug Squad/Control: *bregma, ag-restringere *Triage activity: *36 days ago,* "*needs attention" *2. Launchpad bug search additions:* In the Launchpad Bug Search tool, you would see a single additional item the search options in the Advanced Search menu: reference: https://bugs.launchpad.net/ubuntu/+bugs?advanced=1 *Bug Control/Squad:* *[] "needs attention"* On Wed, Nov 6, 2013 at 4:39 PM, AG Restringere wrote: > If it brief, perhaps it isn't that bad. > > > *1. Bug triage activity summary in bug reports:* > > It would be very brief, just a listing the Bug Control/Squad members and > brief summary with just a few words located at the top of the report: > > reference: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1221304 > > >> *Bug Squad/Control: bregma >> , ag-restringere >> **Triage activity: *3 days ago, >> "recent" > > > If the bug hasn't had any triage activity for at least 30 days and it > needs attention from the Bug Squad/Control the field will change to this: > > >> *Bug Squad/Control: bregma >> , ag-restringere >> **Triage activity: *36 days ago,* >> "*needs attention" > > > *2. Launchpad bug search additions:* > > In the Launchpad Bug Search tool, you would see a single additional item > the search options in the Advanced Search menu: > > reference: https://bugs.launchpad.net/ubuntu/+bugs?advanced=1 > > >> *Bug Control/Squad:**[] "needs attention"* > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From es20490446e at gmail.com Thu Nov 7 12:39:07 2013 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Thu, 07 Nov 2013 13:39:07 +0100 Subject: Bug triage activity summary on bug reports (Launchpad)... In-Reply-To: References: Message-ID: <527B89EB.4080108@gmail.com> For me, it sounds interesting. Sometimes I find myself looking for some way to realize this same information. El 06/11/13 22:39, AG Restringere escribió: > > If it brief, perhaps it isn't that bad. > > > *1. Bug triage activity summary in bug reports:* > > It would be very brief, just a listing the Bug Control/Squad > members and brief summary with just a few words located at the top > of the report: > > reference: > https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1221304 > > *Bug Squad/Control: bregma , > ag-restringere > **Triage activity: *3 > days ago, "recent" > > > If the bug hasn't had any triage activity for at least 30 days and > it needs attention from the Bug Squad/Control the field will > change to this: > > *Bug Squad/Control: bregma , > ag-restringere > **Triage activity: > *36 days ago,*"*needs attention" > > > *2. Launchpad bug search additions:* > > In the Launchpad Bug Search tool, you would see a single > additional item the search options in the Advanced Search menu: > > reference: https://bugs.launchpad.net/ubuntu/+bugs?advanced=1 > > *Bug Control/Squad: > **[] "needs attention"* > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From es20490446e at gmail.com Thu Nov 7 16:53:17 2013 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Thu, 07 Nov 2013 17:53:17 +0100 Subject: "One Hundred Papercuts" is having a submit Message-ID: <527BC57D.2000809@gmail.com> ♥ One Hundred Papercuts *Papercuts are easily fixable but very annoying bugs.** **Our mission is to improve the user experience in Ubuntu by reducing them.* We'll be having a submit at "*Thursday 15:05 - 16:00 UTC*" on . This will be interesting for you if you want: - To meet *people* involved. - To share ideas on how to reduce *papercuts*. - To share ideas about how to make Ubuntu community *accessible* to all kinds of people. Thank you ♥ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Banner.svg Type: image/svg+xml Size: 23546 bytes Desc: not available URL: From ag.restringere at gmail.com Thu Nov 7 21:37:19 2013 From: ag.restringere at gmail.com (AG Restringere) Date: Thu, 7 Nov 2013 16:37:19 -0500 Subject: Bug triage activity summary on bug reports (Launchpad)... In-Reply-To: <527B89EB.4080108@gmail.com> References: <527B89EB.4080108@gmail.com> Message-ID: What is the next step for this? Ideally I would want to do this through the Bug Squad/Control but since it's more of a Launchpad thing what should I do? Please let me know... On Thu, Nov 7, 2013 at 7:39 AM, Alberto Salvia Novella < es20490446e at gmail.com> wrote: > For me, it sounds interesting. Sometimes I find myself looking for some > way to realize this same information. > > > El 06/11/13 22:39, AG Restringere escribió: > > If it brief, perhaps it isn't that bad. > > > *1. Bug triage activity summary in bug reports:* > > It would be very brief, just a listing the Bug Control/Squad members and > brief summary with just a few words located at the top of the report: > > reference: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1221304 > > >> *Bug Squad/Control: bregma >> , ag-restringere >> **Triage activity: *3 days ago, >> "recent" > > > If the bug hasn't had any triage activity for at least 30 days and it > needs attention from the Bug Squad/Control the field will change to this: > > >> *Bug Squad/Control: bregma >> , ag-restringere >> **Triage activity: *36 days ago,* >> "*needs attention" > > > *2. Launchpad bug search additions:* > > In the Launchpad Bug Search tool, you would see a single additional item > the search options in the Advanced Search menu: > > reference: https://bugs.launchpad.net/ubuntu/+bugs?advanced=1 > > >> *Bug Control/Squad: **[] "needs attention"* > > > > > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.park at canonical.com Thu Nov 7 21:39:39 2013 From: robert.park at canonical.com (Robert Park) Date: Thu, 7 Nov 2013 13:39:39 -0800 Subject: Bug triage activity summary on bug reports (Launchpad)... In-Reply-To: References: <527B89EB.4080108@gmail.com> Message-ID: On Thu, Nov 7, 2013 at 1:37 PM, AG Restringere wrote: > What is the next step for this? Ideally I would want to do this through the > Bug Squad/Control but since it's more of a Launchpad thing what should I do? > Please let me know... The next step for this is to branch lp:launchpad and start submitting patches. From brian at ubuntu.com Thu Nov 7 21:56:34 2013 From: brian at ubuntu.com (Brian Murray) Date: Thu, 7 Nov 2013 13:56:34 -0800 Subject: Bug triage activity summary on bug reports (Launchpad)... In-Reply-To: References: Message-ID: <20131107215634.GM23498@murraytwins.com> On Wed, Nov 06, 2013 at 01:50:34PM -0500, AG Restringere wrote: > Robert Park: Thank you for the point by point response, yes now I'll feel > free to jump in on as many bugs as I can even if others are currently > working on them. I'll know the help is always appreciated. Bug-triage is a > more free-flowing collaborative process that just builds. Got it. > > > Alberto Salvia Novella: > > > > If this feature is implemented, it can be done by just listing the members > > of specific teams that recently entered the bug; from teams like BugControl > > or administrator of the mother project. > > > Exactly, like a "Bug Triage" activity report summary: > > Whenever a person on the Bug Control/Squad team is creating activity on a > bug-report Launchpad should automatically write few brief notes somewhere > about this and if activity dies down for a while like for 15 or 30 days it > should say "no recent activity". It should also provide a list of names of > the people "triaging" the bug. This should be searchable so we could find > bugs that have low Bug Triage activity and need attention. I realize that this don't meet your exact needs, but given that Launchpad is in maintenance mode and patching it can be hard, I thought this information would be useful. If activity is created on the bug because the bug is missing sufficient information for it to be recreated (status Confirmed), or for it to be worked on by a developer (status Triaged), then the bug task's status should be Incomplete. If a bug only has one task and that task is set to Incomplete then the bug is eligible for expiration[1]. Bugs that have seen "no recent activity" will expire after 60 days. You can find a list of bugs that can expire here: https://bugs.launchpad.net/ubuntu/+expirable-bugs [1] https://help.launchpad.net/BugExpiry -- Brian Murray Ubuntu Bug Master From brian at ubuntu.com Thu Nov 7 22:14:10 2013 From: brian at ubuntu.com (Brian Murray) Date: Thu, 7 Nov 2013 14:14:10 -0800 Subject: Bug Triage processes need some improvement and automation... In-Reply-To: References: Message-ID: <20131107221410.GN23498@murraytwins.com> On Mon, Nov 04, 2013 at 03:54:55PM -0500, AG Restringere wrote: > Re-posting my message to this list to create a new thread about Bug Triage > procedures. I've outlined some ideas that I think would really improve the > efficiency and clarity of Bug Triage operations. > > -------------------------------- > > In my experience in - when I dabbled in some bug control work as part of > the Ubuntu-X team - the Bug Triage process is still very tedious and lacks > sufficient automation. Most of the time and effort I spent doing bug > control work was spent browsing Launchpad and reading through hundreds of > bug-emails in order to find bugs to work on. Most of my time was spent > searching for bugs but very little of my time was spent actively working on > bugs and being productive. Also, many times I saw bugs that had comments > from Bug Control members but it was never clear who was working on the bug > or what they wanted to do with it. This often lead me to add comments when > they weren't needed or not contribute when a bug actually needed attention > and action. What types of bugs did you have difficultly searching for? > Modifications I would make to the Bug Triage process: > > 1. Assignment and eliminating redundancy: > > When a Bug Triager begins working on a bug they should assign themselves to > the bug on Launchpad if they intend to actively work on it. Only one Bug > Triage member should be assigned and actively working on a bug at any given > time and they should effectively "own" that bug and be responsible for it. > The only other people who should be working on that specific bug should be > Reporters, Testers and Developers. Assignment would help other Bug Triage > people to know "this bug is actively owned by another member" and know to > move on to other bugs and leave that one alone. It would be even better if > Launchpad could filter out the bugs that were actively assigned to Bug > Control members so people could find those that nobody was working on and > needed attention. Sufficient criteria for finding new bugs could be as > simple as "Confirmed"+"Unassigned". In the scenario where a Bug Triager is working on a bug in what state is the bug report? If it is missing information then it should have a status of Incomplete and having the bug assigned would prevent it from expiring. Bug expiration is a useful thing because we frequently have bug reporter who have a "fire and forget" attitude and do not respond to questions for more information. > 2. Email volume reduction: > > Bug Triage members should only receive emails about bugs they're actively > assigned to. It's really time consuming to sort through hundreds of > bug-mails that involve bugs that are not relevant to ones currently being > worked on. This applies to all roles such as Testers, Reporters and others > as well. The only general emails that should be received should be from > the discussion or developer mailing lists. Launchpad generally sends e-mails to people assigned to or subscribed to bug reports. If someone is receiving a high volume of email this is due to a subscription that they, or a team of which they are a member, have setup. So not everyone has to receive hundreds of bug mails. This wiki page is really helpful for filtering Launchpad mail: https://wiki.ubuntu.com/Bugs/HowToFilter > 3. Auto-assignment process queue: > > Similar to a tech-support ticket system the next step in this process would > be to introduce a process queue with auto-assignment of bugs to Bug Triage > members. I don't know how this would work but some status change in the > bug would have to trigger it's submission it into the process queue such as > reaching a Confirmed status or increased Reporter activity at some > threshold level. The distribution of the bugs would have to take into > account the work-load of the Bug Triage members and distribute them evenly > but perhaps that's a bit too complicated to do in code. Maybe random > assignment would be better or it could based on the package selection > preferences of individual members. Perhaps there could even be some senior > Bug Control members who would manually assign the bugs from the queue. > This would eliminate the need for Bug Triage members to even need to go to > Launchpad to search for bugs unless they're doing some extra research. > Bugs would be sent to them via email automatically when they're ready to > be triaged and auto-assigned without any extra steps needed. I think that given the quantity of bugs reported on a daily basis and the number of people actively triaging bug reports we'd quickly end up overwhelmed and demotivated. I believe we talked about this idea once before and I'd suggested trying the process of assigning bugs to yourself as an experiment. Did you end up doing that? -- Brian Murray Ubuntu Bug Master From dtl131 at gmail.com Thu Nov 7 22:27:00 2013 From: dtl131 at gmail.com (Daniel Letzeisen) Date: Thu, 07 Nov 2013 17:27:00 -0500 Subject: Bug triage activity summary on bug reports (Launchpad)... In-Reply-To: <20131107215634.GM23498@murraytwins.com> References: <20131107215634.GM23498@murraytwins.com> Message-ID: <527C13B4.30301@gmail.com> On 11/07/2013 04:56 PM, Brian Murray wrote: > I realize that this don't meet your exact needs, but given that > Launchpad is in maintenance mode and patching it can be hard, I > thought this information would be useful. If activity is created on > the bug because the bug is missing sufficient information for it to be > recreated (status Confirmed), or for it to be worked on by a developer > (status Triaged), then the bug task's status should be Incomplete. If > a bug only has one task and that task is set to Incomplete then the > bug is eligible for expiration[1]. Bugs that have seen "no recent > activity" will expire after 60 days. You can find a list of bugs that > can expire here: https://bugs.launchpad.net/ubuntu/+expirable-bugs [1] > https://help.launchpad.net/BugExpiry -- Brian Murray Ubuntu Bug Master I respectfully disagree with AG Restringere's proposal. I believe it over-complicates things and will create more work for BugSquad members. Getting a bug to the Triaged state is a collaborative process (requesting information, researching upstream, etc.). Also, if development effort is going to be put into Launchpad, I think there are more important/fundamental changes that can be made which I and C de-Avillez/hggdh have expounded in previous postings (see: "What We Learned From Bug Day"). From ag.restringere at gmail.com Thu Nov 7 23:06:28 2013 From: ag.restringere at gmail.com (AG Restringere) Date: Thu, 7 Nov 2013 18:06:28 -0500 Subject: Bug Triage processes need some improvement and automation (Bug triage activity summary)... Message-ID: @ Brian Murray, I've shelved and retracted the previous proposal after some discussion on the Bug-Squad mailing list. The process I was proposing was simply diametrically opposed to the current Bug Squad/Control processes and would not actually work as intended in actual application. However I did "drill down" to the problem that I had and it turned out to be a problem with what kind of data is displayed on actual bug reports in Launchpad and making that data more searchable. It's not a process problem, it's a data display and search issue. > What types of bugs did you have difficultly searching for? Yes, Launchpad has loads of detailed search items available but the problem with looking at bugs about to expire is that these are bugs that I should NOT be looking at, it's better to let them expire like you said. True I could see if they are Incomplete but that would mean that Bug Triage has already done their job and is just waiting for the Reporter. The bugs I want to find are ones with multiple Reporters are Confirmed and fresh but aren't getting any attention from Bug Triage or not enough attention. This the area where I could really jump in a "pick up the slack". There doesn't seem to be a way to search for bugs that have low "bug triage" activity because Launchpad just records everyone's activity and only reports generic information. That is activity from Reporters, Developers, Packagers and Bug Control/Squad members, everyone, but it doesn't separate out or filter just activity from Bug Control/Squad. The minor feature I am proposing for Launchpad seeks to display information that is relevant only to Bug Squad/Control and to help summarize some of that activity as well as the relevant ID's of the Bug Triage people active on a bug. Then to make this searchable in a way that is useful. I've worked out that the only additional information that needs to be put on a bug-report is: 1. Bug triage activity summary on bug-reports: It would be very brief, just a listing the Bug Control/Squad members and brief summary with just a few words located at the top of the report, please note the Launchapd ID's would be URL links to the Bug Triage members Launchpad page: reference: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1221304 > Bug Squad/Control: *bregma*, *ag-restringere* > Triage activity: 3 days ago, "recent" If the bug hasn't had any triage activity for at least 30 days and it needs attention from the Bug Squad/Control and the field will change to this: > Bug Squad/Control: *bregma*, *ag-restringere* > Triage activity: 36 days ago, "needs attention" 2. Launchpad bug search additions: In the Launchpad Bug Search tool, you would see a single additional item the search options in the Advanced Search menu, days are list so you can be more specific in the search because this would be more useful: reference: https://bugs.launchpad.net/ubuntu/+bugs?advanced=1 > Bug Control/Squad: "needs attention" > [] past 5 days > [] past 15 days > [] past 30 days > [] all "needs attention" -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.park at canonical.com Fri Nov 8 00:12:18 2013 From: robert.park at canonical.com (Robert Park) Date: Thu, 7 Nov 2013 16:12:18 -0800 Subject: Bug Triage processes need some improvement and automation (Bug triage activity summary)... In-Reply-To: References: Message-ID: On Thu, Nov 7, 2013 at 3:06 PM, AG Restringere wrote: > Yes, Launchpad has loads of detailed search items available but the problem > with looking at bugs about to expire is that these are bugs that I should > NOT be looking at, it's better to let them expire like you said. True I Here is a search that should interest you: https://bugs.launchpad.net/bugs/+bugs?field.searchtext=&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&assignee_option=none&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.tag=&field.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search&orderby=-date_last_updated&start=0 This is: NEW and CONFIRMED bugs, unassigned, without linked branches or blueprints. That should be quite a good list of triagable bugs. If somebody already triaged it, then it's state should be either Triaged or Incomplete. If somebody is assigned, or if there's a linked branch, then somebody is probably working on them. This search should find most of what's left over. From brian at ubuntu.com Fri Nov 8 01:05:40 2013 From: brian at ubuntu.com (Brian Murray) Date: Thu, 7 Nov 2013 17:05:40 -0800 Subject: Bug Triage processes need some improvement and automation (Bug triage activity summary)... In-Reply-To: References: Message-ID: <20131108010540.GO23498@murraytwins.com> On Thu, Nov 07, 2013 at 06:06:28PM -0500, AG Restringere wrote: > @ Brian Murray, I've shelved and retracted the previous proposal after some > discussion on the Bug-Squad mailing list. The process I was proposing was > simply diametrically opposed to the current Bug Squad/Control processes and > would not actually work as intended in actual application. However I did > "drill down" to the problem that I had and it turned out to be a problem > with what kind of data is displayed on actual bug reports in Launchpad and > making that data more searchable. It's not a process problem, it's a data > display and search issue. > > > > What types of bugs did you have difficultly searching for? > > > Yes, Launchpad has loads of detailed search items available but the problem > with looking at bugs about to expire is that these are bugs that I should > NOT be looking at, it's better to let them expire like you said. True I > could see if they are Incomplete but that would mean that Bug Triage has > already done their job and is just waiting for the Reporter. The bugs I > want to find are ones with multiple Reporters are Confirmed and fresh but > aren't getting any attention from Bug Triage or not enough attention. This > the area where I could really jump in a "pick up the slack". When looking at a list of bugs about a package (or a project) at a url like this: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bugs There is a gear icon that allows you to change what information is displayed in the bug list. A useful attribute to have there is "Date last updated". Once it is there you click on it to sort by the date last updated. I think you could do a search for Confirmed bugs then sort by date last updated with the least recently updated ones at the top and find a good approximation of what you want. > There doesn't seem to be a way to search for bugs that have low "bug > triage" activity because Launchpad just records everyone's activity and > only reports generic information. That is activity from Reporters, > Developers, Packagers and Bug Control/Squad members, everyone, but it > doesn't separate out or filter just activity from Bug Control/Squad. This makes an assumption that activity from people who are not in the Ubuntu Bug Squad or Ubuntu Bug Control is less valuable, which is not the case. There are plenty of developers of other distributions and upstream projects who are not members of either team. Frequently, we (Ubuntu Developers) see patches for bugs from new Launchpad users. One thing I personally use is a Firefox Greasemonkey script that marks up bug comments with team membership information for bug commenters, using this allows me to quickly scan a bug's contents for the comments I may want to read first. Here's a screenshot: http://www.murraytwins.com/blog/wp-content/uploads/2008/08/lp-gm-script.png We can see that Bryce is a developer and member of Ubuntu Bug Control. Another script that I use displays the date the bug was last updated at the top of the bug report. So it now says: Reported by Bob on 2010-05-15 and last updated on 2013-11-07 It's not perfect but it helps my work flow. -- Brian Murray Ubuntu Bug Master From ibere.fernandes at gmail.com Thu Nov 7 19:19:03 2013 From: ibere.fernandes at gmail.com (=?ISO-8859-1?Q?Iber=EA_Fernandes?=) Date: Thu, 7 Nov 2013 17:19:03 -0200 Subject: "One Hundred Papercuts" is having a submit In-Reply-To: <527BC57D.2000809@gmail.com> References: <527BC57D.2000809@gmail.com> Message-ID: 2013/11/7 Alberto Salvia Novella > [image: ♥ One Hundred Papercuts] > > *Papercuts are easily fixable but very annoying bugs.* > *Our mission is to improve the user experience in Ubuntu by reducing them.* > > > We'll be having a submitat "*Thursday > 15:05 - 16:00 UTC*" on . > > This will be interesting for you if you want: > > - To meet *people* involved. > - To share ideas on how to reduce *papercuts*. > - To share ideas about how to make Ubuntu community *accessible* to all > kinds of people. > > > Thank you ♥ > > -- > Ubuntu-quality mailing list > Ubuntu-quality at lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality > > Thank you for your e-mail. Doubt: Is the 100 papercuts project for Ubuntu only or the other flavors are included? I'm a tester/member of lubuntu-qa@ Lubuntu 14.04 will be our first LTS. I was searching for Kubuntu, KDE, Gnome, Xubuntu, Xfce, Lubuntu and LXDE at https://bugs.launchpad.net/hundredpapercuts/+bugs The search result page for queries like lubuntu or lxde is empty. I was reading the 100 papercuts wiki and I could not find if it's a project for all the flavors: https://wiki.ubuntu.com/One%20Hundred%20Papercuts/One%20Hundred%20Papercuts%20will%20make%20Ubuntu%20shine Thank you advance for your reply! -- https://wiki.ubuntu.com/Ibere-Fernandes -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Banner.svg Type: image/svg+xml Size: 23546 bytes Desc: not available URL: From ag.restringere at gmail.com Fri Nov 8 01:36:02 2013 From: ag.restringere at gmail.com (AG Restringere) Date: Thu, 7 Nov 2013 20:36:02 -0500 Subject: Bug Triage processes need some improvement and automation (Bug triage activity summary)... In-Reply-To: <20131108010540.GO23498@murraytwins.com> References: <20131108010540.GO23498@murraytwins.com> Message-ID: > > There is a gear icon that allows you to change what information is > displayed in the bug list. A useful attribute to have there is "Date > last updated". Once it is there you click on it to sort by the date > last updated. I think you could do a search for Confirmed bugs then > sort by date last updated with the least recently updated ones at the > top and find a good approximation of what you want. Those are actually really useful features I didn't know about. I guess I can build a workflow around those and explore which options work best. Once I find a useful strategy I'll provide some feedback on it. One thing I personally use is a Firefox Greasemonkey script that marks > up bug comments with team membership information for bug commenters, > using this allows me to quickly scan a bug's contents for the comments I > may want to read first. Here's a screenshot: Building a "Bug Squad/Control" Firefox extension would be the best way to implement this, because that's the default Ubuntu browser, though a Chrome one would be great too. That way you could just augment the information that the Bug Report provides and not bother the Launchpad people and workaround the issue. This extension could be extended to provide even more summary information and accomplish the goals of this proposal. Thanks for the interesting feedback. On Thu, Nov 7, 2013 at 8:05 PM, Brian Murray wrote: > On Thu, Nov 07, 2013 at 06:06:28PM -0500, AG Restringere wrote: > > @ Brian Murray, I've shelved and retracted the previous proposal after > some > > discussion on the Bug-Squad mailing list. The process I was proposing > was > > simply diametrically opposed to the current Bug Squad/Control processes > and > > would not actually work as intended in actual application. However I did > > "drill down" to the problem that I had and it turned out to be a problem > > with what kind of data is displayed on actual bug reports in Launchpad > and > > making that data more searchable. It's not a process problem, it's a > data > > display and search issue. > > > > > > > What types of bugs did you have difficultly searching for? > > > > > > Yes, Launchpad has loads of detailed search items available but the > problem > > with looking at bugs about to expire is that these are bugs that I should > > NOT be looking at, it's better to let them expire like you said. True I > > could see if they are Incomplete but that would mean that Bug Triage has > > already done their job and is just waiting for the Reporter. The bugs I > > want to find are ones with multiple Reporters are Confirmed and fresh but > > aren't getting any attention from Bug Triage or not enough attention. > This > > the area where I could really jump in a "pick up the slack". > > When looking at a list of bugs about a package (or a project) at a url > like this: > > https://bugs.launchpad.net/ubuntu/+source/update-manager/+bugs > > There is a gear icon that allows you to change what information is > displayed in the bug list. A useful attribute to have there is "Date > last updated". Once it is there you click on it to sort by the date > last updated. I think you could do a search for Confirmed bugs then > sort by date last updated with the least recently updated ones at the > top and find a good approximation of what you want. > > > There doesn't seem to be a way to search for bugs that have low "bug > > triage" activity because Launchpad just records everyone's activity and > > only reports generic information. That is activity from Reporters, > > Developers, Packagers and Bug Control/Squad members, everyone, but it > > doesn't separate out or filter just activity from Bug Control/Squad. > > This makes an assumption that activity from people who are not in the > Ubuntu Bug Squad or Ubuntu Bug Control is less valuable, which is not > the case. There are plenty of developers of other distributions and > upstream projects who are not members of either team. Frequently, we > (Ubuntu Developers) see patches for bugs from new Launchpad users. > > One thing I personally use is a Firefox Greasemonkey script that marks > up bug comments with team membership information for bug commenters, > using this allows me to quickly scan a bug's contents for the comments I > may want to read first. Here's a screenshot: > > http://www.murraytwins.com/blog/wp-content/uploads/2008/08/lp-gm-script.png > > We can see that Bryce is a developer and member of Ubuntu Bug Control. > > Another script that I use displays the date the bug was last updated at > the top of the bug report. So it now says: > > Reported by Bob on 2010-05-15 and last updated on 2013-11-07 > > It's not perfect but it helps my work flow. > > -- > Brian Murray > Ubuntu Bug Master > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisjohnston at ubuntu.com Fri Nov 8 18:27:34 2013 From: chrisjohnston at ubuntu.com (Chris Johnston) Date: Fri, 8 Nov 2013 13:27:34 -0500 Subject: Bug triage activity summary on bug reports (Launchpad)... In-Reply-To: References: <20131106183901.GB8258@gallifrey> Message-ID: On Wed, Nov 6, 2013 at 2:08 PM, AG Restringere wrote: > It [Launchpad] already creates a full history. > > > There are some drawbacks to that: > > 1. It doesn't tell me which Bug Control/Squad team members are > creating activity on the bug. > > Have you taken a look at the LP Greasemonkey scripts [1]? IIRC it can display team logo's after a users name in LP. You could very possibly also extend it to show you some of the other things that you are wanting to see while not requiring changes to LP (which can be quite hard to do, especially to the scale of what you are wanting) plus it won't confuse others (say the reporter/novice LP user) as it won't show up on their views, only on the views of those who have the script installed. [1] https://launchpad.net/launchpad-gm-scripts cJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cindy.scd02 at gmail.com Sat Nov 9 16:28:27 2013 From: cindy.scd02 at gmail.com (=?ISO-8859-1?Q?Cindy_C=E9spedes?=) Date: Sat, 9 Nov 2013 11:28:27 -0500 Subject: Hacked account Message-ID: Unsubscribe me please -------------- next part -------------- An HTML attachment was scrubbed... URL: From as.bcit at gmail.com Sun Nov 10 19:32:11 2013 From: as.bcit at gmail.com (A.Shahidi) Date: Sun, 10 Nov 2013 11:32:11 -0800 Subject: Hacked account In-Reply-To: References: Message-ID: Me too plz! Cant take the constant emails.. On Nov 10, 2013 11:15 AM, "Cindy Céspedes" wrote: > Unsubscribe me please > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From es20490446e at gmail.com Sun Nov 10 19:41:07 2013 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Sun, 10 Nov 2013 20:41:07 +0100 Subject: Hacked account In-Reply-To: References: Message-ID: <527FE153.5010803@gmail.com> You can unsubscribe by clicking in the provided link of this list's signature, that is https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad. El 10/11/13 20:32, A.Shahidi escribió: > > Me too plz! > Cant take the constant emails.. > > On Nov 10, 2013 11:15 AM, "Cindy Céspedes" > wrote: > > Unsubscribe me please > > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From as.bcit at gmail.com Sun Nov 10 20:36:31 2013 From: as.bcit at gmail.com (A.Shahidi) Date: Sun, 10 Nov 2013 12:36:31 -0800 Subject: Hacked account In-Reply-To: <527FE153.5010803@gmail.com> References: <527FE153.5010803@gmail.com> Message-ID: Their is a bug!!! in the "unsubscribe" function. Can we get the team to focus on that? :)p On Nov 10, 2013 11:41 AM, "Alberto Salvia Novella" wrote: > You can unsubscribe by clicking in the provided link of this list's > signature, that is > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad. > > > El 10/11/13 20:32, A.Shahidi escribió: > > Me too plz! > Cant take the constant emails.. > On Nov 10, 2013 11:15 AM, "Cindy Céspedes" wrote: > >> Unsubscribe me please >> >> -- >> Ubuntu-bugsquad mailing list >> Ubuntu-bugsquad at lists.ubuntu.com >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad >> >> > > > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From es20490446e at gmail.com Mon Nov 11 00:07:03 2013 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Mon, 11 Nov 2013 01:07:03 +0100 Subject: Hacked account In-Reply-To: References: <527FE153.5010803@gmail.com> Message-ID: <52801FA7.6010807@gmail.com> Do you mean you can unsubscribe from there? Perhaps its enough to leave the "Ubuntu BugSquad" team in Launchpad . El 10/11/13 21:36, A.Shahidi escribió: > > Their is a bug!!! in the "unsubscribe" function. Can we get the team > to focus on that? :)p > > On Nov 10, 2013 11:41 AM, "Alberto Salvia Novella" > > wrote: > > You can unsubscribe by clicking in the provided link of this > list's signature, that is > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad. > > > El 10/11/13 20:32, A.Shahidi escribió: >> >> Me too plz! >> Cant take the constant emails.. >> >> On Nov 10, 2013 11:15 AM, "Cindy Céspedes" > > wrote: >> >> Unsubscribe me please >> >> >> -- >> Ubuntu-bugsquad mailing list >> Ubuntu-bugsquad at lists.ubuntu.com >> >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad >> >> >> > > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanbell at ubuntu.com Mon Nov 11 00:12:53 2013 From: alanbell at ubuntu.com (Alan Bell) Date: Mon, 11 Nov 2013 00:12:53 +0000 Subject: Hacked account In-Reply-To: <52801FA7.6010807@gmail.com> References: <527FE153.5010803@gmail.com> <52801FA7.6010807@gmail.com> Message-ID: <52802105.4020901@ubuntu.com> no, the launchpad team has nothing to do with subscription status on lists.ubuntu.com I pressed the unsubscribe button for both users in this thread wanting to ubsubscribe, they should have an email with a link to click on. Anyone can put in the email address and press the unsubscribe request button, it sends a link to the user. That is probably a better thing to do for a user than just replying and telling them to sort it out themselves, that doesn't give them any more information than was at the bottom of every email anyway. Maybe they don't have a browser that can render the form efficiently or something. If there is a bug in the unsubscribe functionality then it would be good to know what that bug is, but in general I have reason to believe that some people have been able to unsubscribe from some lists. Alan. On 11/11/13 00:07, Alberto Salvia Novella wrote: > Do you mean you can unsubscribe from there? > > Perhaps its enough to leave the "Ubuntu BugSquad" team in Launchpad > . > > -- I work at http://libertus.co.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: From walter.garcia at upf.edu Mon Nov 11 05:10:45 2013 From: walter.garcia at upf.edu (Walter Garcia-Fontes) Date: Mon, 11 Nov 2013 06:10:45 +0100 Subject: Hacked account In-Reply-To: <52802105.4020901@ubuntu.com> References: <527FE153.5010803@gmail.com> <52801FA7.6010807@gmail.com> <52802105.4020901@ubuntu.com> Message-ID: <20131111051045.GA26701@upf.edu> * Alan Bell, alanbell at ubuntu.com [11/11/13 01:13]: > If there is a bug in the unsubscribe functionality then it would be > good to know what that bug is, but in general I have reason to > believe that some people have been able to unsubscribe from some Very often the user subscribed with an email account that it is not the one he/she is using right now, and then has difficulties unsubscribing because of this. -- Walter Garcia-Fontes From noreply at ubuntu.com Tue Nov 12 08:04:03 2013 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Tue, 12 Nov 2013 08:04:03 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22DebuggingDBus=22_by_pitti?= Message-ID: <20131112080403.22034.41520@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "DebuggingDBus" page has been changed by pitti: http://wiki.ubuntu.com/DebuggingDBus?action=diff&rev1=6&rev2=7 Comment: Update recipe to actually work on recent Ubuntu versions This is trickier, because D-Bus policy typically prevents anything but signals from being viewable by dbus-monitor. But we can change that. - 1. Create a file /etc/dbus-1/system.d/99-eavesdrop.conf, with these contents: + 1. Create a file /etc/dbus-1/system-local.conf, with these contents: {{{ - + - + + - - + + }}} + 1. Reload D-BUS to pick up the configuration change: + {{{ + sudo reload dbus }}} 1. Now run dbus-monitor as root. You should be able to see all signals, method calls, and method replies. {{{ @@ -43, +42 @@ }}} 1. When done debugging, it is wise to remove the policy snippet: {{{ - sudo rm /etc/dbus-1/system.d/99-eavesdrop.conf + sudo rm /etc/dbus-1/system-local.conf }}} = Filtering all the noise = From noreply at ubuntu.com Wed Nov 13 12:52:37 2013 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Wed, 13 Nov 2013 12:52:37 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Hotkeys/Troubleshooting=22_by_pi?= =?utf-8?q?tti?= Message-ID: <20131113125237.2960.95759@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "Hotkeys/Troubleshooting" page has been changed by pitti: http://wiki.ubuntu.com/Hotkeys/Troubleshooting?action=diff&rev1=40&rev2=41 Comment: update for evtest, as udev's keymap tool went away in 13.10 * in some cases the keybindings may be wrong, perhaps due to a legacy (i.e., pre-evdev) keymap. You can check your keymap using `gconf-editor` and looking under `/apps/gnome_settings_daemon/keybindings`. Bindings without sensible key names are probably bugs. * for audio volume control hotkeys, gnome-sound-properties may be misconfigured. You can either examine with gconf-editor '/desktop/gnome/sound' or do 'gconftool --recursive-list /desktop/gnome/sound' to get the current settings; the particular configuration items are 'default_mixer_tracks' and 'default_mixer_device'. a. if there are too many keypress events then you need to determine where they are being duplicated. - 1. if the key code is wrong, or there is no keypress event, or the key only works once and then the desktop gets "stuck", exercise the "Fixing broken keys" section in /usr/share/doc/udev/README.keymap.txt (Ubuntu 9.10 and later). + 1. if the key code is wrong, or there is no keypress event, or the key only works once and then the desktop gets "stuck", install the "evtest" package, run `sudo evtest`, select your keyboard device, press the broken keys, and note down their scan code (MSC_SCAN), current keycode (KEY_*), and intended meaning. - a. If that was successful, file a bug against udev ("ubuntu-bug udev") and attach your newly created keymap and rule. + a. If that was successful, file a bug against udev ("ubuntu-bug udev") and add the scan code → meaning map. - a. If udev's keymap tool shows a correct key symbol, look up the symbolic name in /usr/include/linux/input.h. If it is mapped to a code over 255 (over 0x0ff), then it is outside X's range see [[https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/313514|bug 313514]]. In this case, if it is important to have the key mapped, the key should be remapped to an appropriate value < 256. + a. If evtest shows a correct key symbol, look up the symbolic name in /usr/include/linux/input.h. If it is mapped to a code over 255 (over 0x0ff), then it is outside X's range see [[https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/313514|bug 313514]]. In this case, if it is important to have the key mapped, the key should be remapped to an appropriate value < 256. 1. If the events are reported by more than one input device then report a kernel bug (Ubuntu `linux` package) because it should only send the event on one device. 1. if not found with `keymap`, use `acpi_listen` to determine whether the key is coming through as an ACPI event instead of a keypress a. if there is an ACPI event but no keypress, this is a bug in the kernel (ubuntu-bug linux) for not translating the ACPI event to an input event. From hggdh2 at ubuntu.com Wed Nov 13 20:40:45 2013 From: hggdh2 at ubuntu.com (C de-Avillez) Date: Wed, 13 Nov 2013 14:40:45 -0600 Subject: Hacked account In-Reply-To: <20131111051045.GA26701@upf.edu> References: <527FE153.5010803@gmail.com> <52801FA7.6010807@gmail.com> <52802105.4020901@ubuntu.com> <20131111051045.GA26701@upf.edu> Message-ID: <20131113144045.4fb8b285@icatu> On Mon, 11 Nov 2013 06:10:45 +0100 Walter Garcia-Fontes wrote: > * Alan Bell, alanbell at ubuntu.com [11/11/13 01:13]: > > If there is a bug in the unsubscribe functionality then it would be > > good to know what that bug is, but in general I have reason to > > believe that some people have been able to unsubscribe from some > > Very often the user subscribed with an email account that it is not > the one he/she is using right now, and then has difficulties > unsubscribing because of this. > Well. Email is sent to the *subscribed* email. If you receive email from BugSquad (or any other ML in lists.ubuntu.com) then you *can* unsubscribe. If you are not receiving emails because you changed your email address, then this is *not* an issue anymore. Ergo, if you can reply to this thread, you can unsubscribe yourself. Cheers, ..C.. -- ab alio expectes alteri quod feceris -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From as.bcit at gmail.com Wed Nov 13 20:59:06 2013 From: as.bcit at gmail.com (A.Shahidi) Date: Wed, 13 Nov 2013 12:59:06 -0800 Subject: Hacked account In-Reply-To: <20131113144045.4fb8b285@icatu> References: <527FE153.5010803@gmail.com> <52801FA7.6010807@gmail.com> <52802105.4020901@ubuntu.com> <20131111051045.GA26701@upf.edu> <20131113144045.4fb8b285@icatu> Message-ID: Still receiving. Hence the reply. :) On Nov 13, 2013 12:41 PM, "C de-Avillez" wrote: > On Mon, 11 Nov 2013 06:10:45 +0100 > Walter Garcia-Fontes wrote: > > > * Alan Bell, alanbell at ubuntu.com [11/11/13 01:13]: > > > If there is a bug in the unsubscribe functionality then it would be > > > good to know what that bug is, but in general I have reason to > > > believe that some people have been able to unsubscribe from some > > > > Very often the user subscribed with an email account that it is not > > the one he/she is using right now, and then has difficulties > > unsubscribing because of this. > > > > > Well. Email is sent to the *subscribed* email. If you receive email > from BugSquad (or any other ML in lists.ubuntu.com) then you *can* > unsubscribe. If you are not receiving emails because you changed > your email address, then this is *not* an issue anymore. > > Ergo, if you can reply to this thread, you can unsubscribe yourself. > > Cheers, > > ..C.. > > -- > ab alio expectes alteri quod feceris > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ursinha at ursinha.net Thu Nov 14 13:46:38 2013 From: ursinha at ursinha.net (Ursula Junque) Date: Thu, 14 Nov 2013 11:46:38 -0200 Subject: Hacked account In-Reply-To: References: <527FE153.5010803@gmail.com> <52801FA7.6010807@gmail.com> <52802105.4020901@ubuntu.com> <20131111051045.GA26701@upf.edu> <20131113144045.4fb8b285@icatu> Message-ID: Hi, On Wed, Nov 13, 2013 at 6:59 PM, A.Shahidi wrote: > Still receiving. Hence the reply. :) > If you click on this link: https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad at the bottom of the page you have: "To unsubscribe from Ubuntu-bugsquad, get a password reminder, or change your subscription options enter your subscription email address:". Add the email you used to subscribe to the list and that should be enough. Easier than that, only if you give me your password and email so I can do that for you :) (please, don't do that) Cheers! Úrsula On Nov 13, 2013 12:41 PM, "C de-Avillez" wrote: > >> On Mon, 11 Nov 2013 06:10:45 +0100 >> Walter Garcia-Fontes wrote: >> >> > * Alan Bell, alanbell at ubuntu.com [11/11/13 01:13]: >> > > If there is a bug in the unsubscribe functionality then it would be >> > > good to know what that bug is, but in general I have reason to >> > > believe that some people have been able to unsubscribe from some >> > >> > Very often the user subscribed with an email account that it is not >> > the one he/she is using right now, and then has difficulties >> > unsubscribing because of this. >> > >> >> >> Well. Email is sent to the *subscribed* email. If you receive email >> from BugSquad (or any other ML in lists.ubuntu.com) then you *can* >> unsubscribe. If you are not receiving emails because you changed >> your email address, then this is *not* an issue anymore. >> >> Ergo, if you can reply to this thread, you can unsubscribe yourself. >> >> Cheers, >> >> ..C.. >> >> -- >> ab alio expectes alteri quod feceris >> >> -- >> Ubuntu-bugsquad mailing list >> Ubuntu-bugsquad at lists.ubuntu.com >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad >> >> > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > -- Ursinha (Ursula Junque) ursinha at ursinha.net ursinha at ubuntu.com -- Ubuntu - I am because we are -- Linux user #289453 - Ubuntu user #31144 -------------- next part -------------- An HTML attachment was scrubbed... URL: From amjjawad at gmail.com Fri Nov 15 12:13:38 2013 From: amjjawad at gmail.com (Ali Linx (amjjawad)) Date: Fri, 15 Nov 2013 16:13:38 +0400 Subject: Call For Help Message-ID: Hello Everyone, Starting today, we have a dedicated sub-team for contributions and we are in urgent need for more contributions, help and support. Kindly have a read: http://ubuntugnome.org/announcement-ubuntu-gnome-packaging-team/ Your help and support are highly appreciated :) Thank you! P.S. Please, spread the word if you know anyone who might be interested. -- Remember: "All of us are smarter than any one of us." Best Regards, amjjawad Areas of Involvement My Projects -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholas.skaggs at canonical.com Mon Nov 18 15:57:59 2013 From: nicholas.skaggs at canonical.com (Nicholas Skaggs) Date: Mon, 18 Nov 2013 10:57:59 -0500 Subject: Quality vUDS Sessions In-Reply-To: <527A8771.3010000@canonical.com> References: <52790D43.2020704@canonical.com> <527A8771.3010000@canonical.com> Message-ID: <528A3907.9060507@canonical.com> Just a reminder, here's the sessions again in order, with links. These start tomorrow! See you @ vUDS :-) QA Community Workflows 2013-11-19 15:05..16:00 in Community 1 http://summit.ubuntu.com/uds-1311/meeting/21981/community-1311-quality-defining-workflows/ Startup Disk Creator redesign & renaming proposal 2013-11-19 18:05..19:00 in Community 1 http://summit.ubuntu.com/uds-1311/meeting/21985/community-1311-ubuntu-usb-startup-creator/ Merging bugsquad and the community QA team 2013-11-19 19:05..20:00 in Community 1 http://summit.ubuntu.com/uds-1311/meeting/21987/community-1311-quality-bugsquad/ Quality community-run testing events 2013-11-20 14:00..15:00 in Community 1 http://summit.ubuntu.com/uds-1311/meeting/22064/community-1311-quality-calls-for-testing/ Community exploratory testing 2013-11-20 15:05..16:00 in Community 2 http://summit.ubuntu.com/uds-1311/meeting/22065/community-1311-quality-community-exploratory-testing/ Core Apps Test Review 2013-11-20 18:05..19:00 in App Developer 1 http://summit.ubuntu.com/uds-1311/meeting/22071/appdev-1311-core-apps-test-review/ Autopilot planning for trusty 2013-11-20 19:05..20:00 in Community 1 http://summit.ubuntu.com/uds-1311/meeting/22072/community-1311-quality-autopilot-roundtable/ Automated ubiquity testing with autopilot 2013-11-21 14:00..15:00 in Community 1 http://summit.ubuntu.com/uds-1311/meeting/22063/community-1311-quality-autopilot-image-testing/ One hundred papercuts for trusty 2013-11-21 15:05..16:00 in Community 1 http://summit.ubuntu.com/uds-1311/meeting/22070/community-1311-quality-papercuts/ Touch Core Apps testing needs 2013-11-21 16:05..17:00 in Community 1 http://summit.ubuntu.com/uds-1311/meeting/22062/community-1311-coreapps-testing/ Nicholas On 11/06/2013 01:16 PM, Nicholas Skaggs wrote: > Just a reminder, here are the currently scheduled vUDS sessions > relating to quality. Quality sessions typically will occur on the > community track. It was pointed out to me my original agenda for the > roundtable was shall we say, "ambitous". So I pulled out almost all of > the items into seperate sessions, so now we have several more. > > Here's the full list broken down by interest :-) > > *For folks involved with core apps;* > Core apps test review, checking out what tests we have and what is > still needed for each core app > https://blueprints.launchpad.net/ubuntu/+spec/appdev-1311-core-apps-test-review > > Core apps testing workflow review; how can we keep tests green and > running reliably? > https://blueprints.launchpad.net/ubuntu/+spec/community-1311-coreapps-testing > > *For test writers;* > Autopilot roundtable session, talking about what's new and what we > need for ap 1.5, etc > https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-autopilot-roundtable > > Let's get ubiquity autopilot tests running well this cycle and ensure > the release process changes to incorporate them too! > https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-autopilot-image-testing > > *For testers;* > Let's talk about revamping calls for testing to let everyone in the > community schedule there own :-) > https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-calls-for-testing > > We want to be exploratory testing this cycle on all devices (pc, > phone, tablet, etc)! > https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-community-exploratory-testing > > *For developers;* > Let's talk about papercuts for trusty! > https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-papercuts > > A community inspired session on tweaking usb startup creator for trusty > https://blueprints.launchpad.net/ubuntu/+spec/community-1311-ubuntu-usb-startup-creator > > *For everyone;* > QA Community Roundtable, talking about the roles change, our big > projects, and other things :-) > https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-defining-workflows > > A blueprint for us to work out the details on merging bugsquad and qa > community teams > https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-bugsquad > > Nicholas -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergioandresmeneses at gmail.com Mon Nov 18 16:56:01 2013 From: sergioandresmeneses at gmail.com (Sergio Meneses) Date: Mon, 18 Nov 2013 11:56:01 -0500 Subject: Quality vUDS Sessions In-Reply-To: <528A3907.9060507@canonical.com> References: <52790D43.2020704@canonical.com> <527A8771.3010000@canonical.com> <528A3907.9060507@canonical.com> Message-ID: Thanks Nicholas! :D Sergio Meneses Linux User: #478743 Ubuntu User: #24056 On Mon, Nov 18, 2013 at 10:57 AM, Nicholas Skaggs < nicholas.skaggs at canonical.com> wrote: > Just a reminder, here's the sessions again in order, with links. These > start tomorrow! See you @ vUDS :-) > > QA Community Workflows > 2013-11-19 15:05..16:00 in Community 1 > > http://summit.ubuntu.com/uds-1311/meeting/21981/community-1311-quality-defining-workflows/ > > Startup Disk Creator redesign & renaming proposal > 2013-11-19 18:05..19:00 in Community 1 > > http://summit.ubuntu.com/uds-1311/meeting/21985/community-1311-ubuntu-usb-startup-creator/ > > Merging bugsquad and the community QA team > 2013-11-19 19:05..20:00 in Community 1 > > http://summit.ubuntu.com/uds-1311/meeting/21987/community-1311-quality-bugsquad/ > > Quality community-run testing events > 2013-11-20 14:00..15:00 in Community 1 > > http://summit.ubuntu.com/uds-1311/meeting/22064/community-1311-quality-calls-for-testing/ > > Community exploratory testing > 2013-11-20 15:05..16:00 in Community 2 > > http://summit.ubuntu.com/uds-1311/meeting/22065/community-1311-quality-community-exploratory-testing/ > > Core Apps Test Review > 2013-11-20 18:05..19:00 in App Developer 1 > > http://summit.ubuntu.com/uds-1311/meeting/22071/appdev-1311-core-apps-test-review/ > > Autopilot planning for trusty > 2013-11-20 19:05..20:00 in Community 1 > > http://summit.ubuntu.com/uds-1311/meeting/22072/community-1311-quality-autopilot-roundtable/ > > Automated ubiquity testing with autopilot > 2013-11-21 14:00..15:00 in Community 1 > > http://summit.ubuntu.com/uds-1311/meeting/22063/community-1311-quality-autopilot-image-testing/ > > One hundred papercuts for trusty > 2013-11-21 15:05..16:00 in Community 1 > > http://summit.ubuntu.com/uds-1311/meeting/22070/community-1311-quality-papercuts/ > > Touch Core Apps testing needs > 2013-11-21 16:05..17:00 in Community 1 > > http://summit.ubuntu.com/uds-1311/meeting/22062/community-1311-coreapps-testing/ > > Nicholas > > > On 11/06/2013 01:16 PM, Nicholas Skaggs wrote: > > Just a reminder, here are the currently scheduled vUDS sessions relating > to quality. Quality sessions typically will occur on the community track. > It was pointed out to me my original agenda for the roundtable was shall we > say, "ambitous". So I pulled out almost all of the items into seperate > sessions, so now we have several more. > > Here's the full list broken down by interest :-) > > *For folks involved with core apps;* > Core apps test review, checking out what tests we have and what is still > needed for each core app > > https://blueprints.launchpad.net/ubuntu/+spec/appdev-1311-core-apps-test-review > > Core apps testing workflow review; how can we keep tests green and running > reliably? > > https://blueprints.launchpad.net/ubuntu/+spec/community-1311-coreapps-testing > > *For test writers;* > Autopilot roundtable session, talking about what's new and what we need > for ap 1.5, etc > > https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-autopilot-roundtable > > Let's get ubiquity autopilot tests running well this cycle and ensure the > release process changes to incorporate them too! > > https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-autopilot-image-testing > > *For testers;* > Let's talk about revamping calls for testing to let everyone in the > community schedule there own :-) > > https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-calls-for-testing > > We want to be exploratory testing this cycle on all devices (pc, phone, > tablet, etc)! > > https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-community-exploratory-testing > > *For developers;* > Let's talk about papercuts for trusty! > > https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-papercuts > > A community inspired session on tweaking usb startup creator for trusty > > https://blueprints.launchpad.net/ubuntu/+spec/community-1311-ubuntu-usb-startup-creator > > *For everyone;* > QA Community Roundtable, talking about the roles change, our big projects, > and other things :-) > > https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-defining-workflows > > A blueprint for us to work out the details on merging bugsquad and qa > community teams > > https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-bugsquad > > Nicholas > > > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amjjawad at gmail.com Thu Nov 21 14:30:30 2013 From: amjjawad at gmail.com (Ali Linx (amjjawad)) Date: Thu, 21 Nov 2013 18:30:30 +0400 Subject: [Sandbox][Work Item] vUDS: Quality community-Run Testing Events Message-ID: Hi Everyone, As discussed on yesterday session: http://summit.ubuntu.com/uds-1311/meeting/22064/community-1311-quality-calls-for-testing/ and as one of the work times: http://pad.ubuntu.com/uds-1311-community-1311-quality-calls-for-testing Here is a mockup on my sandbox area: Main Page: https://wiki.ubuntu.com/amjjawad/Projects/Sandbox/TestingEvents Results Page: https://wiki.ubuntu.com/amjjawad/Projects/Sandbox/TestingEvents/TestingResults If there is anything not clear of if you have any question, please ask :) Thank you! -- Remember: "All of us are smarter than any one of us." Best Regards, amjjawad Areas of Involvement My Projects -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.varlitskiy at gmail.com Thu Nov 21 02:43:58 2013 From: s.varlitskiy at gmail.com (Serge Varlitskiy) Date: Wed, 20 Nov 2013 18:43:58 -0800 Subject: ubuntu 13.10 terminal newuser bug Message-ID: There is a bug in the new stable release of ubuntu 13.10. For some reason, the first time that newusers is used you can only add one user after that you can add as many as you would like. Here are the steps: 1. Do a clean install of Ubuntu 13.10 2. Open terminal and run A. sudo apt-get update B. sudo apt-get dist-upgrade 3. Create a text file with two or more users to be added 4. Run command: sudo newusers textfile 5. Ubuntu errors out with: *** Error in `newusers': double free or corruption (!prev): 0x0000000001bd3790 *** *** Error in `newusers': malloc(): memory corruption: 0x0000000001bd3830 *** 6. Create another text file with a single user to be added 7. run command: sudo newusers newtextfile 8. Everything works great 9. Now run the previous command: sudo newusers textfile 10. Everything works great 11. Seems like a bug to me .... -- Serge Varlitskiy -------------- next part -------------- An HTML attachment was scrubbed... URL: From chilicuil at ubuntu.com Thu Nov 21 15:38:27 2013 From: chilicuil at ubuntu.com (Javier Lopez) Date: Thu, 21 Nov 2013 09:38:27 -0600 Subject: [Sandbox][Work Item] vUDS: Quality community-Run Testing Events In-Reply-To: References: Message-ID: <20131121153825.GA2089@sup.lan> That's a nice wiki!, just to make it clear, the table is for describing only testing event right?, what about classroom testing events? https://wiki.ubuntu.com/Testing/Activities/Classroom Should we include both events in the same wiki? Best Regards On 21/11/13 at 06:30pm, Ali Linx (amjjawad) wrote: > Hi Everyone, > > As discussed on yesterday session: > http://summit.ubuntu.com/uds-1311/meeting/22064/community-1311-quality-calls-for-testing/ > > and as one of the work times: > http://pad.ubuntu.com/uds-1311-community-1311-quality-calls-for-testing > > Here is a mockup on my sandbox area: > > Main Page: > https://wiki.ubuntu.com/amjjawad/Projects/Sandbox/TestingEvents > > Results Page: > https://wiki.ubuntu.com/amjjawad/Projects/Sandbox/TestingEvents/TestingResults > > If there is anything not clear of if you have any question, please ask :) > > > Thank you! > > -- > Remember: "All of us are smarter than any one of us." > Best Regards, > amjjawad > Areas of Involvement > My Projects From amjjawad at gmail.com Thu Nov 21 15:49:58 2013 From: amjjawad at gmail.com (Ali Linx (amjjawad)) Date: Thu, 21 Nov 2013 19:49:58 +0400 Subject: [Sandbox][Work Item] vUDS: Quality community-Run Testing Events In-Reply-To: <20131121153825.GA2089@sup.lan> References: <20131121153825.GA2089@sup.lan> Message-ID: Hi, On Thu, Nov 21, 2013 at 7:38 PM, Javier Lopez wrote: > That's a nice wiki!, Thank you :) > just to make it clear, the table is for describing only > testing event right?, Yes :) See: http://summit.ubuntu.com/uds-1311/meeting/22064/community-1311-quality-calls-for-testing/ Work Items (which by mistake, I wrote work times - sorry) : http://pad.ubuntu.com/uds-1311-community-1311-quality-calls-for-testing > what about classroom testing events? > > https://wiki.ubuntu.com/Testing/Activities/Classroom > > Should we include both events in the same wiki? > > I don't think so because these are two different topics. Those who will carry on with Testing Events already know what they need to do and they should have learned something from the Classroom Testing events :) The name could be confusing but the idea should be different AFAIK :) > Best Regards > > Thank you! Remember: "All of us are smarter than any one of us." Best Regards, amjjawad Areas of Involvement My Projects -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.park at canonical.com Thu Nov 21 19:36:18 2013 From: robert.park at canonical.com (Robert Park) Date: Thu, 21 Nov 2013 11:36:18 -0800 Subject: ubuntu 13.10 terminal newuser bug In-Reply-To: References: Message-ID: On Wed, Nov 20, 2013 at 6:43 PM, Serge Varlitskiy wrote: > 11. Seems like a bug to me .... Then please report it as a bug, because emails are too easily forgotten about. Try `ubuntu-bug newusers` in a terminal. From nicholas.skaggs at canonical.com Thu Nov 21 19:58:26 2013 From: nicholas.skaggs at canonical.com (Nicholas Skaggs) Date: Thu, 21 Nov 2013 14:58:26 -0500 Subject: [Sandbox][Work Item] vUDS: Quality community-Run Testing Events In-Reply-To: References: <20131121153825.GA2089@sup.lan> Message-ID: <528E65E2.3010805@canonical.com> Looks nice Ali, I have some feedback I'll type up later. But I wanted to add that the idea for a calendar has resurfaced, and I think I will pursue it. Namely, you can get an ical sync of what's going on; testing events, etc, etc. It should include these, but nothing should otherwise be affected. Cheers, Nicholas On 11/21/2013 10:49 AM, Ali Linx (amjjawad) wrote: > Hi, > > On Thu, Nov 21, 2013 at 7:38 PM, Javier Lopez > wrote: > > That's a nice wiki!, > > > Thank you :) > > just to make it clear, the table is for describing only > testing event right?, > > > Yes :) > See: > http://summit.ubuntu.com/uds-1311/meeting/22064/community-1311-quality-calls-for-testing/ > > Work Items (which by mistake, I wrote work times - sorry) : > http://pad.ubuntu.com/uds-1311-community-1311-quality-calls-for-testing > > what about classroom testing events? > > https://wiki.ubuntu.com/Testing/Activities/Classroom > > Should we include both events in the same wiki? > > > I don't think so because these are two different topics. Those who > will carry on with Testing Events already know what they need to do > and they should have learned something from the Classroom Testing > events :) > > The name could be confusing but the idea should be different AFAIK :) > > Best Regards > > > Thank you! > > > Remember: "All of us are smarter than any one of us." > Best Regards, > amjjawad > Areas of Involvement > My Projects > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kline at thought.org Thu Nov 21 21:31:38 2013 From: kline at thought.org (Gary Kline) Date: Thu, 21 Nov 2013 13:31:38 -0800 Subject: ubuntu 13.10 terminal newuser bug In-Reply-To: References: Message-ID: <20131121213138.GA27598@ethic.thought.org> Organization: Thought Unlimited. Public service Unix since 1986. Of_Interest: With 27 years of service to the Unix community. On Thu, Nov 21, 2013 at 11:36:18AM -0800, Robert Park wrote: > On Wed, Nov 20, 2013 at 6:43 PM, Serge Varlitskiy > wrote: > > 11. Seems like a bug to me .... > > Then please report it as a bug, because emails are too easily forgotten about. > > Try `ubuntu-bug newusers` in a terminal. > > -- > Ubuntu-bugsquad mailing list > Ubuntu-bugsquad at lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad Yes, *please* do get this cleared up ASAP. I had my (volunteer) system admin upgrade to 13.10 a week+ ago. He uses another distro of Linux; I am most familiar with the BSD side of the open-source world. My problem is that I injured my shoulder years back. I Will, of course, save this in my ~/bugs directory. be easier to upgrade in some N weeks. -- Gary Kline kline at thought.org http://www.thought.org Public Service Unix Twenty-seven years of service to the Unix community. http://www.thought.org/HOPE From webmaster at ubuntu.com Fri Nov 22 13:30:44 2013 From: webmaster at ubuntu.com (Help Ubuntu) Date: Fri, 22 Nov 2013 13:30:44 -0000 Subject: =?utf-8?q?=5BCommunity_Ubuntu_Documentation=5D_Update_of_=22ReportingBugs?= =?utf-8?q?=22_by_penalvch?= Message-ID: <20131122133044.9703.82008@jostaberry.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Community Ubuntu Documentation" for change notification. The "ReportingBugs" page has been changed by penalvch: http://help.ubuntu.com/community/ReportingBugs?action=diff&rev1=248&rev2=249 Comment: Due to LP#1074110 and others, put note about "I think I'm exempt from testing as a report was filed upstream/downstream" fallacy. Thank you for reading this article. This will guide you on how best to present your bug report so that it gets addressed as soon as possible. Here are a few guiding principles that lead to success in getting bugs fixed: <
><
> Before filing any hardware related reports on Launchpad, please '''update''' your BIOS, and hardware firmware (CF card readers, SSDs, USB 3.0 controllers, DVD/CD drives, etc.) to the newest available from your vendor. Outdated and buggy BIOS and firmware is a common cause of a variety of hardware issues (ex. intermittent wireless, suspend not working, certain keys on keyboard not working correctly, card readers not working, and kernel panics after plugging USB drive in). As well, because BIOS vendors tend test to Windows and make release notes commenting on results to it, it wouldn't advise on if a problem in linux is resolved by it. Hence, one should update anyways, even if your problem isn't specifically mentioned. In summation, if your vendor has a newer version of the BIOS on their website, and you have not updated to this, your report is considered [[https://wiki.ubuntu.com/Bugs/Status|Status Incomplete]] whether or not someone toggled the Status of your report. + <
><
> + Please do not claim because you or someone else filed a bug report upstream or downstream (which is publicly viewable, and has no restrictions on who can file) you are somehow exempt from providing the information a developer or triager requested. You are being asked for this information so that it would provide more information on how to fix the problem. <
><
> Please do not speculate on what you think is or isn't a duplicate report (ex. I googled around and found bug report...). This is largely unhelpful as it tends not to be a duplicate, and already has been or easily done by triagers and developers. Instead, ensuring the report has all the requested testing information performed would be the fastest way to ensure your bug is resolved as soon as possible. <
><
> From es20490446e at gmail.com Sun Nov 24 13:18:42 2013 From: es20490446e at gmail.com (Alberto Salvia Novella) Date: Sun, 24 Nov 2013 14:18:42 +0100 Subject: Have good luck =?UTF-8?B?4pmj?= Message-ID: <5291FCB2.2010106@gmail.com> Please have a look at the *search traffic* for ubuntu.com in Alexa and you'll notice, since this traffic has increased about a 50% for the last couple of months compared to any previous epoch, the world is now paying more attention to Ubuntu than ever. There's another important fact, that is *experience* shows good software usually takes ten years ; and the development release we have now will be launched in the tenth anniversary of this community. So all this aspects suggests me we're now in the *turning point*, so take a deep breath and good do ♣ -------------- next part -------------- An HTML attachment was scrubbed... URL: From webmaster at ubuntu.com Fri Nov 29 08:50:38 2013 From: webmaster at ubuntu.com (Help Ubuntu) Date: Fri, 29 Nov 2013 08:50:38 -0000 Subject: =?utf-8?q?=5BCommunity_Ubuntu_Documentation=5D_Update_of_=22ReportingBugs?= =?utf-8?q?=22_by_penalvch?= Message-ID: <20131129085038.21831.44724@jostaberry.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Community Ubuntu Documentation" for change notification. The "ReportingBugs" page has been changed by penalvch: http://help.ubuntu.com/community/ReportingBugs?action=diff&rev1=249&rev2=250 Comment: Due to LP#1101657 added note on not pasting every past comment when making a new comment as it makes bug reports onerous to read. Please '''do not report bugs about software in [[PPA]]s''' on Launchpad. This is because software in PPAs are not provided by the official Ubuntu repositories. Instead, the PPA homepage would have a contact point and preference of the PPA provider. The exception is [[LibreOffice]] as per [[https://lists.launchpad.net/libreoffice/msg00072.html|this mail]], as LibreOffice is too big to be tracked via email: as described in the mail, file a bug on Launchpad with tag `ppa`. <
><
> Please '''do not add project tasks to bug reports that are invalid because they are not supported'''. For example, if you were using the LibreOffice PPA and reported a bug against the package libreoffice (Ubuntu), which would be marked Status Invalid, please do not add the Launchpad Project [[https://launchpad.net/df-libreoffice|df-libreoffice]] to the report, or change the package libreoffice (Ubuntu) to the project df-libreoffice. The purposes of adding the upstream project to a report is to track valid bugs in Ubuntu that are valid upstream, and may have been reported upstream, not to start another upstream bug tracker. + <
><
> + When posting new comments to a report, please do not include every past comment made, as doing so makes it onerous to read a report, and is wasteful. Instead just make your new comment, or just include the relevant portion of a previous comment you are responding to. <
><
> '''Many of the triagers and developers who are providing support to you, are volunteers doing so out of altruism. Please keep this in mind when making your comments.'''