QA meeting
(wikify) |
|||
(18 intermediate revisions not shown) | |||
Line 1: | Line 1: | ||
- | + | ==QA Meeting Agenda== | |
- | Please place the things you wish to discuss at the QA meeting on IRC below. | + | 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 | * IRC: irc.freenode.org | ||
Line 9: | Line 18: | ||
* Time: Tuesday, November 10th, 14:30 UTC | * Time: Tuesday, November 10th, 14:30 UTC | ||
- | + | ===Agenda=== | |
* QA is good. | * QA is good. | ||
Line 20: | Line 29: | ||
* specific bug report should always be required to block a package from entering Extras. | * 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." | * 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''' | ||
+ | |||
+ | # We recommend lowering acceptable karma from 10 to 5. | ||
+ | # Thumbs down requires a comment as well. | ||
+ | # Testers should follow the checklist closely so it is clear what the testing criteria are. | ||
+ | # Positive package karma gets preserved for bug fixes, cosmetic changes. | ||
+ | # Allow people to cast more than one vote for a package. | ||
+ | # App authors should be *prevented* from thumbing up own app and that a maintainer thumbing it down removes it from the QA list | ||
+ | # PPAs are bad. | ||
+ | # 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=== | ||
+ | |||
+ | # Approval interface available in Application Manager. | ||
+ | # User clicks a series of checkboxes, the app gets promoted automatically. | ||
+ | |||
+ | [[Category:Community]] | ||
+ | [[Category:Quality Assurance]] |
Latest revision as of 07:53, 12 July 2010
Contents |
[edit] QA Meeting Agenda
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 an open bug for this issue. Feel free to add your thoughts!
- How to build a bridge between bugs.maemo.org and 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.
--jukey 19:18, 11 November 2009 (UTC)
[edit] Meeting details
- IRC: irc.freenode.org
- Channel: #maemo-meeting
- Time: Tuesday, November 10th, 14:30 UTC
[edit] 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
- We recommend lowering acceptable karma from 10 to 5.
- Thumbs down requires a comment as well.
- Testers should follow the checklist closely so it is clear what the testing criteria are.
- Positive package karma gets preserved for bug fixes, cosmetic changes.
- Allow people to cast more than one vote for a package.
- App authors should be *prevented* from thumbing up own app and that a maintainer thumbing it down removes it from the QA list
- PPAs are bad.
- 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 ;-)
[edit] Wishlist
- Approval interface available in Application Manager.
- User clicks a series of checkboxes, the app gets promoted automatically.
- This page was last modified on 12 July 2010, at 07:53.
- This page has been accessed 36,456 times.