Channel Configuration Options
Option 1: Dedicated Code-Review Channel Per Repo
Attach each GitHub repo to a dedicated channel for pull requests (PRs) per team.
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.
- 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 agent makes the channel focused on PRs, free of other conversations.
Cons:
- Some projects may have many repos, leading to too many code review channels with sparse activity.
- Some teams may prefer more active collaboration across repos and teams.
Option 2: General Development-Channel Per Team
Attach the repo to an existing (or new) development channel for the team.
Pros:
- A single place for all code-related conversations, including code reviews.
- Code reviews become part of the conversation, spawning off other tasks and threads in the channel.
Cons:
- Mixing agent-generated threads with human conversations can make it harder to see all the PR to-dos at a glance.
- Team members can’t use channel-level notification control.
Option 3: One Channel for Project-Wide Code Reviews
Attach all project repos to one project-wide code review channel.
Pros:
- 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, and team members may 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.
Recommendation: If you’re unsure which option will work best for you, start with Option 1 and explore other configurations as your team gets accustomed to the workflow.
You can connect one repository to multiple channels based on the paths of the files changed in the PR, for example in the case of monorepos. Learn how to set it up here.