Scoring calculation

Proposals Pitches
6

Thanks Megan, it’s helpful to hear that your team also needs this. Is there a specific set of questions that we can model this after?

7

Hi Robert! We had hired Jozian to create a tallying function that automatically calculates scores for two surveys - the Felt Stigma and Psychosocial Wellbeing subforms. These surveys measure the outcome and impact that case management services have on survivors to better inform their individual case management services, as well as broader programmatic decision making.

To calculate the scores, you add the points across all 10 items, then divide the total by 10 (the total number of questions). If the survivor skipped one or more items in the questionnaire, their average point score is calculated for the answered questions only. To do this, the points for all answered questions are added together, and divided by the total number of questions answered. For example, if the survivor answered 8 questions, the sum is divided by 8.

The issue is, the final automatic calculation rounds the average to a whole number, without decimals. The entire scoring system, however, is developed and based on decimals to the hundredth place. Without the decimals, these automatic calculations are unusable.

The good news is the coding is there! Automatic calculations exist! We just need to include decimals and not have them round to whole numbers. Let me know if this is unclear - I’m happy to explain further.

8

Based on the discussion here is a scope for the work:

  1. Provide a calculated field type and expose this calculated field type in the UI
  2. Ensure that this field type supports aggregations
  3. Provide an interface to select 1-n numerical fields across forms and subforms (this should be limited to within discreet modules I assume?)
  4. Modify the avg function to round to some arbitrary number of decimal places
  5. Output the result of the calculation into a read only (disabled=true) field. Note that support for outputting the result into labels such as question help texts for example is out of scope
  6. Run QA and write tests for the modified functionality

Time: 2 months
Estimate: 5 ETH

9

Hi Ian. I think the approach sounds good. To your question on point 3 (limiting this to discreet modules), I think that’s correct but I’d like to get more clarity. I’d also like to request that you submit the cost estimate in USD as the ETH value has been fluctuating a lot

10

Point 3 just to clarify:
We have an instance with both CP and GBV modules deployed. The same questions are asked in both modules about risk. A case suffered GBV and requires CP
We should NOT be able to work out an average in this case across modules. We can work out an average risk for the child for CP and then a separte average risk for GBV - but we cannot work out a combined average risk
On todays eth price the 5 eth estimate for the work is $US18k in dollars

11

Thanks for clarifying. AS defined in your approach, this seems like it might be slightly too large a scope of work for the DAO. Can you suggest ways we might chunk it out into smaller pieces?

12

Probably the easiest way would be to separate the front end and back end work. Back end work would be the calculated field type, aggregations, mathematical functions, qa etc. It would be slightly less than 50% of the estimated amount. Front end work would be exposing fields in the UI, selecting fields in forms and sub forms, outputting results coherently and writing tests/qa. This would be the rest of the amount.
Problems with this are that the backend work is not really visible to end users so the acceptance criteria is harder to establish. Also the front end work will take longer to do (with much more back and forth) than the backend stuff

13

Hi Ian, I think the perhaps best way forward is to take on these 2 specific projects (Phanneth’s request from Cambodia and Megan’s for GBVIMS+). From this we could learn more about how we might can make these features available (through the form builder) in a future release. If we took that approach, how would your level of effort estimate change?

14

The work then would be:

  1. Modifying the calculation function to enable decimals for GBV folks
  2. Verifying the GBV calculation work is recognised on CP and porting over whatever is missing or does not work
  3. Configuring the server for @pkhauv to enable calculations. This will just be in a single form or a single sub form for now with values hardcoded

Estimate: US5k

15

I think this sounds like a better approach. @megan.obrien what do you say?

16

If it’s helpful to understand what we are looking for, here is the scope:

  • Create a tallying function that adds the points from the responses entered into Felt Stigma Subforms

  • Create a tallying function that adds the points from the responses entered into Psychosocial Wellbeing Subforms

  • Create a tallying function that provides a score for each Felt Stigma Subform. This is calculated adding the points across all 10 items, then dividing the total by 10. If the survivor skipped one or more items in the questionnaire, their average point score is calculated for the answered questions only. To do this, the points for all answered questions are added together, and divided by the total number of questions answered. For example, if the survivor answered 8 questions, the sum is divided by 8. This will require decimal points to be available as a part of number responses.

  • Create a tallying function that provides a score for each Psychosocial Wellbeing Subform. This is calculated adding the points across all 10 items, then dividing the total by 10. If the survivor skipped one or more items in the questionnaire, their average point score is calculated for the answered questions only. To do this, the points for all answered questions are added together, and divided by the total number of questions answered. For example, if the survivor answered 8 questions, the sum is divided by 8. This will require decimal points to be available as a part of number responses.

  • Ensure that the scores are included when the Felt Stigma and/or Psychosocial Wellbeing subforms are exported

I’m happy to jump on a call to discuss further if that would be useful!

17

I think we are ready to vote on this one. What do others think?

1 Like
18

I am happy to vote - definitely in favor of getting the above completed!

19

Here is a recap of the updated proposal given the feedback:

Proposal one-liner:
Decimals on scores and configuration of a server to enable them per unique form

Value proposition
Automate some specified calculations and avoid possible inaccuracies when using manual calculations.

Brief explanation
The scope of the work is as follows:

  1. Modify the calculation function to enable decimals as an output
  2. Verify that the current calculation work is recognised on the child protection module and port over whatever is missing or does not work
  3. Configure the server for Cambodia to enable calculations for a single form or a single sub form. The values will be hardcoded into the server configuration and will not be user configurable

Acceptance criteria
The first acceptance is getting the decimal changes accepted into the Primero codebase (along with a test). The second will be UAT from the Cambodia team

Time estimation
Some parts of this (particularly the second) rely on factors external to the development team. Consequently we need to allow 2 months

Risk estimation:
The major risk is one of expectations from the field teams in Cambodia so we need to align on this before we start

Proposal Stakeholders
UNICEF Cambodia, Primero CP and GBV teams

20

The decimals work for GBV is completed (waiting a migration) however the Cambodia work is blocked waiting for clarity on the forms needed

21

Dear Ian and all, sorry for the delay. it is now confirmed that there is no change to forms so please kindly proceed for Cambodia. Thanks

1 Like
22

Hi @pkhauv , thats good news. Please can you provide us with a list of the forms for us to enable the scoring on?
Thanks!

23

Hi Ian,

Please find the requirement in the link

https://unicef-my.sharepoint.com/:x:/r/personal/mmmagar_unicef_org/Documents/UNICEF%20EAPRO/Primero/Cambodia/Development%20Work/Assessment%20scoring%20feature%20requirement_FINAL.xlsx?d=w3cd7dc00e2904e028edf57a104813ada&csf=1&web=1&e=28yp5c

Thank very much.
Phanneth

1 Like
24

Thanks @pkhauv for sharing this. We’ve done a revision of the feature and it’s looking good! We will do some further QA but this work should be committed and available before the end of the month. Congrats on being the first Data Challenge winners AND the first to get their feature delivered.

25

Hi everyone,
We have a unique situation that I want to share. In this proposal, we started with a large scope of work. We decided to break it up into chunks bc we considered it too big the DAO. The DAO approved Ian and Awen’s proposal to tackle the first chunk ([Phanneth’s original proposal + Megan’s GBVIMS+ proposal ](Scoring calculation)) , which is now completed and ready to merge and make the payment ($5k). HOORAY!
The second chunk of the work, which was NOT initially approved through the DAO, was making calculations more generally available throughout the system. When the dev team started working on the first part, they realized that it would be impractical and cause future work.
SO, we approved the work for Ian/Awen to finish the job and we will pay they previously quoted amount from the thread above. ($5k)
Potential future work could be exposing this within the UI to allow admins/end users to implement this themselves. This work was initially estimated at $8k. ($5 + $5 + $8k was the initial estimate).
That’s the whole story, feel free to respond here with questions.