Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support DAY period for variables. #763

Closed
Br3nda opened this issue Nov 7, 2018 · 6 comments
Closed

Support DAY period for variables. #763

Br3nda opened this issue Nov 7, 2018 · 6 comments
Assignees
Labels
kind:feat A feature request, a feature deprecation

Comments

@Br3nda
Copy link
Contributor

Br3nda commented Nov 7, 2018

Here is what I did:

We started looking at the feasibility of using OF on an area of law that needs to give answers on a day by day basis.

I saw OF only does YEAR and MONTH

Here is what I'd like to know:

What was the reasoning for only having these two options?

Has the concept of WEEK and DAY been looked into? Has anyone worked on it?

Would a period=DAY feature patch be welcomed?

Context

We would like to run an experiment, calculating some model applications for citizenship through Open Fisca. The rules require you have not left the country more than X days of the last rolling year, for several years in the past. This answer changes day by day. You can be not eligible on Monday, be eligible on Tuesday, Wednesday and then not eligible again on Thursday. This is because of how a trip out of the country is split by the rolling year rules.

To run this experiement, we'll need to calculated by DAY

I identify more as a:
Hacker, coder, open source contributor, public servant.

@bonjourmauko bonjourmauko added the kind:feat A feature request, a feature deprecation label Nov 10, 2018
@fpagnoux fpagnoux changed the title period of DAY for variables. Support DAY period for variables. Nov 15, 2018
@bonjourmauko bonjourmauko self-assigned this Nov 15, 2018
@Morendil
Copy link
Contributor

Looking at #766 and #768 it seems that we have tacitly embarked upon a plan of "merge a DAY period feature into Core so as to support running an experiment in OF-NZ".

I would prefer to make this explicit. One potential downside I see is that the experiment might not pan out, leaving Core with the additional support burden of a feature that is not needed elsewhere. Or the experiment might unearth new adjustments required to properly support the DAY period, leading to further PRs.

An alternative plan would be to make the required changes in a fork, and run the experiment against the fork, evolving the feature as needed. We could then open a PR with the accumulated changes to the fork, with a better chance that these represent a consistent set of changes supporting the feature for which the DAY period is required.

@Br3nda
Copy link
Contributor Author

Br3nda commented Nov 16, 2018

I'd really like to avoid moving our nz ruleset to a fork of OF core. The experiment is whether it can be used for citizenship.

There's no doubt we need DAY to continue adding variables from our law.

Is this actually an unusual case in the world? Changing state by DAY seems like a very needed core feature.

@Morendil
Copy link
Contributor

Yes, that's fine. My concern is to be explicit about what the plan is for adding this feature.

@bonjourmauko
Copy link
Member

Hi @Br3nda and @Morendil!

I saw OF only does YEAR and MONTH
Has the concept of WEEK and DAY been looked into? Has anyone worked on it?

The idea of supporting more time periods has been explored before, notably in #670.

The TL; DR:

  • It would be cool to add new time periods
  • Some very specialised time periods like FORTNIGHT and TRIMESTER should probably be taken care of per country
  • Their atomic units could be introduced in the core, like DAY or WEEK
  • Per the current implementation, WEEK is tricky
  • There's also another dimension when we think in terms of dates

Looking at #766 and #768 it seems that we have tacitly embarked upon a plan of "merge a DAY period feature into Core so as to support running an experiment in OF-NZ".
I would prefer to make this explicit. One potential downside I see is that the experiment might not pan out, leaving Core with the additional support burden of a feature that is not needed elsewhere.

I think that is at the root of how core was born and how it'll probably evolve.

At some point, there was an experiment in France called https://mes-aides.gouv.fr/. Most of what we know as being the core component of OpenFisca saw the light when MesAides was still an experiment, without any guarantee of success.

That same work proved later useful for another French initiative, https://www.mesdroitssociaux.gouv.fr/. And so on.

I agree NZ's experiment may not work, as many. But maybe the ones to come will, in part thanks to the DAY feature proposed here.

An alternative plan would be to make the required changes in a fork, and run the experiment against the fork, evolving the feature as needed. We could then open a PR with the accumulated changes to the fork, with a better chance that these represent a consistent set of changes supporting the feature for which the DAY period is required.

I understand your concerns, and it would definitely make sense in a case of greater uncertainty about what the required features are to give support to an underlying user need.

My concern is to be explicit about what the plan is for adding this feature.

As I currently understand, to calculating some model applications for citizenship through Open Fisca.

Also, I'm personally convinced that the best way we can achieve the opening of every single country's legislation with OpenFisca is by enabling all countries to better serve their citizens. 😃

@guillett
Copy link
Member

I support the addition of that feature in Core master rather than in a fork.

The age variable should be able to change on a day to day basis.
Variables that depends on the age variable should be explicit on the date that variable is considered (the start of the month, the end of the month, the request date).

Currently, in OpenFisca-France this is implicit.

@fpagnoux
Copy link
Member

Also agreeing that we should avoid forking, the need seem general enough so that I'm pretty convinced others will need it in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:feat A feature request, a feature deprecation
Projects
None yet
Development

No branches or pull requests

5 participants