How projects and tasks work

Projects & Tasks is a to-do tracker that lives in your server. A project is a piece of work your team is doing — the website, the modding queue, the next event — and an issue is one thing to do inside it. Issues sit in columns on a board, move to the right as the work advances, and can be assigned to somebody, given a priority, a due date and a label or two.

If you have used Linear, Jira or GitHub issues, this is the same shape, made smaller and moved into Discord. If you have not: picture a wall of sticky notes. Each note is one thing to do. The wall is split into columns — not started, being worked on, done — and a note moves from one column to the next as somebody does the work. That is the whole idea; everything below is detail.

Projects & Tasks is being rolled out gradually. If Projects & Tasks is not in your dashboard's Management section, and /task answers that it is not available, the module is not enabled for your server yet.

The objects

Projects, states, labels and cycles are the furniture: you set them up once and rarely touch them again. Issues are the work, and doc pages are the writing around it. Customers are who asked for the work, and requests are what they asked for.

Identifiers

Every project has a key: two to eight characters, upper case, starting with a letter — WEB, MOD, ART2. Every issue in the project gets a number, handed out in order, and the two together are the issue's identifier:

WEB-12
 │   └─ the number, handed out in order inside that project
 └───── the project's key

That is what people say out loud and what they type. /task view reference:WEB-12 opens it, and typing web-12 works just as well — the key is read case-insensitively. A bare 12 is never an identifier: with two projects open it would be ambiguous, so FlaviBot refuses it rather than guessing.

Numbers are handed out per project and are never reused. Delete WEB-12 and the next issue is still WEB-13, so an identifier quoted in an old thread never comes back pointing at different work. Two people creating an issue at the same second get two different numbers.

The issue's identifier follows its project's key, so renaming a key rewrites every identifier the project shows. See projects, states and labels.

The path an issue takes

1. Somebody creates it, from the + on a board column, from C on the keyboard, from New from template on the filter bar, or from /task create in Discord. It needs a title and nothing else: it lands in the project's first column with no assignee and no priority.
2. FlaviBot posts its card in the module's default channel, or in the channel the command ran in. The card shows the identifier and title, the state, the priority, the assignee, the labels, the due date and the cycle, and carries four buttons: change the state, take it (or drop it), comment, and open it on the dashboard.
3. When Create a thread is on, a thread named WEB-12 Title is opened under the card, and every comment written on the dashboard is mirrored into it. That is where the conversation goes, so the channel itself stays a list of cards rather than a chat.
4. People work on it. Each change — state, assignee, priority, title, due date, cycle, labels — is written to the issue's activity trail with who did it and when, repaints the card, and where it matters sends a DM.
5. Moving the issue into a completed or cancelled column closes it and records the moment. It drops out of the default filters, stops counting as open, and counts towards its cycle's progress. Moving it back out reopens it and clears that moment; moving it straight from one closed column to the other, Done to Cancelled, keeps it.

Archiving an issue puts it away without losing anything: it leaves the board, the list and every view, keeps its identifier, its comments and its activity, and comes back whole when you restore it. It is the right answer to an issue that is neither done nor wanted — a duplicate, something dropped, a board that has silted up.

Deleting an issue removes it, its comments, its activity and its card (Discord removes the thread with the card it hangs from). Its sub-issues survive; they simply stop having a parent. There is no undo — closing an issue, and archiving it when it is still in the way, is the normal way to be done with something. See archiving an issue.

States and what they mean

A state has a name you choose and a type you pick from five. The name is what everyone reads; the type is what FlaviBot understands.

Two states can share a type: In Progress and In Review are both started, and a team that also wants a QA column simply adds a third. Completed and cancelled both close an issue; the difference between them is whether the work actually happened, which matters to a report and to nothing else.

Every new project is seeded with the six columns above, so it is usable the second it exists. Renaming, recolouring, reordering, adding and deleting them is in projects, states and labels.

Priorities

Five levels, from none to urgent. The level is drawn as a small meter — a chip on the card, a column on the list, a row on the issue's own page — and it is the meter's shape that carries it, with the word beside it wherever there is room for one. The list can be sorted and filtered by it.

Grouping the board by priority is the one place a level carries a colour of its own: the dot beside a column or swimlane heading. See views and shortcuts.

Sizes, time, teams and GitHub

Four things an issue can carry beyond the properties above, all optional and all off until somebody turns them on:

A server that ignores all four has exactly the tracker described above, which is why none of them is on to begin with.

Where you configure it

Everything is on the dashboard, under Management > Projects & Tasks, on one page with a project switcher in its header:

• The issues, drawn either as a board of columns you drag cards between or as a dense list for reading and sorting — whichever you pick in Display. See the board and the issue.
• Cycles: the dated slices of work and their progress, behind the Cycles button in the header. See cycles.
• Docs: the project's pages, or the server wiki when no project is chosen, behind the Docs button beside it. See doc pages.
• Customers: who asked for the work, and the requests behind each issue, behind the Customers button — on a server that keeps them. See customers and requests.
• Settings: the switches below, the server's labels, the current project's columns, and its issue templates, behind the cog beside it.

Those buttons are toggles — pressing the lit one puts you back on the issues. The issues themselves can be grouped by something other than the state, sliced with filters and saved as a view, and the whole page answers the keyboard — see views and shortcuts.

Who can do what

What a member may do in the tracker is a set of permissions, the same set whether they act from the dashboard, from a card's buttons or from /task — a member is never refused by one and let through by another. There are seventeen, and most come in two sizes: own, for an issue you created or are assigned to, and any, for everybody's.

These are the names the dashboard uses, and the names the bot quotes when it refuses.

Done is a permission of its own. Moving a card between open columns and moving it into a finished one are two different rights, and which one a move needs is decided by the column's type — completed or cancelled — never by its name. A column called Done of type in progress is a move; a column called Parked of type cancelled is a close. Filing an issue straight into a finished column counts as closing it too. That is what lets a server say "my team files and works, I say when it is done" whatever the columns are called.

Presets

Four ready-made sets, each holding everything the one before it does:

A set that is not exactly one of the four is shown as custom; tick whatever combination you like.

The floor, and how roles add up

The floor is what every member of the server can do with no role or member row at all. Its default is exactly what the bot always allowed from Discord: file, comment, claim a free issue, log your own time, and edit, move or close your own issue. The dashboard is not part of it, and cannot be: the floor can never carry View the tracker or Manage settings, so it lets somebody act on the card and in /task, and nothing more. A server that never opens the settings notices no difference.

On top of the floor, a role or member row grants a set of permissions to a Discord role or to a single member. A member's permissions are the union of the floor, every row naming them or one of their roles, and what their standing already implies: Manage Server and Administrator are always the full Admin set, and the server's dashboard allowlist is Manager. A row only ever adds; nothing here takes a right away, and nothing can take the module away from Manage Server — an admin who could lock themself out of a page would have no way back in.

A member whose only standing is one of those rows — no Manage Server, not on the dashboard allowlist — can log into the dashboard and gets the tracker and nothing else: no other page of your server's dashboard opens for them.

It is all set under Management > Projects & Tasks > Settings > Members & roles: the floor is one list of checkboxes, and under it the Roles list, one row per role or member, each with a preset or a custom set. Saving the roles applies at once, on the dashboard and on the next command.

The own rows are the ones worth reading twice. A tracker where only admins can move a card is a tracker nobody updates, and one where anybody can reassign anybody's work is a tracker nobody trusts — so the people who own a piece of work, the person who asked for it and the person doing it, are the ones who can change it by default. Commenting is on the floor by default: answering a question is not a change. A server that unticks Comment from the floor keeps it to the roles and members listed under it.

/task itself carries no Discord permission, because a tracker only works when the person who spots the problem can write it down; what each subcommand then does is decided by the permissions above. If that is not what you want, the command can be restricted or switched off for your server in Configuration > Commands Settings, like any other command — see turning things on and off.

Editing or deleting a comment is the author's own right; Moderate lets a member edit or delete anyone's, and an edited comment says that it was edited. Reacting to one is open to anybody who can comment.

When the bot refuses — a button, a subcommand or a save on the dashboard — the answer is private, names the permission that is missing by the name it has in the table above, and the issue is untouched. Whoever manages the settings can hand it out.

Notifications

FlaviBot sends direct messages, never channel pings. No task notification ever mentions a role or @everyone.

You follow an issue by being involved with it: creating it, being assigned it, or commenting on it. Following is per issue, so a project you set up in January does not fill your inbox in June. Notify the assignee only gates the assignment DM — the other two answer something the member themselves started.

To stop an issue's DMs, press Mute this issue under any DM it sent you, or the bell beside the issue's title on the dashboard. A muted issue sends you nothing — no state changes, no comments, no assignment — and it stays muted when you comment on it or are assigned it again, so being involved later does not quietly switch the DMs back on. Unmute this issue, or the bell again, brings them back. A mute is yours alone: everyone else following the issue is told exactly as before.

Putting an issue on a team notifies nobody either: a team is a label saying whose work this is, not a mailing list, and nothing about it mentions a role. A timer running on an issue is nobody else's business and is never announced.

Nobody is ever told about their own action: assigning an issue to yourself, moving one or commenting on one sends you nothing.

Naming somebody with an @mention in a description or a comment sends them one DM — the issue's title and a link, not the text around their name — and nothing more: it does not assign them anything and does not make them follow the issue. A few rules keep it from turning into a way to message people:

• only members of the server are told, and only the first five people a comment or description names;
• a member who follows the issue already gets the comment itself, so a mention in a comment sends them nothing extra;
• editing a description only notifies the people the edit added;
• a muted issue stays muted, mentions included;
• a mention written inside code, or by an automation, notifies nobody.

A member with DMs closed simply does not get one; nothing else changes, and the issue carries on.

Commands

The full detail, the card's buttons and what each error means are in the Discord side.

Settings

Limits

How many active projects a server may have, and how many issues each project may hold, depend on the plan:

Archiving a project frees its slot while keeping its issues readable and its key taken, so a finished project never has to be deleted to start the next one. A sub-project takes a slot like any other project. The issue cap counts closed issues too — it is how much a project holds, not how much is open — and it is per project so that splitting the same work across two projects does not dodge it. The full table is in limits by tier.

The rest are the same for everybody:

What FlaviBot needs

In the channel where cards are posted: View Channel, Send Messages and Embed Links. Without them the issue is still created — it simply has no card, and the dashboard is the only place it shows. Add Create Public Threads to open the discussion thread, and Send Messages in Threads to mirror comments into it.

Nothing else is needed. Tasks never touch roles, never delete messages and never mention anyone in a channel.

Next: the board and the issue.