Workspaces and the web app

Everything on neosource belongs to a workspace. Every account has exactly one personal workspace, named by its handle. An organization is a shared workspace with members, roles and teams. Repositories, teams, packages, runners and workspace access tokens all belong to one workspace, and its name is the first segment of their URLs: /acme/api, /acme/teams.

Switching workspace

The web app always works in one workspace at a time. The switcher at the top of the left rail lists your personal workspace, then every organization you belong to. Picking one takes you to its home. The rail’s teams, the New menu and the command palette then act in that workspace. You can also switch from the command palette, or by opening a URL that names another workspace you are a member of.

The URL names the workspace, so two tabs can be in two different workspaces at once. The app remembers the organization you last switched to. When you open / with an organization remembered, you land on that organization’s home.

The home of each workspace

Workspace	Home URL	What members see
Personal	`/`	your personal dashboard
Organization	`/<org>`	the organization page with work band

The logo and the rail’s Home both go to the home of the workspace you are in. Going home never switches workspace.

Your personal home (/) shows:

Needs attention: review requests, your open PRs, and issues assigned to you, in that order, limited to this workspace.
Repositories in your personal workspace, and Shared with you when other people have given you access to theirs.
Agent sessions and Recent activity. Recent activity links to the workspace’s scoped inbox.
A Getting started checklist, while it has unfinished items and until you dismiss it.

An organization’s home (/<org>) is the organization’s page. For a member, a work band sits above the repository list. It holds the same Needs attention and Recent activity sections, limited to that organization. Below it are the Repositories and Packages tabs, and the Teams, Usage and New repository links. Anyone who is not a member, signed out included, sees the organization’s public profile instead, with no work band.

Neither home mixes in another workspace’s work. For everything everywhere, use the account-wide pages in the rail.

From top to bottom:

Workspace switcher, with Settings (your account settings at /settings) and Sign out. Beside it are Search (the command palette, Ctrl K or ⌘K) and Compose, the New menu: New repository, New ticket, New team and New organization.
Home, Inbox (with its unread count), then four rows that are the same in every workspace: My issues (assigned to you everywhere), Reviews (pull requests waiting on you everywhere), Starred (/stars), and Explore (/explore, where trending repositories live).
Favorites: repositories, teams and issues you have bookmarked. The section is collapsible and hidden while you have none.
Your teams in the current workspace, once it has one. Each team row expands to its Triage, Tickets and Cycles (current and upcoming). See Planning.
For an organization, Settings if you are an Admin or Owner, or Runners if you are a Member.
Help, which opens these docs.

On a desktop screen, signed in, there is no global header: the rail carries search, compose and the inbox, and a repository page shows only its own header row. Phones and signed-out visitors keep the header with search, the Inbox and the New menu.

Explore and Starred

Explore (/explore) lists public repositories. It sorts by Updated (most recently updated first, the default) or Trending (most stars gained in the last seven days), and has a filter box.

Above the list, Explore opens with a Mirror archive section: up to six repositories from the _mirror workspace (popular open-source GitHub projects mirrored to neosource and built on neosource CI), each with its upstream, last sync and latest CI status. All mirrors → opens /_mirror. The section is hidden while you filter.

Starred (/stars) lists the repositories you have starred, most recent first. Stars are yours, not a workspace’s, so the list is the same whichever workspace you are in. A personal profile also has a Stars tab at /<handle>/-/stars.

Creating an organization

Choose New organization from the New menu or the switcher’s Organizations row, or open /new/organization. Give it a handle, and optionally a display name and description. You become its Owner.

The handle is the URL slug and cannot be renamed later. Names that exist on GitHub are reserved for their owners. If the handle you want belongs to a GitHub organization you administer, the page offers to connect it: install the neosource App on the organization on GitHub as one of its owners, and the handle is yours here too. neo org claim starts the same flow from a terminal.

Members, roles and teams

An organization has three roles:

Role	Can
Member	work in the organization’s repositories and teams; see Runners, Usage
Admin	also manage settings, members and workspace access tokens
Owner	also archive the organization

Admins and Owners manage people under Settings → Members:

Invite by email: one address or a pasted list (up to 50 at a time), with a role. Addresses follow the same rules as on an account (ASCII, full domain); a bad entry is reported as invalid and the rest still go out. Pending invites can be resent or revoked.
Add an existing account by handle, with a role.
Change a member’s role, or remove them. You can grant only a role at or below your own, and the last Owner cannot be removed.

A membership granted through an email invite is email-bound: it ends if the account stops holding that address verified. One added by handle is direct. An invite can be accepted under any address your account holds verified, not only the primary, either from the mailed link or from Invitations at the top of your home, personal or organization (see Email addresses).

Teams group people and work inside a workspace. Create one with New team, or from the organization’s Teams page (/<org>/teams). A personal workspace can have teams too. What a team owns is described in Planning.

The rest of an organization’s settings are General (avatar, display name, description), Access tokens (see Authentication and tokens), Runners, Usage and Danger zone.

Repository pages

A repository’s tabs, at /<owner>/<repo>:

Tab	What is there
Code	files and folders at any branch; the README
Issues	the repository’s issues
Pull requests	open and closed pull requests; see Pull requests
Commits	history of a branch, and of a single file
Tags	the repository’s tags
Actions	workflow runs, workflows, caches and usage
Packages	shown only when packages are linked to the repository
Settings	shown only when you can open at least one settings page

A pull request has Conversation, Files changed and Checks views. How review works across force-pushes is covered in Code review, and the Actions tab in How CI works. To bring back a branch that was deleted, see Recovering branches.

Repository settings are General, Mirrors, Webhooks, GitHub, Labels, Access, Branches, Pages, Secrets, Quarantine and Danger zone. Labels and Quarantine are open to anyone with write access. The other pages need admin access to the repository.

Archiving and deleting

A repository is deleted under Settings → Danger zone by typing its name. Its code, pull requests, issues and history go. Forks are kept and decoupled. This cannot be undone.
An organization can be archived by an Owner under Settings → Danger zone, by typing its handle. Archiving hides the organization and all its repositories, teams and members, and it stops resolving for everyone. Contact support to restore it.
An account or personal workspace cannot be deleted from the web app or the API yet.