Each instance of Manuscript can be used to keep track of multiple projects. A project is a long-running unit of work which is typically never “complete.” On typical software teams, you might set up a project for every individual product that you develop. New Manuscript accounts have a project already set up called “Inbox” which is intended to be used for cases dedicated to customer correspondence, which is another example of a type of work which is never complete and therefore gets its own project.
Within each project, you can divide cases into areas which are aspects of the larger project but still largely separate from each other. For example, a software project might have separate areas for front-end code, back-end code, and documentation. Alternatively, the Inbox project might have separate areas called “Sales” and “Support”. Each area is a part of the larger project, but is more-or-less separate from the other areas in the project.
Setting Up Projects and Areas
An administrator can create and edit projects and areas by navigating to Avatar menu > Projects. Administrators can also determine which users can view, create and edit cases within a project with permissions set on the project configuration page.
Each project has a primary contact. The primary contact is the default person whom you’ve designated to look at cases in this project and take the appropriate action (e.g. set their priority, assign them to the correct developer to fix, or send back to the opener requesting more information). When someone enters a new case, they usually leave it assigned to the primary contact. In Manuscript, every case is always assigned to one person, which helps cases from falling through the cracks!
If desired, you can also set up different primary contacts for each area. By default, areas will inherit their primary contact from the project they are in.
If you are working on a large project team, you may want to have several people who help sort through new cases. To do this, we suggest that you set up a virtual user account called “Up For Grabs” and make that the primary contact of the project. You can use as many email addresses as you want for the Up For Grabs user, separated by commas, so that a group of people receive an email notification whenever there’s a new case in a particular project. Anyone who wants to help sort through new bugs can create a saved filter on “all cases assigned to Up For Grabs” which they check occasionally, or you can create this filter as a shared filter so that all users can see it.
Creating Good Areas
In general you’ll find that the fewer areas you have, the more likely people are to categorize cases correctly into the right area. Think of it this way: if you have 100 areas, everybody who enters a case is going to have to consider each of those 100 areas to decide which area is the best fit. Inevitably, cases will be miscategorized, and the pain of choosing an area may even make people enter fewer cases. If it’s easier to jot down a case than enter it into Manuscript, you’re going to lose the benefit of bug tracking.
Our recommended approach is to start with just one area, called Miscellaneous, and use it for everything.
Then, add areas only after careful consideration—and only if they are needed for a particular filter that you want to create. For example, if you have a team of technical writers and they want to be able to see all the bugs in the documentation, create an area called Documentation.
Don’t create more areas than you absolutely need, because the more you have, the more likely cases will be misfiled. If you need finer categorization, you might consider using tags. You can also group cases into hierarchies with subcases.
You can set a project to allow public submissions.