Task #1405
Updated by Sophie Gautier over 8 years ago
We regularly organize Bughunting Sessions.
This requires
* agreeing on and announcing a date in time
* nail down "point of no return" by when we need to have snapshot instead of delayed RC
* staff some key times with QA representatives to guide new users
h2. Communication
One month before the week-end of the bug-hunting session, some preparation for communication is needed:
* create the page on the wiki
* create the banners that should be placed on
** the wiki page
** the wiki event page
** the website
** BugZilla
* create a Redmine ticket containing the dates and a link to the page in order for Italo to issue a PR when he sees the time is best
15 days before make a new call for participation on lists and social media.
h2. Session
h3. The day before
* Make sure the wiki page has all information
* Make sure that MozTrap run is available
* * Make sure there is a mentor available on the page with his name and mail address*
* Make sure the release is not delayed, if it is:
** point the testers to another release on master
** communicate on the QA and Projects lists and on IRC
** create a new run on MozTrap pointing to the right version.
h3. During the session
** Make sure there is always a mentor available*
* Make sure that cross communication is working
* Check again the availability of the version to test.ant the links on the wiki page.
* Organize testing sessions on a dedicated module or new major functionality (e.g test on Writer only for 2 hours)
* Insist on that it's not a triaging session and anybody should concentrate on testing and reporting bugs only.
h3. After the session
* Remove the banners from
** the wiki event page
** the website
** Bugzilla
* Collect metrics on participants (also NLPs participation)
* Collect metrics on bug reports, triage
* Collect metrics on MozTrap runs
* Thanks everybody for his participation on lists and social media