Learn A development shop with clients

A developer shop and its clients

Your developers work in Gitea and Slack. Your clients work here. The same task, typed once.

  1. 1. A project per client, with the client in it
  2. 2. Connect the project to its repository
  3. 3. The client writes a task; the developer gets an issue
  4. 4. The client's notes reach the developer
  5. 5. The team's news in Slack, and tasks from it

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 Gitea repository with a token, and choose which tasks cross: every task in the project, or only the ones carrying a label such as dev. Most shops choose the label, because "send the invoice" has no business in a repository.

Do this: connect one project to one repository and pick the label. The guide: Gitea.

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

A qualifying task opens an issue 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. Status flows out: done closes the issue; in progress and blocked are labels on it.

Do this: put the label on one real task and watch the issue appear. The guide: 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. Nothing goes the other way yet: the developer's comments stay in the repository, and the client never reads a stack trace.

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

5. The team's news in Slack, and tasks from it

The same Integrations page connects the project to a Slack channel: the project's news arrives there, and /sjtasks Fix the nav @jane !high friday in that channel makes a task the way it would anywhere else. A mention of the app does the same.

Do this: connect the channel and make one task from Slack. The guide: Slack.

Try the path on a team of your own: start for free, no card needed.