Team workflows when developing

Rasa Open Source
1

I’m hoping to find some guidance on how do teams of developers collaborate on a rasa project, something like Introducing GitFlow. I have seen the project management template (Project Management for Conversational AI Teams [+Template] | The Rasa Blog | Rasa) but am hoping to get more detail in the day to day.

  1. How do you split up development tasks, should it be split by features or files (i assume we can’t split files since each new feature in rasa requires editting multiple files).
  2. What are the scenarios specific to rasa development where merge conflict would occur, and how does the team minimize that?
  3. Which are the tasks that can be split between various roles, which roles are sharing tasks? (Examples of roles are Product Manager, Conversation Designer, from Recipes for Building Conversational AI Teams | The Rasa Blog | Rasa)
  4. Is it viable to keep a main1 branch as small as possible, so new collaborators can clone the minimum required skeleton, and only implement the feature they care about, and testing that, before merging into another main2 branch that contains all updated features ready for testing again that it still works when mixed with other stories/features. I assume this can speed up development because we minimize training time when the training files in the skeleton are small, and also assume that story flows/features that work before merging will still work after merging. Not sure if my assumptions hold true, can anyone experienced comment?

Any other collaboration tips are welcome too.

2

We split tasks by features, treating each as a “mini-project” with a checklist of impacted files (stories, domain, NLU, etc.). To avoid merge conflicts, we used GitFlow with feature branches and kept the main branch small and stable. Daily check-ins helped us stay aligned.

Your idea of a minimal skeleton branch is great! We used a similar setup, which sped up training and made onboarding easier. Conversation designers focused on flows, while developers handled training data and integrations—clear handoffs made a big difference.

I’d also recommend documenting everything, a tip I picked up from mantralis.co.uk. Clear documentation saved us countless headaches!

3

From my experience, splitting development tasks in Rasa can be a bit tricky, but we usually focus on separating them by feature sets rather than specific files—especially since Rasa often requires changes across multiple files for a single feature. For merge conflicts, one thing we do is always try to stay on top of communication. If two team members are working on similar features, we set up brief syncs to avoid overlapping changes. As for the main branch setup, keeping it small is a great idea. It’s kind of like PMI Scheduling Professional (PMI-SP) strategies I’ve seen in project management—minimizing risk by working with smaller, manageable tasks and testing frequently. It can definitely help with streamlining and speeding up development.