@Ved-Patel welcome to the CHT community! Thank you for the contributions you have made and your interest in contributing further!
Ved-Patel:
Please anyone from the team guide me over the Proposal review process, how can I make a winning proposal and get accepted as I don’t have many significant contributions till date, am I needed to contribute more or write a more detailed proposal?
I do not have a lot of info regarding the details of how proposals are submitted/processed on the C4GT side. But, here is what I can share from the Medic perspective.
This year we are supporting two DMP projects:
opened 04:36PM - 10 Mar 26 UTC
DMP 2026
## Ticket Contents
The CHT has basic [Bikram Sambat (BS) calendar support](http… s://docs.communityhealthtoolkit.org/bikram-sambat/) used in [app forms](https://docs.communityhealthtoolkit.org/apps/reference/forms/app/#bikram-sambat-datepicker), but several quality-of-life issues make it incomplete for users in Nepal and other regions using this calendar system. The current date picker is minimal (no calendar view, no month navigation), the Reports tab filter still shows the Gregorian calendar even when the language is set to Nepali, there is a bug where dates convert incorrectly when no month is selected, and [targets/UHC counts](https://docs.communityhealthtoolkit.org/building/targets/) reset on Gregorian month boundaries instead of Bikram Sambat month boundaries.
This project is a collection of improvements to make Bikram Sambat a first-class calendar experience in the CHT. The work can be done incrementally (one issue at a time).
## Goals & Mid-Point Milestone
- [ ] Understand the existing Bikram Sambat date picker implementation and the [`bikram-sambat`](https://github.com/nickshanks/bikram-sambat) library
- [ ] Fix the bug where the date picker defaults to Baisakh (first month) when user hasn't selected a month, allowing incorrect date conversion
- [ ] Upgrade the Bikram Sambat date picker with proper calendar view (month/weeks), month/year navigation, "today" button, and clear option
- [ ] Integrate Bikram Sambat calendar into the Reports tab date filter (currently shows Gregorian even in Nepali mode)
- [ ] Add configuration to align target/UHC count resets to Bikram Sambat month boundaries instead of Gregorian months
- [ ] Write unit tests and e2e tests for all changes
- [ ] **Goals achieved by mid-point milestone:** Date picker bug is fixed, date picker is fully upgraded, and Reports tab date filter uses BS calendar, with unit tests
## Expected Outcome
- A fully functional Bikram Sambat date picker with a proper calendar view, navigation controls, and parity with the Gregorian date picker UX
- The Reports tab date filter displays the Bikram Sambat calendar when the platform language is set to Nepali
- The date picker no longer silently defaults to Baisakh when no month is selected
- A new configuration option (e.g. in `app_settings`) that allows target/UHC counts to reset at the beginning of BS months instead of Gregorian months
## Implementation Details
The Bikram Sambat date picker widget lives in:
- `webapp/src/ts/` (Angular webapp components)
The [nepali-date-picker](https://github.com/opensource-nepal/nepali-date-picker) ([demo](https://leapfrogtechnology.github.io/nepali-date-picker/demo/)) can be used as reference for the improved date picker UI.
For the date picker bug: the widget currently converts the date even when the user hasn't selected a month, defaulting to Baisakh. The fix should either require month selection before conversion or handle the missing month gracefully.
For the Reports tab filter: the date filter component needs to detect when the platform language is Nepali and render the BS calendar instead of Gregorian. Date range conversions between BS and Gregorian will be needed for the underlying CouchDB queries.
For target/UHC alignment: currently targets are stored with an identifier that includes `YYYY-MM` for the Gregorian month. The [`uhc.visit_count.month_start_date`](https://docs.communityhealthtoolkit.org/building/forms/configuring/uhc-mode/#settings) setting controls the day targets reset. A new configuration would override this to use BS month boundaries instead.
Key technical consideration: an open design question exists around whether a BS month can ever start and end within the same Gregorian month, which could cause target document ID collisions.
## Product Name
Community Health Toolkit: `cht-core`
## Organization Name
Medic
## Domain
Healthcare
## Tech Skills Needed
Angular, CSS, Docker, JavaScript, Mocha, Node.js, TypeScript
## Organizational Mentor
@sugat009, @jkuester
## Complexity
High
## Category
Frontend, Localization
opened 04:32PM - 10 Mar 26 UTC
DMP 2026
## Ticket Contents
Currently, the CHT (Community Health Toolkit) app allows use… rs to perform basic contact management tasks such as creating an editing contacts. Users with the proper permissions can also delete contacts, but _only if there are no child contacts associated with the contact to delete._
More [advanced contact management](https://docs.communityhealthtoolkit.org/building/contact-management/moving-contacts/) current requires a system administrator to use the [`cht-conf` CLI tool](https://github.com/medic/cht-conf). `cht-conf` can perform operations like [moving](https://github.com/medic/cht-conf/blob/main/src/fn/move-contacts.js), [merging](https://github.com/medic/cht-conf/blob/main/src/fn/merge-contacts.js), and [deleting](https://github.com/medic/cht-conf/blob/main/src/fn/delete-contacts.js) contacts in the hierarchy (note that the `delete-contacts` action in cht-conf is _recursive_ so that it also deletes all the child contacts). Having this functionality in `cht-conf` creates friction for users who cannot perform these actions themselves through the webapp, especially when dealing with duplicate contacts or reorganizing health facility hierarchies.
It also forces services like [cht-user-management](https://github.com/medic/cht-user-management) to either re-implement these operations or else somehow leverage cht-conf under the hood to perform them.
This project aims to add REST API endpoints in `cht-core` for these actions. The work can be done incrementally (one action at a time), giving it a limited initial scope with room to expand. The goal is simply to have api support for these operations. Updating the webapp to actually give the user access to these operations is _out of scope_.
## Goals & Mid-Point Milestone
- [ ] Understand the existing `cht-conf` move/merge/delete contact logic
- [ ] Implement the delete-contacts API endpoint with support for recursive hierarchy deletion
- [ ] Implement the move-contacts API endpoint for relocating contacts between parent hierarchies
- [ ] Implement the merge-contacts API endpoint for combining duplicate contacts and reassigning all linked documents (reports, tasks) to the surviving contact
- [ ] Write API documentation for all new endpoints in [cht-docs](https://github.com/medic/cht-docs)
- [ ] **Goals achieved by mid-point milestone:** Delete-contacts and move-contacts API endpoints are functional with unit and integration tests
## Expected Outcome
New REST API endpoints available in `cht-core`:
- `DELETE /api/v1/contact/:uuid` (or `POST /api/v1/contact/:uuid/delete`) for recursively deleting a contact and its children in one step
- `POST /api/v1/contact/:uuid/move` for moving a contact (and its subtree) to a new parent
- `POST /api/v1/contact/:uuid/merge` for merging two duplicate contacts, reassigning all linked documents to the surviving contact
These endpoints replace the need to use the `cht-conf` CLI for these operations, enabling them to be performed programmatically or through the webapp.
## Implementation Details
The existing `cht-conf` implementations serve as the reference for the core logic:
- [`cht-conf/src/fn/move-contacts.js`](https://github.com/medic/cht-conf/blob/main/src/fn/move-contacts.js)
- [`cht-conf/src/fn/merge-contacts.js`](https://github.com/medic/cht-conf/blob/main/src/fn/merge-contacts.js)
- [`cht-conf/src/fn/delete-contacts.js`](https://github.com/medic/cht-conf/blob/main/src/fn/delete-contacts.js)
New API controllers should be added in `api/src/controllers/` following the patterns established by the existing person, place, and report controllers.
Key technical considerations:
- TODO these actions may involve long-running processes. We need to determine if we should block our REST response until the process actually completes (our typical approach for existing endpoints) or if we should implement some kind of "polling" pattern where we queue the operation and then immediately return a reference to it. Then the consumer can poll a `/api/v1/operation` endpoint to get the status (and know when it completes).
- Permission model should follow the `hasAny` pattern (e.g. `can_delete_contacts` OR `can_edit`)
- Delete must handle recursive cleanup of child contacts and all associated documents
- Move must update parent lineage references across the entire subtree and linked documents
- Merge must handle conflict resolution and reassignment of all linked reports and tasks to the surviving contact
## Product Name
Community Health Toolkit: `cht-core`
## Organization Name
Medic
## Domain
Healthcare
## Tech Skills Needed
Docker, JavaScript, Mocha, Node.js, TypeScript
## Organizational Mentor
@sugat009, @jkuester
## Complexity
High
## Category
API, Backend
On our end, once the DMP application process is complete we receive a list of candidates that have applied to work on these projects. Our candidate selection process is similar to what you might expect from any internship opportunity. We evaluate candidates based on all the information we have including the proposal, interactions on GitHub issues/PRs, here on the forum, as well as in various public CHT community meetings . It is not just about quantity , but also about quality .
1 Like