QA meeting
(wikify)
 
(20 intermediate revisions not shown)
Line 1: Line 1:
-
'''QA Meeting Agenda'''
+
==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.  
-
'''Meeting details'''  
+
'''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'''
+
===Agenda===
* QA is good.
* QA is good.
Line 17: Line 26:
* 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.
* 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.
* 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 ;-)
 +
 +
===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

  1. We recommend lowering acceptable karma from 10 to 5.
  2. Thumbs down requires a comment as well.
  3. Testers should follow the checklist closely so it is clear what the testing criteria are.
  4. Positive package karma gets preserved for bug fixes, cosmetic changes.
  5. Allow people to cast more than one vote for a package.
  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 ;-)

[edit] Wishlist

  1. Approval interface available in Application Manager.
  2. User clicks a series of checkboxes, the app gets promoted automatically.
Retrieved from "http://wiki.maemo.org/QA_meeting"