From Fedora Project Wiki

m (fix typo in command)
(F19 Alpha links)
Line 23: Line 23:


* What: A list of all contributors who filled in some test case results in our [[QA/Join#Release_validation|release validation wiki matrices]].
* What: A list of all contributors who filled in some test case results in our [[QA/Join#Release_validation|release validation wiki matrices]].
* How: Use [http://git.fedorahosted.org/cgit/fedora-qa.git/tree/stats-wiki.py stats-wiki.py]: {{#tag:pre|$ ./stats-wiki.py {{FedoraVersionNumber|next}} -f Beta > stats.html}}
* How: Use [https://git.fedorahosted.org/cgit/fedora-qa.git/tree/stats/stats-wiki.py stats-wiki.py]: {{#tag:pre|$ ./stats-wiki.py {{FedoraVersionNumber|next}} -f Beta > stats.html}}
* When: Created and sent out for every Fedora Branched milestone (Alpha/Beta/Final) separately (i.e. don't include previous milestones numbers in the current stats).
* When: Created and sent out for every Fedora Branched milestone (Alpha/Beta/Final) separately (i.e. don't include previous milestones numbers in the current stats).
* Examples: [https://kparal.wordpress.com/2012/12/03/the-heroes-of-fedora-18-alphabeta-testing/ F18 Alpha+Beta], [https://kparal.wordpress.com/2013/01/14/the-heroes-of-fedora-18-final-testing-wiki-matrices F18 Final]
* Examples: [https://kparal.wordpress.com/2012/12/03/the-heroes-of-fedora-18-alphabeta-testing/ F18 Alpha+Beta], [https://kparal.wordpress.com/2013/01/14/the-heroes-of-fedora-18-final-testing-wiki-matrices F18 Final], [https://kparal.wordpress.com/2013/05/06/the-heroes-of-fedora-19-alpha-testing/ F19 Alpha]


== Release validation - Bugzilla ==
== Release validation - Bugzilla ==


* What: A list of all reporters who created new bug reports in [http://bugzilla.redhat.com/ Bugzilla] against a specific Fedora release.
* What: A list of all reporters who created new bug reports in [http://bugzilla.redhat.com/ Bugzilla] against a specific Fedora release.
* How: Use [http://git.fedorahosted.org/cgit/fedora-qa.git/tree/stats-bugzilla.py stats-bugzilla.py]: {{#tag:pre|$ ./stats-bugzilla.py --threshold 5 18 Final 2012-11-29 2013-01-15 > stats.html}} The dates denote the start and end date for the specific milestone (in this example 18 Beta release and 18 Final release dates).
* How: Use [http://git.fedorahosted.org/cgit/fedora-qa.git/tree/stats/stats-bugzilla.py stats-bugzilla.py]: {{#tag:pre|$ ./stats-bugzilla.py --threshold 5 18 Final 2012-11-29 2013-01-15 > stats.html}} The dates denote the start and end date for the specific milestone (in this example 18 Beta release and 18 Final release dates).
* When: Created and sent out for every Fedora Branched milestone (Alpha/Beta/Final) separately (i.e. don't include previous milestones numbers in the current stats).
* When: Created and sent out for every Fedora Branched milestone (Alpha/Beta/Final) separately (i.e. don't include previous milestones numbers in the current stats).
* Examples: [https://kparal.wordpress.com/2013/02/04/the-heroes-of-fedora-18-final-testing-bugzilla/ F18 Final]
* Examples: [https://kparal.wordpress.com/2013/02/04/the-heroes-of-fedora-18-final-testing-bugzilla/ F18 Final], [https://kparal.wordpress.com/2013/05/06/the-heroes-of-fedora-19-alpha-testing/ F19 Alpha]


[[Category:QA SOPs]]
[[Category:QA SOPs]]

Revision as of 11:22, 10 May 2013

There are a lot of people who spend their time on QA-related activities. Some of them are Red Hat employees who are paid for this, some of them are Red Hat employees who do it in their free time, and large portion of them is the community. We would like to recognize their work as valuable and publicly thank them for their effort regularly.

Recommendations

  • Name people explicitly
    Don't post just a general un-targeted letter, but try to name the most helpful people explicitly. Seeing your name publicly is very gratifying and motivating. It's the least we can do for the people helping us out. If possible and within some reasonable limits, name all the contributors, not just the top ones.
  • Attach result values, but carefully
    If there are any numbers connected with the names (number of executed test cases, reported bugs, etc), you can add them too and create some form of ladder. This should be done carefully, though. It will certainly please people at the top and can motivate others to increase their effort next time. But, on the other hand, it might discourage some. The results should be taken lightly and with humor in the adjacent text, rather than considering it a serious metric. You should mention that these numbers should be taken with a pinch of salt, because they are inherently incomplete (e.g. different test cases have different complexity, and also it covers just one particular area of QA activities). Adam is putting it very nicely here.
  • Don't filter nor brand the contributor list
    Filtering the list based on community/Red Hat membership is not recommended. You never know who participated in his/her free time and who was paid for it. Relevant discussion is in this thread. Branding Red Hat employees is not recommended as well, it might be seen as some 'elite' club. But it is recommended to acknowledge in your text that many of the contributors are Red Hat employees and specifically call out community contributors who did an outstanding job and thank them once again.
  • Do not re-use old letters too much
    If you re-use your letter over and over again, just changing the list of contributors, it will appear as computer-generated. That does not convey the right message. It must include a human touch if it is to be sincere. Of course there's nothing wrong with re-using some old headers and footers of the letter, but the main text should not be copy-and-pasted, but written completely anew.
  • Encourage people to join the testing effort
    Include information for newcomers how to join the effort and help us out in future activities.


Our regular recognition letters

This is a list of recognition letters we try to send out regularly and their short description.

Release validation - wiki matrices

  • What: A list of all contributors who filled in some test case results in our release validation wiki matrices.
  • How: Use stats-wiki.py:
    $ ./stats-wiki.py 40 -f Beta > stats.html
  • When: Created and sent out for every Fedora Branched milestone (Alpha/Beta/Final) separately (i.e. don't include previous milestones numbers in the current stats).
  • Examples: F18 Alpha+Beta, F18 Final, F19 Alpha

Release validation - Bugzilla

  • What: A list of all reporters who created new bug reports in Bugzilla against a specific Fedora release.
  • How: Use stats-bugzilla.py:
    $ ./stats-bugzilla.py --threshold 5 18 Final 2012-11-29 2013-01-15 > stats.html
    The dates denote the start and end date for the specific milestone (in this example 18 Beta release and 18 Final release dates).
  • When: Created and sent out for every Fedora Branched milestone (Alpha/Beta/Final) separately (i.e. don't include previous milestones numbers in the current stats).
  • Examples: F18 Final, F19 Alpha