Guidelines for Filing Lighthouse Tickets

FilingIssues.md

Lighthouse Ticket Guidelines

1. Please provide a detailed description of the problem and the expectation.

2. Reproduction sequence including any working sample code or simplified project required to duplicate the problem.

3. If there is a Q&A or Helpdesk item involved please put a link to the thread in the ticket. Hyperlink it please.

4. Set the "Who's responsible?" field. See the platform sections below for the appropriate platform responsible party.

5. Tags are important. Each ticket should have these tags plus a platform identifier tag

• One of [defect | feature].
• If the issue is from a HD ticket please add the rplist tag.
• If the issue is from an enterprise or large external client please add the enterprise tag.
• If it's a defect and it worked in a previous release, then the regression tag is required.
• We also require the reported-X.X.X tag to know the found in version. (e.g. reported-1.5.1)

6. Any device, emulator/simulator, OS version, etc. that's pertinent to the issue.

7. Please format the issue appropriately using this formatting guide

8. If a platform engineer hasn't specified a milestone, please at least set it to TBS so it will appear in queries. You may also set a scheduling tag tbs-X.X.X as a reminder of when it should be pulled into a release. This is an optional tag normally set by the responsible party.

Android tickets

1. Platform tag is android

2. Please provide the stacktrace and trace level log.

3. Responsible party: Don Thorp

iOS Tickets

1. Platform tag is ios

2. Please provide a debug level log and a console log.

3. Responsible party: Reggie Seagraves

API Documentation Issues

1. Platform tag is apidoc

2. Responsible party: Don Thorp

Desktop Issues

1. Platform tag (each occurring platform): linux, mac, win

2. Responsible Party: Josh Roesslein

Workflow

Once tickets have been scheduled into a milestone. There are various state changes that it should go through.

1. When a developer starts working on a ticket it should be moved into the in-progress state to signal that someone is working the issue. Other open tickets not marked in-progress are available for other team members to work if they get done early.

2. When a developer finish addressing an issue and is ready to have it tested. The state should transition to fixed-in-qa. This is normally done in the github commit message. Release tags release-X.X.X should be added for each branch the fix is committed on (e.g. release-1.5.2). Use the working version on the particular branch so that we can determine when it was added more easily. That version is in the build/titanium_version.py. **Note: ** items on master, typically X.X.0, can be bulk tagged at the end of the release with the release-X.X.0 tag.

3. If the developer is unable to reproduce the issue or has other questions. The state of the ticket should be changed to needs_more_info and the Responsible party field set to the party that should provide the information. Once the information has been provided, the Responsible party should be set back to the developer asking the question and the state changed back to new or in-progress depending on what the state was when it was changed to fixed-in-qa

4. Once the issue has been verified as fixed, it's state should be moved to resolved. Normally, this would be someone from QE or QA, but it could be anyone other than the original developer.

• Always set the "Who's responsible?" field to me, that way I'll get notified when the ticket is entered.

Test case/app.js attachment required?

Good point @kevin

For iOS, a debug log is good, but also the console output is also desirable.

Should Desktop tickets get kicked to Ralf as well?

If you want you can assign desktop tickets to me by default.

@josh do you want any platform tags added.

Yeah add a tag for each platform the issue is present on: mac, win, linux

Who do we assign TiDeveloper tickets to?