I’m Megha, a 2nd year CSE student from IIITDM Jabalpur, currently contributing to MEDIC through C4GT (DMP 2026).
I had a quick question regarding collaboration. If two contributors are interested in the same project or problem statement, is it possible for them to work together officially? Or is it expected that each participant works individually on separate issues?
I just wanted to understand how collaboration is handled in DMP 2026 so I can plan my contributions accordingly.
Would really appreciate any guidance on this. Thanks!
I’m Mohammad Sakib, and I’m currently preparing a proposal for the issue “Add API endpoints for advanced contact management operations.”
While going through the discussion, I came across the comment by @jkuester about the need for more sophisticated batching/queuing logic and the challenges around async execution and offline-first behavior.
Based on that, I had a couple of follow-up questions to better align my proposal with the expected design:
1. REST pattern for async operations:
Would the preferred approach be to model these as explicit operation resources—returning an operationId and exposing a /operations/:id endpoint for status tracking—or is there another pattern you’d recommend for handling long-running batched operations?
2. Offline-first consistency model:
In cases where a server-side move or merge conflicts with offline updates (such as outdated _rev values or reports linked to the old hierarchy), should we treat server-side structural changes as authoritative and reconcile incoming data accordingly, or is there an expectation to preserve client-side updates and potentially reapply or roll back operations?
I want to make sure my approach aligns with the intended architecture, especially around consistency and replication behavior.
Each DMP project will be assigned to one contributor. As you work on separate issues, you are encouraged to support each other through the community platforms like the forum and Github.
I am Keerti Gupta, a student at the Indian Institute of Information Technology Jabalpur. I recently started contributing to the CHT Core repository through the C4GT program and have opened my first PR related to contact sorting.
I am really excited to be part of the Medic/CHT community and to learn more about how the toolkit is used in real-world healthcare solutions. I’m particularly interested in frontend development and improving user experience, but I’m also open to exploring other areas as I continue contributing.
Really looking forward to learning from you all and contributing more going forward!!
That makes sense - I understand that each project is assigned to an individual contributor. I’ll make sure to actively collaborate informally through discussions on GitHub and the forum while working on my own assigned issues.
What you have described matches my current thoughts. However, we not not 100% committed to this if we can find an alternate approach that would be better. (But in general I love the simplicity of just having an operation endpoint.)
Once a merge/move/delete has been triggered on the server-side, we should treat that as authoritative. The main question, though, is how to handle incoming data from the clients after the merge/move/delete has been triggered on the server-side.
Unfortunately, the current approach in the CHT has been to just not handle it. This put the burden on each deployment to require re-syncing after a move.
I think we need to find a better way to handle this when we move this functionality into the CHT, itself.
Ultimately this may require some updates to our replication algorithm (or maybe client-side transitions… ). Either way, the short answer is that I don’t think we have idendified the best approach here yet…
Hi @jkuester, thanks for the clarification , this really helped me understand the problem space better.
I also went through the current cht-conf approach for moving contacts, and I noticed that while it handles hierarchy updates correctly, it relies on a manual workflow and requires users to re-sync when offline data conflicts occur. This makes it harder to use in practice, especially in real deployments with offline users.
I agree that treating server-side move/merge/delete operations as authoritative is the right direction. The more challenging part, as you pointed out, is handling data that arrives later from offline clients without forcing a full re-sync.
One approach I’m considering is a reconciliation-based mechanism where incoming data is accepted but checked against the latest contact hierarchy. If it references an outdated structure (for example, a contact that has been moved or merged), it can be remapped to the updated hierarchy during processing instead of being rejected or causing inconsistencies. This would allow the system to remain eventually consistent while avoiding disruption to users.
To support this, we could explore lightweight ways to detect stale references, such as lineage comparison or operation-aware metadata.
I understand this area is still open-ended, but I’ll reflect this direction in my proposal and keep the design flexible based on what fits best with the existing architecture. Happy to iterate further based on your feedback .
Hey everyone! I’m Harkirat, a CSE student from Thapar Uni.
I’m applying for DMP 2026 and targeting the “Add API endpoints for advanced contact management operations” issue in cht-core. I’ve been going through the cht-conf source files (move-contacts.js, merge-contacts.js, delete-contacts.js) and exploring the existing API controller patterns in the codebase.
My stack is TypeScript, Node.js, React and I have experience building REST APIs , so the backend work here feels like a natural fit. I’ve also set up the local dev environment (Docker + CouchDB) and have been actively engaging on the GitHub issue.
Looking forward to contributing and learning from the community here!
However, we not not 100% committed to this if we can find an alternate approach that would be better. (But in general I love the simplicity of just having an 
). Either way, the short answer is that I don’t think we have idendified the best approach here yet…