David Recordon (daveman692) wrote in lj_dev,
David Recordon
daveman692
lj_dev

Opening Zilla Bugs

As Zilla usage has picked back up this past week, we wanted to take a minute to refresh everyone on its usage, especially when opening bugs.


When you first goto open a new bug, please first search to make sure no other bugs exist for the issue. Descriptive subjects when opening bugs makes this much easier. If a bug does exist, a simple "Me too!" is much less helpful than information concerning how you reproduced the bug.

Product:
Most bugs that you open will relate to the "LiveJournal" product. Others may related to LJCom, although try and make sure you know which one it should go into. If you aren't sure, it can always be moved later by someone who does know.

Component:
When selecting a component, realize you may not always be able to find the one that you feel is correct. In this case, find the one that fits the best. Not wanting to think is not an excuse to just put it in "General/Unknown". Please also suggest new components if you feel there is one not there that should be.

Priority and Severity
While these two often seem related, and they can be, they also are quite different. In many cases it is reasonable to leave the priority at its default setting and only set the severity. Any bug that causes data loss would be considered critical, we don't really use the blocker severity level. A new feature addition would be considered an enhancement for severity, but could have a higher priority. Once again, these values can, and often are, changed later after a bit of discussion has occurred.

Assign To:
When you select a component, this field is automatically filled in for you. While many cases you may not know who else to assign it to, avva@livejournal.com has quite a few bugs. If you are following changelog you should be able to pick up trends in terms of which employees are currently working on what. Please feel free to assign bugs to us as we can always reassign them later, but don't assign them to us without thinking about it first. Please also feel free to assign bugs to yourself if it is something you are interested in or want to work on.

Cc list:
While you are more than welcome to assign a bug to a staff member, please do not CC all of us on bugs. This just fills our in boxes with lots of mail and causes us to get annoyed. Please however CC people who are appropriate to the bug, both staff and other volunteers. For example, if you don't assign a QuickReply bug to me then it makes sense to CC me on it to make sure I see the bug. Don't rely on us just seeing a bug, if you feel it is vital for one of us to see it then CC us. If discussion prior to opening the bug took place in a support request, it may also make sense to CC volunteers who took place in it in the request.

URL:
This is useful if it is easy to provide an example of this bug. If it requires steps to reproduce, then just include these steps and URLs in the description. If this bug is being filed from a support request, then please provide the link to the request here.

Summary:
Please make sure to include a descriptive subject. This is what allows people to quickly find bugs as well as see what they are interested in. Also make sure that your wording will make sense to someone who doesn't know anything else about the bug. "Disabling QuickReply Always" is a bad subject, "Always Disable QuickReply" is also a bad subject, although "QuickReply Does Not Respect Being Disabled In Communities" is a good subject. Be verbose, but don't overdo it.

Description:
This is where you get to provide as much information as you know about the bug that you are reporting. Please provide links to examples, steps to reproduce the bug, information concerning why it is a bug if it isn't painfully obvious, who this is effecting, any research you have done on the bug, etc. If you have started to look at code, please also include what you have found, if it is relevant, so others don't need to do the same research that you just have. It is quite difficult to ever provide too much information, although quite easy to provide too little.

Keywords:
Most new bugs will not have any keywords, but rather they will be added later. The main keywords new bugs may use are i18n, meta, policy, wishlist, and xhtml.

Depends on and Blocks
If other bugs are already opened that either depend on this bug being fixed, or this bug will not allow another bug to be fixed, then include a comma separated list of the bug numbers in these fields. Most new bugs will not block other bugs, although some may depend on others. Research prior to opening the bug will inform you about this.

Only users in all of the selected groups can view this bug:
Bugs that are security issues or contain private information should be placed into one of the two security groups. When you are opening a bug that should be private, you'll know it.

Questions?
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 20 comments