Redmine Tracker definitions
"Trackers" allow us to organize our tickets based on the kinds of tasks they represent. Think of this organization, in part, as a preliminary way of describing which team should be primarily responsible for a given ticket.
Here is a description of each of our Tracker types.
Any aspect of the site that is intended to work one way, but does not. Filing as a Bug calls it to the attention of the dev team.
Any feature that does not currently exist on the site, but should. Call to the attention of the dev team.
A support request from an end user. Next step in the workflow is usually the community team.
Tasks related to documentation, eg new Codex pages. Next step in the workflow is the community team.
Tasks related to community outreach. Campus talks, workshops, presentations.
Publicity tasks are things like: emails that go to our membership list, Hero Slides, blog posts for major releases.
Issues that start as design discussions or questions for UX feedback. These will first go to the UX team, but may be moved to the Bug or Feature tracker once ready for implementation.