|
|
| Line 1: |
Line 1: |
| '''QA Meeting Agenda'''
| | #REDIRECT [Bugsquad/QA_meeting] |
| | |
| Please place the things you wish to discuss at the QA meeting on IRC below.
| |
| | |
| '''In the next meeting...'''
| |
| * I want to discuss how to integrate Fennec as 3rd party app into bugs.maemo.org
| |
| **Do we need ttis integration? Why bugzilla.mozilla.org is not enough?
| |
| **What are alternatives?
| |
| **There is already [https://bugzilla.mozilla.org/show_bug.cgi?id=526798 an open bug for this issue]. Feel free to add your thoughts!
| |
| *How to build a bridge between bugs.maemo.org and [http://maemo.org/packages/repository/qa/fremantle_extras-testing/ the package voting system]
| |
| **As somebody fills bug reports normaly only if I found a bug during normal daily use it would be nice to have a link to the application packge to vote for.
| |
| --[[User:jukey|jukey]] 19:18, 11 November 2009 (UTC)
| |
| | |
| '''Meeting details'''
| |
| | |
| * IRC: irc.freenode.org
| |
| * Channel: #maemo-meeting
| |
| * Time: Tuesday, November 10th, 14:30 UTC
| |
| | |
| '''Agenda'''
| |
| | |
| * QA is good.
| |
| * The criteria are a good start, but need tweaks
| |
| * The packages UI needs some streamlining for testers.
| |
| * As a tester, a better reminder of the checklist when checking would be good. I also like the ease with which I can give feedback.
| |
| * As a developer, I don't *think* I want to be constrained with "release early, release often" when fixing bugs or introducing new small features.
| |
| * We need a mechanism to preserve karma or reset it to zero.
| |
| * Discuss the possibility of PPAs or personal repositories.
| |
| * specific bug report should always be required to block a package from entering Extras.
| |
| * Developer's karma and tester's karma should be incorporated so that a "developer with high karma would be able to push packages through the process faster, and a high rolling tester would be able keep bugs open and classified as critical in case of disagreement."
| |
| * Bugtracker field should be a blocker ? what about background packages ?
| |
| * What to do with CLI apps ?
| |
| * Allow people to vote multiple time.
| |
| '''Actionable items'''
| |
| | |
| 1. We recommend lowering acceptable karma from 10 to 5.<br>
| |
| 2. Thumbs down requires a comment as well.<br>
| |
| 3. Testers should follow the checklist closely so it is clear what the testing criteria are. <br>
| |
| 4. Positive package karma gets preserved for bug fixes, cosmetic changes.<br>
| |
| 5. Allow people to cast more than one vote for a package.<br>
| |
| 6. App authors should be *prevented* from thumbing up own app and that a maintainer thumbing it down removes it from the QA list
| |
| 7. PPAs are bad.
| |
| 8. Without an application, libraries do not go through the QA process.
| |
| tester logs in, reviews app metadata on web, installs via .install, tests and then votes ;-)
| |
| | |
| | |
| '''Wishlist'''
| |
| | |
| 1. Approval interface available in Application Manager.
| |
| 2. User clicks a series of checkboxes, the app gets promoted automatically.
| |
