Boards & views
A board holds your work and defines the workflow it moves through. How you look at that work is a separate choice — the same board renders as a kanban, a list, a spreadsheet or a calendar, and you can save the arrangements you keep coming back to.
Workspaces & boards#
Kevta nests in two levels. A workspace is the team container: it owns the member list and the boards. A board is a single stream of work with its own workflow, properties, labels and issues.
Boards live inside a workspace and are created from the workspace page — only by the workspace owner. Everyone in the workspace can see its boards; finer-grained access is set per board, covered under board settings.
The board header carries the essentials: a star to pin the board, member avatars, Search issues (which matches both titles and task keys), the New issue button, and a menu with Switch board, Archived todos, Board settings and Back to workspace.
The status workflow#
A board's workflow is its Status property, and new boards ship with five stages: To Do, In Progress, In Review, Ready for QA and Done.
These are not fixed. In Settings → Columns & fields an admin can add stages, rename them, recolour them and drag them into a different order — and that order is what determines the order of columns on the board. See tasks & fields for the full picture of properties, including the naming rule that decides which stage counts as finished.
Four view types#
The switcher at the left of the toolbar changes how the same, filtered set of issues is drawn. Keyboard shortcuts 1–4 select them in order.
BoardKanban columns, one per value of whatever you group by. Drag a card between columns to change that value. Each column has a + to add an issue straight into it.ListSingle-line rows under collapsible group headings — the densest way to read a lot of issues.TableA spreadsheet with a column per property. Cells edit in place, so this is the fastest way to fill in missing values across many issues.CalendarA month grid placing issues on their date, with Today and month arrows.Grouping#
The Group control decides how issues are bucketed. You can group by None, Status, Assignee, Priority, Due date, or any other property the board defines. Issues with nothing in that field collect into a trailing “No …” group, so work never goes missing.
Calendar behaves differently: instead of grouping it offers Colour by — Status, Priority or Assignee. So the calendar cannot be grouped, and the other three views cannot be colour-coded.
Filtering#
Filter narrows what every view shows, by Status, Priority, Assignee, Label, and any other property that has values to filter on. Active filters appear as chips below the toolbar, each removable, alongside Clear all.
How multiple selections combine is worth knowing:
- Within most fields, any match wins. Selecting two statuses shows issues in either.
- Labels must all match. Selecting two labels shows only issues carrying both.
Sorting#
Sort is multi-level: each field you add breaks ties in the one above it, and the panel spells out that relationship on every row — “sorted first”, “breaks ties in Priority”. Drag the handles to change which field wins.
Any property can be sorted on, plus three extras: Created, Last updated and Manual order.
Saved views#
A saved view captures the whole arrangement — view type, grouping, colour-by, filters and sort — under a name, as a tab above the toolbar. Every board starts with one called All issues.
Adjust anything and the tab shows a dot to say it has drifted from what was saved. You then get Save view to keep the change or Reset to snap back. Tweaks you never save are temporary, so exploring is free.
+ New view saves the current arrangement under a new name. Each tab's menu offers Rename, Duplicate, Move left, Move right and Delete view. Views are shared with everyone on the board, and a board always keeps at least one.
Task keys & branches#
Every issue gets a short key built from the board key — MS-42. Keys are permanent once stamped, which is what makes them safe to quote in commits and pull requests.
Board settings control the scheme, under GitHub → Branch Names: switch key generation on or off, number issues sequentially or with a short random code, set the default branch type used by Copy branch name, and preview the result.
The board key itself can be changed there via Change board key, confirming with the board's name. Existing issues keep the keys they already have — only new issues use the new prefix — so branches and links you have already pushed keep working.
Board settings#
Board settings is organised into seven sections:
GeneralName, key, description, colour — and deleting the board.Columns & fieldsThe board's properties, listed as Built-in or Custom, plus their select options.LabelsThe board's label set, with colours.AutomationsRules that run when GitHub activity changes an issue on this board.GitHubConnect the board to a repository, and configure task keys and branch names.API tokensTokens limited to this board — see API tokens.MembersWho has access to this board, and at what level.Board membership is where real roles live. Five exist, in increasing order of power:
ViewerRead-only access to the board.CommenterComment on issues, but not edit them.EditorCreate and edit issues.AdminManage board settings, fields and members.OwnerThe board's creator and the workspace owner. Can also delete the board.