From RPM Wiki
| Table of contents |
Summary
All RPM support is managed using the hosted application FogBugz (http://www.fogcreek.com/FogBugz/). Ultimately I would like to see FogBugz used for project management for everything done within RPM Software.
- Logon: Our FogBugz deployment (https://rpm.fogbugz.com/)
- Public: Start a case (https://rpm.fogbugz.com/default.asp?pg=pgPublicEdit), View a case (https://rpm.fogbugz.com/default.asp?pg=pgPublicViewForm)
Cases
In FogBugz everything is a case. A case represents something that needs to be done be it a bug, a feature, or some other task.
- Every case has a globally unique number
Starting a case
A few different ways:
- Login and use the form
- Capture a screenshot with the tool and select the new case option
- Send an email to the cases address (not shown here for spam protection)
- Use the public form (https://rpm.fogbugz.com/default.asp?pg=pgPublicEdit)
When people who aren't RPM FogBugz users (i.e. our customers) enter a case using 3 or 4, they are given a URL to view that case in the future. See "Public access" below.
With FogBugz, most new cases should be added to the "Inbox" project. Sometimes a developer will be instructed to, or it will be obvious to, add a case right into the "RPM" project. If this is done, the "Area", "Priority", and "Fix For" fields must be filled-in. Cases added to the "Inbox" project do not need that information.
Case reference
To reference a case from another case simply enter the number of the case in the comment in the following format: "case {NUMBER}"
- Example: "This case is similar to case 208 from yesterday"
- FogBugz will automatically link the cases and display each on the other's page under "See also"
Duplicate
If a case is going to be dismissed as a duplicate then select "Resolved (duplicate)" as the status and FogBugz will give you a field to enter the number of the original case.
Category
- Bug: A problem with the application
- Feature: Something new that needs to be built
- Inquiry: A question (cases start this way if submitted by a customer).
- Schedule item: Things for us to do internally that aren't directly a part of the application. Example: Upgrading developer workstations to VS 2008
Inbox Project
Cases added by email or the public web form start here for evaluation.
Area
The "Inbox" project has areas for sorting spam.
Development Project
Add all RPM bugs and features here. Cases by email are moved here if they are legit bug/feature.
Area
Most of the areas match sections in RPM, such as "Commissions". For most bugs or features just look at the breadcrumbs to see what area the case should be in. However, there are some exceptions:
- Infrastructure: This is for user-facing things like the logon page, file uploads, and views that span multiple sections of RPM. Example: If it's a problem with views in general then the area is "Infrastructure". If it's a problem with a column specific to commission item views, it's "Commissions".
- Style: The look of the page, JavaScript behavior, etc. are put into a "Style" area to separate these purely client-side bugs and features from "Infrastructure".
- Code: This is for bugs and features than span multiple RPM sections (or don't fit into any) and that involve things the user doesn't see. It also includes things we do in house with source control and file management.
Priority
- Critical: Can't wait for the next deployment.
- Build and upload ASAP, hotfix if possible.
- Bugs only (no features) and must affect live users
- Important: The primary/required features and bugs for a version
- Normal: Other features and bugs that don't have to be fixed
- Maybe: Features that we would like to build, but aren't important enough. Bugs that are very niche and have suitable workarounds.
- Hold: No plan to add this feature.
- Features only (no bugs)
- (not used): FogBugz forces us to have 7 priorities
- (not used): FogBugz forces us to have 7 priorities
I've gone back and forth with my thinking on having a priority level indicate a hotfix. Are a deployment time and a severity really the same thing? If we include a spelling fix in a hotfix, does that make the spelling fix "Critical"? As you can see from this list, my current stance is yes to both questions.
Fix for
An RPM version or "undecided".
Version
Type "dev", "live", or "beta" (for when we do a pre-release deployment to live servers like we often do with CRM).
- Once you've entered a version once, it should be in your browser's auto-complete for future entries if you have that browser feature enabled. This is why I ensured they have different first letters.
Release notes
- See What's new
Support Project
Questions about using RPM, training.
Area
Being developed by Dana.
Hosting Project
Server, network, and database manipulation cases.
Area
Being developed by Jade & Dave.
Website Project
The rpmsoftware.com website.
Area
Not used.
Workflow
1) From a customer by email into FogBugz or web form
- First RPM reviewer cleans up the case
- Edit the title to be short, appropriate, and clear
- Enter the subscriber
- Select the correct project and area
- Select a priority
- Then assigns the case to Jade (development, feature requests), Dana (support, unknown), or Bill (special cases by customer)
or form voice mail forward
- Assign to Dana and support project.
- Dana will listen to the message then fill in the above details.
- Continue with step 1)
or by personal email or phone call
- Enter a case with all appropriate details
- Send an email to the customer (if available) to add them as a correspondant for future communication
- Continue with step 1)
or by RPM staff
- Internally we find bugs and have feature requests.
- If it is a bug, always include a screenshot
- Complete all info and assign to Jade
2) Development
For the overall process of a development version see New version
- Jade reviews the case and if appropriate assigns it to a developer and release
- Developer enters a time estimate
- Comments are added
- Developer commits the changed code adding the FogBugz case number in the commit UI for "BugzID"
- Developer marks the case as resolved. It is automatically assigned to the author.
- Jade may assign it to someone else for testing.
- Tester verifies the fix or feature and then closes the case.
- Add the comment "Verified"
2) Support
- Support rep responds to customer. Preferably through FogBugz. If by phone the conversation should be logged in the.
- If the case is a bug or a feature request assign it to Jade.
- Otherwise
- Enter a time estimate
- Solve the problem as needed
- Resolve then close the case.
Using FogBugz
Public access
From FogBugz help: "When a customer looks at a case, they only see their own correspondence. They see the original case as they entered it, and any email back and forth about the case, but they don't see internal assignments, edits, and conversations conducted by logged-on users."
- Start a case (https://rpm.fogbugz.com/default.asp?pg=pgPublicEdit)
- View a case (https://rpm.fogbugz.com/default.asp?pg=pgPublicViewForm)
New support or dev user
- Get an admin to create a FogBugz user.
- It's web-based so there is no client, although you should install the screenshot tool (see below)
Optional
- Installing the screenshot tool (https://rpm.fogbugz.com/default.asp?pg=pgScreenshotDownload)
- Installing FogBugz for Visual Studio 2005 (http://www.fogcreek.com/FogBugz/KB/setup/InstallFogBugzforVisualSt.html): Simple case browser from the VS 2005 IDE
Subversion link
When a commit is made to our subversion repository, there is a BugzID field where the case number is entered. The server then updates that FogBugz case with the file information.
- Should only be used for cases in the "Development" project
Setup
- All files need the BugzID property: this page has command line instructions (http://www.fogcreek.com/FogBugz/docs/60/topics/sourcecontrol/setup/TortoiseSVN.html), but you can add the same properties with the TortoiseSVN UI. This only needs to be done once for the application or again if a new repository is setup.
Glossary
Hotfix
Copy the files to the server, no rebuild necessary. Users that are in the middle of working should not be affected. That requirement means this is only applicable to style, some database, and simple .aspx fixes.
- Critical priority cases only
Critical update
A new build put on a server without an official version number.
- Critical priority cases only
History
- This page was last modified 20:29, 27 Jun 2008.
- This page has been accessed 1670 times.