Project

General

Profile

Task #1405

Bughunting Sessions

Added by Florian Effenberger over 2 years ago. Updated about 2 years ago.

Status:
In Progress
Priority:
Normal
Target version:
-
Start date:
Due date:
2015-10-30
% Done:

0%

Estimated time:

Description

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

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.

Session

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.

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.

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

Related issues

Copied to Release Engineering - Task #1427: Bughunting SessionsClosed2016-10-17

Copied to Release Engineering - Task #1431: Bughunting SessionsClosed2016-10-17

History

#1 Updated by Sophie Gautier over 2 years ago

Just to add some details:
- BH on last Alpha (e.g mid October for 5.1)
- BH on Beta1 (e.g. mid November for 5.1)
- BH on RC1 (e.g. mid December for 5.1)

  • Communication on each BH begin one month before with a reminder 15 days and 3 days before.
  • Banner should be added to BZ, wiki and site
  • Wiki page set before communication so a month before
  • mentor added to the wiki page at least a week before
  • check with Cloph the availability of the build a day before

#2 Updated by Sophie Gautier over 2 years ago

Link to wiki page containing details of the organization
https://wiki.documentfoundation.org/BugHunting_Organization

#3 Updated by Sophie Gautier over 2 years ago

Copying the wiki page here:

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.

Session

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.

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.

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

#4 Updated by Florian Effenberger over 2 years ago

#5 Updated by Florian Effenberger over 2 years ago

#6 Updated by Sophie Gautier over 2 years ago

  • Description updated (diff)

#7 Updated by Christian Lohmaier about 2 years ago

Proposal: Tag of alpha1 on week 42, and doing bughunting session on week 44

Can use the announcement of alpha1 to point people to the bughunting session, and still have some time to address found issues until feature freeze/branch off in week 47

#8 Updated by Sophie Gautier about 2 years ago

  • Due date set to 2015-10-30

#9 Updated by Florian Effenberger about 2 years ago

  • Target version deleted (Recurring)

#10 Updated by Florian Effenberger almost 2 years ago

  • Related to Task #1761: improve Bug Hunting Sessions added

#11 Updated by Florian Effenberger over 1 year ago

  • Related to deleted (Task #1761: improve Bug Hunting Sessions)

Also available in: Atom PDF