Administration
The operator area is at /admin.
Nothing on the public side links to it beyond one footer link, so it is not somewhere a visitor wanders into.
Projects
Section titled “Projects”One instance hosts as many projects as you have products.
Each gets a board at /p/<slug>, and the slug is what your users’ URLs carry.
A slug can change. When it does, the old one answers with a permanent redirect to the new one, so links people have already shared keep working. Your own tooling should hold the project’s id rather than its slug, which is why the admin API addresses projects by id and the public API by slug.
Designing a status flow
Section titled “Designing a status flow”Columns are per project, and you choose them.
Fewer columns read faster. A visitor should understand the shape of your roadmap in about three seconds, and six columns is already at the edge of that. The default flow — proposed, under review, planned, in progress, shipped, declined — is a reasonable starting point precisely because it is the shortest one that still distinguishes “we have not decided” from “we decided no”.
Two of those are terminal, and the board collapses them behind a “show finished and declined” toggle. That is worth keeping: a board whose first screenful is things you already shipped buries the things you have not.
Choosing how your users identify themselves
Section titled “Choosing how your users identify themselves”This is the decision with the most consequences, and it is per project.
| Mode | Friction | What you get |
|---|---|---|
anonymous |
none | A signed cookie plus a hashed address. Weak deduplication, no notifications. |
magic_link |
one email click | A durable identity. Real vote deduplication, and you can tell people what happened to their suggestion. |
oidc |
a provider login | The strongest, and the obvious choice when the app already has an identity provider. |
Pick anonymous when you want the widest possible participation and you can live with the vote counts being directional rather than exact. Nobody is turned away, and nobody hears back.
Pick magic_link when the votes are going to inform a decision, or when you want people to learn that the thing they asked for shipped. It costs one click, and that click is what makes a vote count mean one person.
Pick oidc when your users already sign in to your product. There is no new account and no new password, and the identity is as good as the one your app already trusts.
An anonymous identity upgrades in place. Somebody who votes and comments anonymously and later verifies keeps everything they did: the votes and comments carry across rather than being orphaned. So starting anonymous and tightening later does not throw away the participation you already have.
Note that magic_link needs working SMTP. Without it the link is written to the log, where your users cannot read it. See Self-hosting.
Offering a sign-in without requiring one
Section titled “Offering a sign-in without requiring one”A board in anonymous mode that has an OIDC provider configured offers it rather than requiring it.
A visitor is asked once, before their first vote or comment: sign in, or carry on as a guest.
Choosing guest creates a local account for that board under a generated name, which they can rename or delete from Your activity.
Without a provider configured there is nothing to offer, so the board says the same thing in a line under the comment box instead of in a dialog.
Requiring an account to comment
Section titled “Requiring an account to comment”Require an account to comment asks for a signed-in visitor before a comment while leaving voting anonymous. It is the middle ground between a board anybody can talk on and one nobody can take part in without signing in: a vote is a number and a comment is a voice.
It needs a way to sign in, so connect a provider first. Serelane refuses the setting on a board that offers neither, because it would otherwise close commenting to everybody with no route back in.
Moderation
Section titled “Moderation”Two queues, both under the project’s Moderation tab.
Comments can be reported by readers. A reported comment stays visible until you act on it, because hiding on report alone hands a heckler’s veto to whoever clicks first.
Suggestions never appear on the board until you accept one. That queue is the one to keep short: somebody who suggests something and hears nothing for a month learns not to suggest anything again.
When two people ask for the same thing, merge rather than decline. Merging moves the votes onto the entry that stays, so the count reflects everybody who asked. Declining a duplicate throws that signal away and reads, to the person who wrote it, as a no.
Serelane also holds repeated content for review rather than refusing it. Two people hitting the same bug write remarkably similar sentences, and the second of them is not spam.
Members
Section titled “Members”Roles are per project, so somebody can run one board without touching another.
Instance settings, and the accounts that can reach them, live under Instance settings and are separate from any single project.