Bugzilla: Difference between revisions Discussion View history

No edit summary
Line 1: Line 1:
[http://www.bugzilla.org/ Bugzilla] is an external bug tracking system used internally by Waze technical teams.
[http://www.bugzilla.org/ Bugzilla] is an external issue tracking system used internally by Waze technical teams.


[https://bugs.waze.com/ Waze Bugzilla] is partially open to the community with different access level permissions in order to make the status of bugs and feature requests visible.
[https://bugs.waze.com/ Waze Bugzilla] is partially open to the community with different access level permissions in order to make the status of bugs and feature requests visible.
Line 5: Line 5:
=Structure=
=Structure=


Waze Bugzilla is divided to two main '''classifications''':
We have two '''classifications''' in which the items are organized:
 
# '''''Internal''''' - accessible to Waze staff only
# '''''Internal''''' - accessible to Waze staff only
# '''''Public''''' - accessible to all with different permission levels
# '''''Public''''' - accessible to all with different permission levels


Each classification contains different '''products'''.
Most items will be in the public area, but some will be restricted and visible to staff only. We'd usually want to be transparent, but sometimes we are limited by privacy and security concerns.
There are two public products, each of them also having corresponding products in the internal part as well.
 
Each classification contains two '''products''' - the general Waze client and services product, and the Waze Map Editor product.


=Permissions=
=Permissions=
Line 16: Line 18:
==View only==
==View only==


Anyone can access most of the public bugs in view mode with no need to login.
Anyone can access and see all of the public bugs with no need to login. Internally, we can mark some of the comments as private for staff only, but the rest of the details are publicly visible.


==Comment & Vote==
==Comment & Vote==
Line 27: Line 29:
**Editor/App beta-testers
**Editor/App beta-testers


The users in this permission level have the right to vote on 25 items they think are the most critical, and to add comments with additional information about bugs and features.


==Bug Submitters==
==Bug Submitters==
Line 32: Line 35:


=General guidelines=
=General guidelines=
*Voting
===Voting===
**Vote on what you think are the most pressing issues we need to address. Votes are your method to express your concerns. We deeply care about the concerns of our community, we consider the vote count, but can't always fit our development efforts to it. There are other things we are forced to consider such as development dependencies, infrastructure issues, business development, things that are easier / harder to develop, etc. However - your votes are your voice and it's important to us. Use them wisely.
*Vote on what you think are the most pressing issues we need to address. Votes are your method to express your concerns. We deeply care about the concerns of our community, we consider the vote count, and try to prioritize our development process according to it. There are other things we are forced to consider such as development dependencies, infrastructure issues, business development, things that are easier / harder to develop, etc. However - your votes are your voice and it's important to us. Use them wisely.
*Comment with helpful information:
**Bugs - ways to reproduce them, description of environments in which they occur, examples.
**Requirements - specific use cases which are difficult to perform with the current implementation.
*We are trying to keep everything very focused. Try to refrain from adding irrelevant information such as off-topic stuff, reproduction of other issues, requests, opinions, social interaction, etc - this things are what the forums are for.


*Before asking our experts to open a new bug report, please verify that it hasn't been already reported.
===Commenting===
 
If you have the appropriate permission level, you are welcome to provide more information using the commenting system.
 
*Bugs - ways to reproduce them, description of environments in which they occur, examples.
*Requirements - specific use cases which are difficult to perform with the current implementation.
 
We are trying to keep everything very focused. Try to refrain from adding irrelevant information such as off-topic discussion, reproduction of other issues, requests, opinions, social interaction, etc - this things are what the forums are for.
 
===Duplicates===
 
One thing one should be careful when managing an issue tracking system is duplicate entries. Before asking our experts to open a new bug report, please verify that it hasn't been already reported using the search tools.


=Public Products=
=Public Products=
*[[Waze Version 3.5 | The Waze application]]
*[[Waze Version 3.5 | The Waze application]]
*[[Waze Map Editor | The Waze Map Editor]]
*[[Waze Map Editor | The Waze Map Editor]]
=Map Editor Bugzilla=
These guidelines are specific to the map editor product.
===Issue types===
The '''Issue Type''' field says whether an issue is Bug or Requirement. Bug means something that should already work but is not working correctly, a requirement means a feature we'd like to see implemented.
===Prioirty ratings===
'''Priority Rating''' is the ranking we set for the issue. The scale is 1-1000, 1000 is we're-not-going-to-sleep-until-it's-done, 1 is maybe-someday. We set the prioirty according to all the considerations we take into account, and may change it when the conditions change.
===Status Workflow===
We change status from '''UNCONFIRMED''' to '''CONFIRMED''' or another status as soon as we go over an issue to make sure we understand what it means. Sometimes we will change the status to '''NEED INFO''' which means, uhm, that we need more info - usually specific steps to reproduce a bug. '''IN PROGRESS''' means we are currently working on this. '''RESOLVED''' means we fixed the bug and deployed it to the beta environment, '''VERIFIED''' means it does not reoccur after deployment.
===Build number===
When submitting a bug, it is important to note what was the active editor sub-version the bug was identified in. In the beta editor you can see the currently deployed version in the top left corner. v1.2-32 means version 1.2, and the build number is 32.

Revision as of 10:49, 12 June 2013

Bugzilla is an external issue tracking system used internally by Waze technical teams.

Waze Bugzilla is partially open to the community with different access level permissions in order to make the status of bugs and feature requests visible.

Structure

We have two classifications in which the items are organized:

  1. Internal - accessible to Waze staff only
  2. Public - accessible to all with different permission levels

Most items will be in the public area, but some will be restricted and visible to staff only. We'd usually want to be transparent, but sometimes we are limited by privacy and security concerns.

Each classification contains two products - the general Waze client and services product, and the Waze Map Editor product.

Permissions

View only

Anyone can access and see all of the public bugs with no need to login. Internally, we can mark some of the comments as private for staff only, but the rest of the details are publicly visible.

Comment & Vote

This permission level requires a login. A login requires submitting an application.

  • At this time, only the following will be eligible for a login:
    • Local / Global champs
    • Experts / Coordinators
    • Editor/App beta-testers

The users in this permission level have the right to vote on 25 items they think are the most critical, and to add comments with additional information about bugs and features.

Bug Submitters

Bug Submitters have permission to post new bugs and are hand-picked by Waze.

General guidelines

Voting

  • Vote on what you think are the most pressing issues we need to address. Votes are your method to express your concerns. We deeply care about the concerns of our community, we consider the vote count, and try to prioritize our development process according to it. There are other things we are forced to consider such as development dependencies, infrastructure issues, business development, things that are easier / harder to develop, etc. However - your votes are your voice and it's important to us. Use them wisely.

Commenting

If you have the appropriate permission level, you are welcome to provide more information using the commenting system.

  • Bugs - ways to reproduce them, description of environments in which they occur, examples.
  • Requirements - specific use cases which are difficult to perform with the current implementation.

We are trying to keep everything very focused. Try to refrain from adding irrelevant information such as off-topic discussion, reproduction of other issues, requests, opinions, social interaction, etc - this things are what the forums are for.

Duplicates

One thing one should be careful when managing an issue tracking system is duplicate entries. Before asking our experts to open a new bug report, please verify that it hasn't been already reported using the search tools.

Public Products

Map Editor Bugzilla

These guidelines are specific to the map editor product.

Issue types

The Issue Type field says whether an issue is Bug or Requirement. Bug means something that should already work but is not working correctly, a requirement means a feature we'd like to see implemented.

Prioirty ratings

Priority Rating is the ranking we set for the issue. The scale is 1-1000, 1000 is we're-not-going-to-sleep-until-it's-done, 1 is maybe-someday. We set the prioirty according to all the considerations we take into account, and may change it when the conditions change.

Status Workflow

We change status from UNCONFIRMED to CONFIRMED or another status as soon as we go over an issue to make sure we understand what it means. Sometimes we will change the status to NEED INFO which means, uhm, that we need more info - usually specific steps to reproduce a bug. IN PROGRESS means we are currently working on this. RESOLVED means we fixed the bug and deployed it to the beta environment, VERIFIED means it does not reoccur after deployment.

Build number

When submitting a bug, it is important to note what was the active editor sub-version the bug was identified in. In the beta editor you can see the currently deployed version in the top left corner. v1.2-32 means version 1.2, and the build number is 32.