A developer shop and its clients

Developers and clients think differently. A developer wants the issue in the repository with the branch and the pull request. A client wants to say "the header is wrong on my phone" and know it was heard. This path gives each side its own room and keeps the task the same task.

1. A project per client, with the client in it

The client gets a project and a guest seat: they see only their own work, read everything in it, and write notes. Your developers are members and see every project. Nobody else's client is visible to anyone who should not see them.

Do this: make the client's project and invite the client as a guest. The guide: People, roles, and who sees what.

2. Connect the project to its repository

On the project's Integrations page, connect a GitHub, GitLab or Gitea repository with a token (one per project). Nothing crosses on its own — "send the invoice" has no business in a repository — so the connection asks one question per direction: which tag sends a task there (dev, and Send to GitHub — or GitLab, or Gitea — on a task puts it on), and which label a developer puts on an issue to bring it here (client).

Do this: connect one project to one repository and keep the tag and the label as they come. The guides: GitHub, GitLab, Gitea.

3. The client writes a task; the developer gets an issue

Press Send to Gitea (or GitHub, or GitLab) on a task and an issue opens in the repository, titled with the task's reference and title, with the description and a link back. Your developers work the issue where they already work. Title, description, status and assignee keep each other in step: done closes the issue, closing the issue marks the task done; in progress and blocked are labels on it.

Do this: send one real task and watch the issue appear. The guides: GitHub, GitLab, Gitea.

4. The client's notes reach the developer

A note the client writes on the task becomes a comment on the issue, with their name on it, so the developer reads what the client actually said. The other way is the developer's choice: their comments stay in the repository, and one that starts with /share becomes a note on the task — a thumbs-up on their comment says it crossed. Nobody has to remember that: every issue sjTasks opens ends with the line explaining it. The client never reads a stack trace.

Do this: write a note on the sent task and read it on the issue. The guide: Notes on tasks.

5. The project's news in Slack, if your team lives there

If your developers already spend the day in Slack, a project's news can post into a channel through a webhook the admin makes in Slack (how); the checkboxes on the Integrations page choose what the channel hears. It runs one way: a reply in the channel stays in Slack. Your client is not in your Slack, so the decisions still go on the task, where the client reads them and the developer finds them next month.

Do this: if the team wants it, connect the project's channel and send a test message. The guide: Slack.