Dev team

Facebook Marketing Partner 2

Facebook Marketing Partner 3

Making TicketsDoing it the Right WayTM

Facebook Marketing Partner

Bug Report• Reproduction

• Explain in detail how someone can make this bug happen again for them.

• If you can’t make the bug happen again, describe instead in detail exactly what you did—everything you did—before the bug occurred.

• Example: “Navigate to add a creative to campaign 12345. Select the Live Nation page.”

• Expected Behavior

• What should happen immediately after the steps described in “Reproduction” have been taken.

• Don’t be afraid to be very obvious here.

• The bug will be considered fixed when the software exhibits this behavior.

• Example: “The posts should be displayed in descending order by when they were created.”

• Current Behavior

• What actually happens after the steps described in “Reproduction.”

• As long as the software exhibits this behavior, it is assumed that the but is not fixed yet.

• Example: “The top post on the list is from three months ago, and they don’t seem to be ordered at all based on when they were created.”

• Notes

• You may or may not want to add additional information here.

10


Bug Report

• Depending on the severity of the bug, it will likely be addressed within a few days.

• It’s a judgment call sometimes whether something is truly a “bug,” an annoying feature,

or a feature that “should” already exist.

11


Following Tickets

• You can add users to follow tickets so they receive updates on the status of the ticket

12


Feature Request• User Story

• Who is going to use this feature?

• What should this feature do?

• Why would they want to do this?

• For example: “The admin user should be able to see the campaigns of any company at CitizenNet so that they can more

efficiently share workloads of clients and troubleshoot self-serve clients’ issues.”

• Acceptance Criteria

• Everything that needs to be met for you to be perfectly happy with the feature.

• For example:

• “Admin user shouldn’t have to log out to view a different company’s campaigns.”

• “Non-admin users should not be able to view other companies’ campaigns.”

• “Admin user should be able to groups, campaigns, ad sets, and ads for the chosen company.”

• Et cetera

13


Feature Request

• Try to focus less on what the new feature should look like, or how it should behave, and

focus instead on what you really want to do.

• “A user should be able to delete many campaigns all at once,” is better than “A user

should be able to click a red button in the bottom right corner after selecting a large

number of campaigns and receive a confirmation that they want to delete the selected

campaigns.”

• Features can take longer than bugs to get addressed. They’ll often be grouped up with

other similar features, or sometimes closed in favor of larger feature builds.

• Everyone at CitizenNet and all of our self-serve users use our product in very different

ways. Sometimes a new feature might have more limited utility than you think it does.

14


After You’ve Written Your Ticket

• Don’t set the priority or milestone for a ticket, and don’t assign it to an engineer. Leave

this to Dan and Riley.

• Do check back on your tickets periodically and when someone asks you for more

information. Close any tickets that are no longer needed by setting their status to

“Invalid.”

• Do test the fix or new feature when the status changes to “Test.” In some cases, you

may have to look at it on a testing version for the site. Riley or the developer who

worked on your ticket can help you with this.

• Do ask members of the product team about what they’re working on.

15


After You’ve Written Your Ticket• Sprints: Short development cycles, usually two weeks, with specific goals set in advance. They are

represented in Assembla by milestones, with the date indicating when the sprint will end.

• Status:

• New—The ticket is not yet being worked on.

• Accepted—The team member who was assigned the ticket is now working on it.

• Test—The work is done and should be tested, usually by whoever wrote the ticket.

• Feedback Required—A team member needs more information in order to progress on the ticket.

• Review—The work needs to be re-examined, perhaps because it did not pass testing.

• Verified—The ticket has been adequately addressed.

• Fixed/Released—The ticket has been closed because the work is done.

• Invalid—The ticket has been closed because it is not necessary.

16