Developers#

This chapter is for the people who do the work the tracker tracks. It assumes you have an account and can find an issue; Reporters covers that. What follows is the process – the states an issue walks and who may move it, how work is taken up and measured, how the tracker decides what you should do next, and what a trivial change may skip.

Not every project uses all of it. A project is either a plain one, which behaves exactly like MantisBT, or one that runs the compliance process, which has more states, named roles and a clock. The project page says which; this chapter marks what belongs only to the process.

Finding the work#

The issue list is one filter and one page of results. The filter box above it is collapsed until you open it; what you set there stays set for your session and for that project.

A few things in it are worth knowing:

Several values in one criterion are an or, and several criteria are an and: status assigned or confirmed, and handler you.
[any] means the criterion is not applied, which is not the same as “empty”; to find issues with no target version, pick the explicit “none” entry where one is offered.
A filter can be saved under a name (Save Current Filter), and a saved filter can be made public, which puts it in everybody’s list for that project. That is how a team keeps “the queue” or “waiting for release” in one place instead of in everybody’s memory.
Manage Columns in your account pages decides which columns this list, the print view and the CSV export show.
The list is also a CSV, an Excel workbook, a Word document, a print view and an RSS feed; the buttons are above the list.

#123 in any text is a link to the issue, ~456 to a note, and the Issue # box at the top right jumps to a number directly.

The life of an issue#

A plain project uses MantisBT’s statuses: new, feedback, acknowledged, confirmed, assigned, resolved, closed. Who may set which is per-status configuration, and the project’s workflow decides which status may follow which.

The update page — Figure 11 `Edit` on an issue: every field at once. The buttons on the issue itself make the single moves; this page is for the rest.#

A project running the compliance process uses twelve, and the order is the process:

Code	Status	What it means
10	new	Reported, nobody has looked at it yet.
15	planning	Somebody is working out what it takes: the estimate, the children it breaks into, who does the steps.
30	acknowledged	The management agrees the work should be done.
40	confirmed	The plan is finished: estimated, divided, with the roles named.
50	assigned	Somebody is implementing it.
60	implemented	The change exists and is handed over for control.
65	reviewed	Somebody other than the implementer has controlled it.
70	integrated	It is in the release that will carry it.
75	deployed	It is where users meet it.
80	verified	Somebody has checked that the change does what the issue asked.
86	informed	Whoever had to be told has been told.
90	closed	Done.

The buttons on the issue page are the moves: Start Planning, Implemented, Controlled, Integrated, Deployed, Verified, Informed. Each is offered only to somebody who may make that move, and the project’s workflow matrix is enforced when the form is submitted, not merely when it is drawn: a transition the matrix does not name is refused however the request reaches the tracker.

Who does what#

The four roles on the update page — Figure 12 In a compliance project the update page asks for the four roles instead of a single “Assigned To”.#

Four people, each a field of the issue:

Implementer: Writes the change.
Reviewer: Controls it. Never the implementer – the tracker refuses it.
Verifier: Checks that what was asked for is what was delivered. A project can require that this is not the implementer either (“Verifier is not the implementer” on the project page); by default it may be.
Communicator: Tells whoever has to be told. A project can name a default communicator, so a new issue has one from the start.

“Assigned To” – the handler – is not asked for in such a project: it follows the state. Whoever must act next is the handler, so the “my issues” box, the mail and every list that keys on the handler stay right without anybody maintaining them.

An issue in a compliance project — Figure 13 An issue of a compliance project: the roles, the plan, the estimate, the deadline and the notification list, beside MantisBT’s own fields.#

Planning#

An issue that is big is divided. Add child issue on the issue makes one, inheriting what makes sense from the parent, and you name who plans it: that person is on the hook for the child’s plan, and the child is theirs from the moment it exists.

The plan box on the parent adds up the hours: this issue, its children, and the two together. While any part is unplanned the box names it and the plan cannot be finished – the move from planning to confirmed is refused with the list of what is missing.

Estimates are hours, entered as hours. A project switches them on (“Effort estimates” on the project page); a compliance project always has them. An estimate is what the work is expected to take, not what you hope; the Graphs tab draws estimates against the effort actually recorded, and the point of that chart is to make estimating better, not to catch anybody out.

The clock#

Activity is not a status. Two people can work on one issue at the same time, a reviewer can read it while it is being written, and nobody takes it away from anybody by pressing a button. What the tracker records is runs: a person, a piece of work, a start and an end.

Figure 14 `My time`: what is running, and the runs waiting for confirmation.#

Work on this on an issue starts a run. It ends whatever you had running – a person has one open run, because one person does one thing at a time – and it fills the handler and the step’s role where the slot is still empty, so taking up an unassigned issue assigns it to you without a second form. Stop ends it. An activity that is not an issue (a meeting, administration, training) is started on My time itself from the project’s activity types.

A run’s kind follows the issue’s state, because the status already says which step the work is at: implementation, control, verification, deployment, release, communication, triage, planning.

Nothing reaches a timesheet until you confirm it. A stopped run waits on My time with what was measured; confirming writes one record per calendar day it touched. Confirmation is the only moment the number can be lowered – “I left it running over lunch” – and it can only be lowered: a figure above what was measured is a claim, not a correction, and is ignored. A single run of more than eight hours is not refused, but it needs an explicit tick saying that it really was one spell of work.

After confirmation the run itself is gone and only the per-day records remain. That is deliberate: start and end times say when somebody sat at their desk, which is a different question from how long the work took, and keeping them would be retention without a purpose.

A record is never edited. A correction is appended, with a reason that is always required, and the sheet then shows the corrected hours beside what was measured.

The Right now box on an issue shows who is working on it at this moment. It is for coordination – so that two people do not start the same thing – and it is the only place in the tracker where one person sees another’s clock running.

Timesheets#

A timesheet — Figure 15 A month: hours per work package per day, what is left of each budget, and the records behind the figures.#

Your Timesheet tab shows one month at a time: hours per work package per day, the month’s total, and how much of each package’s granted budget is left. Below it are the records the figures are made of, each one measured run of one day, with its corrections.

A work package is the contract or grant the hours are charged to. Projects that answer to a funder define them (Managers), and some require one before work starts: then Work on this asks you to classify the issue first. An issue’s package can be chosen later, as long as the work has not been confirmed yet; the record keeps the classification the issue had when the run was confirmed.

Submit this month signs the month off as the person who worked it. A manager then approves it. Changing anything in a month that has been submitted makes the submission stale – the sheet says so – and it has to be submitted again, which is what a signature on a document means.

Export writes the month as a document: the monthly declaration is hours per work package with the two signature blocks and nothing per day or per issue, which is the least that can leave the house and still be signed; the daily grid is for a contract that demands one. Issue numbers go into it only if you tick the box.

Who has looked at the detail of your month is recorded, and you can see that list. A manager who asks for the issue-by-issue detail leaves a trace; approving a month does not need it.

What to do next#

The Priorities tab of the Summary answers one question – what should this person do next – and says why for every line, so that the order is arguable rather than oracular. In order of what outranks what:

A question is waiting for your answer. Somebody is blocked on a minute of your time.
A deadline is pressing. See below.
It blocks other people. The more people, the higher.
The plan is late: the work was wanted by a day that has passed.
Otherwise by severity, priority and age, which is the ordinary order.

The list is per person, and it is a suggestion with its reasoning attached, not an assignment.

Deadlines#

A deadline is MantisBT’s due date, and it means something here. An issue has its own date, if somebody set one, and it inherits from its ancestors: a parent due on the 30th that still needs two days of its own work leaves its children the 28th, because the parent cannot start before its children are done. The earliest of these is the effective deadline, and that is what the planning views, the priority queue and the Due soon box on My View use. The issue page keeps showing the issue’s own date, as MantisBT does.

How far ahead a deadline begins to press is the project’s deadline window, fourteen days by default. Inside the window the pressure rises as the day approaches and as the work left grows; past the deadline it is at its highest. An issue nobody has estimated gets the proximity but no promise either way, and the reason says so (“due in 3 days, nobody has estimated it”).

The Gantt chart marks each deadlined issue in its own band, and a bar that crosses its mark is work the plan does not finish in time.

Fast-track#

The full process asks an issue to walk twelve states with four pairs of hands on it. That is right for a change an auditor will read about and overkill for a typo in a label. Fast-track is a tick on such an issue: the implementer verifies and closes it themselves, and the control, the release and the deployment steps are not visited.

The rules:

The project must allow it (“Allow fast-track” on the project page).
The issue’s severity must be trivial or text. A feature request is deliberately excluded.
Lowering an existing issue’s severity to trivial or text, in a compliance project, is the management’s decision and nobody else’s – otherwise the person who must not skip the control could arrange to.
Raising the severity later clears the tick in the same breath, and both changes are in the history.
The two authority gates still apply: an issue whose required notification has not been given cannot be closed, fast-tracked or not.

Everything else is unchanged: the issue is reported, planned, acknowledged, confirmed, assigned and implemented exactly like any other. Only the end is short. The issue page says so in the compliance band, so that a reader of a closed fast-tracked issue sees why it has no reviewer instead of wondering.

Questions#

In a compliance project, a note can be put to one person as a question: the Put this to select under the note form. The issue does not move – it stays exactly where it was, with whoever had it – and the question appears on that person’s My View and at the top of their priority queue. They answer, or you withdraw it.

Use it instead of the feedback status when the issue should not be parked while one person is asked one thing.

Relationships, duplicates and trees#

The relationships of an issue are on the issue page: related to, duplicate of, has duplicate, parent of, child of.

Mark the later report a duplicate of the earlier one, not the other way round, and say in a note what the newer one added.
parent of is the planning relation: the parent is not finished planning while a child is unplanned, and the parent’s deadline constrains the children.
A tree can be made in one go by an agent (see below) or by hand with Add child issue.

Closing#

Resolve with the resolution that is true: fixed, duplicate, won't fix, no change required, unable to reproduce. In a compliance project an issue that ends without a change needs a resolution other than “open” and a reason – the process does not let work disappear unexplained.

Roadmap and Change Log are built from the target version and the fixed-in version of issues, so setting those two fields is what makes those two pages tell the truth.

Figure 17 The roadmap: what each release still needs, from the issues’ own target versions.#

Work that comes back, and meetings#

Some of the issues you will be assigned were not filed by a person: a periodic task files them on a schedule – the backup check every week, the year-end closing every year – with their children, roles, estimate and deadline already set. They are ordinary issues; the only difference is the row on the issue naming the task they came from.

Meetings carry an agenda made of issues. Discuss at a meeting on an issue proposes it for one; whoever runs the meeting accepts it, rejects it or defers it to the next. What is decided is written in the minutes, and an entry can be written onto the issue itself, where it stays with the work. Both are a manager’s instruments, and Managers describes them from that side.

Agents#

A language model can read this tracker as data and file into it, under the same visibility rules as everybody else: every GET page that shows data also answers JSON, and /llms.txt tells an agent what it may do. Writing needs an account, and an agent’s account is marked as one – its name begins with bot-, its contact address is the human who runs it, and that human had to confirm it.

What this means for you, reading an issue: an agent’s name is marked as an agent wherever it appears, so you can see at a glance that the reporter is a model and whose it is. An agent never deletes anything and never rewrites somebody else’s words. If one is filing nonsense, the human behind it can switch it off from the mail they were sent, and an administrator can disable the account like any other.

Integrators has the endpoints, the discovery documents and the rules in full.

Conventions worth keeping#

Put the issue number in the commit message. #123 in the tracker links to the issue; a bare number in a commit message is what lets somebody reading history find the discussion.
One issue, one piece of work. If a review turns up something else, file it rather than widening the issue in front of you.
Set the target version when you plan and the fixed-in version when you land: the roadmap and the change log are built from nothing else.
Say in a note what you decided and why, especially when you decide not to do something. The tracker is the only place that will still have the reason in two years.

Developers

Contents