Choosing a Repo-Channel Setup

Pullflow helps dev teams collaborate on code reviews more efficiently by combining GitHub and Slack into a unified workflow. You can add the Pullflow bot to any public or private Slack channel to start syncing pull request activity from one or more repositories. This article presents some options and considerations to help you decide which setup or workflow works best for your team.

Note: You can change the repository mapping at any time by entering the /pullflow config command in the Slack channel.

For illustration, we will use a hypothetical project called Tin Hat with three teams, each having their own repository: ios-app, android-app, and chat-service.

Attach the repo to a dedicated channel for pull requests (PRs) per team. For instance, the GitHub repo `ios-app` would be attached to a newly created `#ios-app-prs` channel.

👍🏼 Pros:

• One-to-one repo and channel mapping makes it easier for developers to join/leave and set notifications based on their role and interest.
• Since each PR is a thread, the channel serves as a useful at-a-glance view of the project's status.
• A dedicated channel where each thread is started by the Pullflow bot makes the channel focused on PRs, free of other conversations.

👎🏼 Cons:

• Some projects may have many repos (e.g. micro-services architecture). This can lead to having too many code review channels with sparse activity.
• Some teams may prefer more active collaboration across repos and teams - e.g. frontend and backend may want to share a channel to encourage visibility.

Attach the repo to an existing (or new) development channel for the team, e.g. `ios-dev`. This will serve as the main channel for the team for conversations about software development - e.g. project status, daily stand-ups, technical discussions, questions and answers, etc. Pullflow will be a participant of the channel, creating collaboration threads for each pull request.

👍🏼 Pros:

• A single place for all code-related conversations, including code reviews. No jumping between channels.
• Code reviews become part of the conversation, spawning off other tasks and threads in the channel.

👎🏼 Cons:

• Mixing bot generated threads with human conversations will make it harder to see all the PR to-dos at a glance.
• Team members can't use channel-level notification control. E.g. some may want notifications for all human-initiated messages but not PRs.

Attach all project repos to one project-wide code review channel, e.g. #tinhat-code-reviews. This option centralizes all code review activity across the project into a single channel. However, we do not recommend attaching non-project or unrelated repos to the same channel because doing so can generate noise for team members who don't participate on all repos.

Use the `@pullflow config` message to add or remove multiple repos to a channel.

👍🏼 Pros:

• One channel for all code reviews promotes project-wide knowledge-sharing and transparency. 
• Everyone knows how the project is changing, sparking spontaneous collaboration and minimizing redundant work.

👎🏼 Cons:

• The all-in-one channel can get really busy. Team members may get overwhelmed and start to ignore the channel.
• For team members only interested in some of the repos, it may be harder to stay up to date or set custom notifications.

💡 Not sure which option will work best for you? We recommend start with Option 1 and explore other configurations as your team gets accustomed to the workflow.