Skip to content
Pullflow

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.