Support Commitments
What Fiavaion commits to for AssisT — support channels, acknowledgement times, release cadence, and what is deliberately not promised.
Applies to AssisT 1.0.0 · Last updated 13 September 2026
AssisT is free software maintained by a solo developer and funded by voluntary community contributions. This page says plainly what that does and does not buy you, so that a learning support service can plan around it rather than discover it.
Channels
| What you need | Where to send it | What happens |
|---|---|---|
| Accessibility problem — a barrier in AssisT itself, or an assistive technology that does not work with it | [email protected] | Acknowledged within 5 working days. The acknowledgement says what we think the problem is and whether we can reproduce it |
| Bug report | Report a bug or GitHub issues | Triaged on a best-effort basis. Public, so you can see the queue and the history |
| Feature request | GitHub issues | Read, labelled, and considered against the roadmap. Supporters also vote on priorities |
| Institutional enquiry — adoption pack, institution branding key, a written statement for procurement | [email protected] | Answered as a priority, because these usually block a decision affecting many students |
| General question | [email protected] | Best effort |
| Security issue | See SECURITY.md in the repository | Handled under the repository’s disclosure policy |
The one firm commitment
Accessibility reports sent to [email protected] are acknowledged within 5 working days.
That is an acknowledgement, not a fix. It means a human has read the report, tried to reproduce it, and written back to tell you what they found. Reports from disability services, and from students using assistive technology, are handled ahead of everything else in the queue.
What is not promised
Being straight about this is more useful than an aspirational SLA nobody can hold us to.
- No service level agreement. There is no guaranteed response time outside the accessibility commitment above, no guaranteed fix time for anything, and no uptime guarantee (AssisT runs in your browser; there is no service to be up or down).
- No paid support tier. There is no tier to buy. Everyone gets the same channels. Supporting the project financially does not buy priority support — it buys a vote on the roadmap.
- No dedicated account contact, no phone line, no ticketing portal. Email and GitHub issues.
- No guaranteed release schedule. Releases ship when they are ready.
- No warranty. The EUPL-1.2 disclaims warranty and liability; see the terms.
- No commitment to build a requested feature, however reasonable the request.
How updates reach your students
Through the Chrome Web Store, like any other extension. Chrome checks for updates on its own schedule and installs them silently in the background. There is no installer to repackage, nothing for your IT team to push, and no action required from the student.
If you force-install AssisT by policy, updates still arrive this way — see the managed deployment
guide. If you pin a version with Chrome’s ExtensionSettings
policy, you take on the job of applying accessibility and security fixes yourself.
Release cadence: there is no fixed cadence. Accessibility and security fixes are prioritised and
shipped as soon as they are ready; feature releases arrive when they arrive. Every release is
recorded in the changelog and in the repository’s CHANGELOG.md.
What happens if the project stops
A fair question for anyone recommending a tool to students who will depend on it.
AssisT is released under the EUPL-1.2 and the source is public. If development stopped tomorrow, your institution — or anyone else — could fork it, maintain it, and redistribute the result under the same licence, with no permission needed from us. Settings and student-created content live on the student’s own device, not on a server that could be switched off. An abandoned AssisT keeps working; it does not evaporate.