Get in touch

Before you start

You'll need a free GitHub account

GitHub is the website that hosts Anchor's code and its public to-do list. To post anything there you need an account, which is free — there's nothing to buy and no Anchor-specific sign-up. If you don't have one yet, create it at github.com/signup; it takes a minute. You can use a personal or a school email address, whichever you prefer.

How to open an issue

Start a new issue

An "issue" is just GitHub's word for a note to the team — a bug you hit, or a change you'd like. To begin, go to the new issue page and sign in if you're prompted. You'll be shown a short menu of templates; pick the one that best matches what you want to say, fill in the boxes it gives you, and press Submit new issue. That's the whole process — the template makes sure you don't forget anything important.

Which template should I choose?

The picker offers a few options. You don't have to get this exactly right — the team will reclassify it if needed — but choosing well helps your report land in the right place faster:

• Bug report — something isn't working the way it should. The agent crashes, a block page won't go away, a session won't start, the dashboard shows the wrong thing. If it's broken, this is the one.
• Feature — a capability that doesn't exist yet and you'd like added. Support for a platform Anchor doesn't cover, a new kind of report, an integration that isn't there today.
• Enhancement — something already works, but could work better. A clearer message, a smoother step, a small improvement to an existing screen or behaviour. The difference from a feature is that the thing exists; you're refining it, not inventing it.
• Documentation — the software is fine, but the writing about it is missing, wrong, or confusing. A page that doesn't explain something, an instruction that's out of date, a gap on this very website.

Writing a report we can act on

"It crashes" isn't enough — here's what helps

A good report is one someone else can follow. "It crashes" tells us something is wrong but not where to look; a minute spent describing what happened saves a long back-and-forth and gets your problem fixed sooner. For a bug, the template asks for these pieces — they're the same ones any developer would need:

• What you did — the steps to reproduce it, in order: what you clicked, opened, or started. If we can follow the same steps and see the same thing, it's as good as fixed.
• What you expected — what you thought would happen instead.
• What actually happened — the real result, including any error message word for word (a screenshot is perfect).
• Your environment — which Windows version, which Anchor agent or extension build, and anything else that might matter. The same bug can behave differently on different setups, so this narrows it down quickly.

The other templates are shorter, but the spirit is the same: say what you want, why it matters, and how we'd know it was done. The more concrete you are, the easier you make it for someone to help.

A couple of things first

Before you open one

If your question is about how your school handles Anchor — what data is kept, who can see a session, how to get something deleted — the answer lives with your school or its IT administrator, who runs the backend; Plink Labs operates none and holds no student data. And it's worth a quick look at the FAQ first, since the most common questions are answered there. For anything else about Anchor itself, an issue is the way to reach us.