Welcome to the fourth in our series of blogs documenting the process of creating a Rules as Code repository for New Zealand as part of the Digital Aotearoa Collective.
With the rules mapped (see our rules mapping blog for more information) it was time to break into two working streams:
- OpenFisca development
- Service design
The OpenFisca stream
The OpenFisca stream was led by NZ developer and Digital Aotearoa Collective (DAC) member, Hamish Fraser. Hamish was supported by another three developers, including one of the OpenFisca original French developers and me as the Salsa representative.
The first step was collectively deciding on clear standards for contributing to the project, such as critical aspects of contributing to OpenFisca Aotearoa including the GitHub Flow, Semantic Versioning and coding guidelines.
We needed to decide on contribution guidelines that outline best practices for submitting code contributions, advertising changes and documenting the codebase.
These guidelines recommend:
- Following the GitHub Flow for submitting code contributions via pull requests
- Adhering to Semantic Versioning when advertising changes
- Providing clear explanations and documentation of changes in pull requests and the changelog
- Following established coding guidelines such as consistent naming conventions and best practices for performance and maintainability
By following these guidelines, contributors can help ensure that the repository is well-organised, consistent and easy to understand, making it easier for everyone to contribute and maintain. Additionally, following established patterns and best practices will help ensure the codebase is maintainable and efficient, benefiting all Digital Aotearoa Collective users.
The social security benefits
The first five social security benefits for coding were identified as:
- Jobseeker
- Sole Parent Support
- Disability Allowance
- Child Disability Allowance
- Accommodation Supplement
The initial analysis of these social security benefits revealed shared entities, definitions, rules, calculations and eligibility criteria.
For example, in the case of the Jobseeker benefit it was determined that there were many shared entities, definitions, rules, calculations and eligibility criteria with other social security benefits. As a result, it was decided to implement the Jobseeker benefit first, so the shared variables could be reused in additional social security benefits.
The other benefits were divvied up between the developers.
Coding in OpenFisca
The process of implementing a benefit as rules as code typically involves several steps, including:
- Defining input data as variables
- Verifying if existing variables can be reused
- Defining output data as calculations
- Creating unit tests
Defining input data as variables
The first step in the process is defining the input data variables required to calculate eligibility and payment amounts. This includes identifying the specific data points necessary to determine whether an individual is eligible for a particular benefit, as well as the information needed to calculate the benefit payment amount. For example the Jobseeker required input variables for eligibility for New Zealand citizen/resident, age, work status and income.
Verifying if existing variables can be reused
Once the input data variables have been identified, the next step is verifying if existing variables can be reused. This step is vital as it helps to ensure consistency across the codebase and can reduce the amount of code that needs to be written and maintained. Using the above example, these particular variables of New Zealand citizen/resident, age and income could be reused in calculating the Sole Parent Support and Accommodation Supplement eligibility.
Defining output data as calculations
After the input data variables have been defined and any existing variables have been reused, the next step is to define the output variables for eligibility and payment amounts. This includes identifying the specific data points that will be used to indicate whether an individual is eligible for a benefit, as well as the data points that will be used to calculate the benefit payment amount. Using our Jobseeker example, we have two output variables for eligibility and the benefit amount. We require input variables for the age, residential, and minimum income requirements. If eligible, the income variable provided for the minimum income requirement is reused to calculate the reduction from the Jobseeker base rate for the final benefit amount.
Creating unit tests
Finally, the implementation process includes creating unit tests with real-world scenarios to test the variables. This step is crucial to ensure the accuracy and reliability of the rules as code. By testing the variables in various scenarios, we can ensure that they are working correctly and identify any issues that need to be addressed. The unit test we created for the example above had input variables set as age=30, residential_requirement=true, availble_for_work=true and income=300, which would expect the output variables eligible=True and amount=217.
Next steps
With the alpha launch completed, the Digital Aotearoa Collective is now conducting user testing with advocacy groups and other end users. The goal is to continue the OpenFisca development to include the other social security payments. The webform will be expanded as necessary.
View BenefitMe