Conflicts in team work #32
|
In my team we have decided to commit the .lattice so every team member will have all the context of the whole features. |
Replies: 4 comments 4 replies
|
@ShuratCode : First of all, thanks a lot for trying Lattice and embedding it into your team's workflow. I'd genuinely love to hear your feedback on how it works in practice and whether it helps the team. Real-world usage and feedback are incredibly valuable in shaping the framework. Regarding conflicts in the .lattice folder, I think there are two different categories of content. The first category is repository-level knowledge such as knowledge priming, architectural standards, engineering practices, and other shared guidance. These tend to be relatively stable and are not modified frequently by everyone on the team. The second category is feature-level artifacts, which is where parallel development happens and where most conflicts are likely to occur. My recommendation is to treat a feature as the primary unit of ownership in Lattice. Traditionally, we break work down into epics, features, and stories. With the speed AI enables, many teams may find that working at the feature level is sufficient, though going down to stories is still perfectly valid if needed. The key idea is that a feature should ideally have a single Design Blueprint that captures the intent, architecture, and implementation direction for that feature. Having multiple developers editing the same blueprint simultaneously will naturally create conflicts. Instead, assigning ownership of a feature (and its corresponding blueprint) to a single developer or a small coordinated group can significantly reduce merge issues. In practice, I've found that once a feature blueprint is created, implementation moves quite quickly with AI assistance, which reduces the duration for which these artifacts remain in conflict. For reference, here's how I managed the .lattice folder in one of my open-source projects while using Lattice to evolve the codebase: [ConfIT .lattice Structure] (https://github.com/techygarg/ConfIT/tree/master/.lattice?utm_source=chatgpt.com) This is still an area where I'd love to learn from the community. If your team discovers effective collaboration patterns for multi-developer workflows, please share them back. I suspect we'll collectively develop better practices as adoption grows. |
|
@techygarg Thanks for the response. In general, we are combining lattice and gstack as a single framework. Our current development pipeline is: Our conflicts now are mostly on the index.html file - because any new feature is a design blueprint, and because of that the index.html is updated in parallel in each developer feature branch. |
|
@ShuratCode That is a valid concern. Let me think about this and I will get back. |
|
@techygarg another issue we encounter after few weeks of working with lattice is bloating of the index.md and operational-learnings.md files Is there recommendations on how to compress those? |
|
@ShuratCode : I have a few thoughts in mind. Would it be possible jump over a call and discuss it briefly? |
|
@ShuratCode : You can run |
|
This PR (#34 ) addressed your concerns. |
|
Thanks for the efforts!! |
@ShuratCode
This PR (#34 ) addressed your concerns.
I will release a new version of plug in.
We can run /lattice-init and it will migrate existing requirement folder to new structure and will remove conflict for future editions.