undate planning meeting 2024-05-02

[rlskoeser]

meeting to determine people's interest and availability in continuing to work on undate development

Cole:

• have some projects that could benefit
• some capacity, but working on python-edtf
  • old spec, trying to get it up to date to latest version of the spec
    https://www.loc.gov/standards/datetime/
  • managed by australian group that does library dev; main dev left
    • someone from leipzig did some work to try to get it up to date
      • pr languished, so they forked it but can't maintain
      • trying to cherry pick their changes
      • company is responsive now
  • undate - replacement for python-edtf or something different?
    • need to look again and figure out what the difference was
    • got buy in from the team; was a blocker before
  • to work on: if it's for a project, can spend more time on it; otherwise, fit it in but harder to justify
  • review is easier to fit in

Robert:

• don't have concrete uses; something could use in a web project, but hasn't come up
  • can look at PRs but not as much into the codebase, but would be more superficial, looking at python understanding
  • dealing with calendar systems - out of scope?
    • have a widget in research space, converts between calendars in js
  • RSK has calendar conversion code in geniza code
    EDTF ignores the problem entirely (multiple calendars)
• most implementations choose one calendar for comparison

Julia:

• one project where this would be useful, but a pretty big lift to change things around
  • pain pressure is not high enough to do this
• happy to review things if there's a need, but like Robert, may miss some of the details

Rebecca:

• interested in working; lots of ideas but not sure how to prioritize
• integrate geniza calendar conversion
  • geniza code has to do calculation for comparing/combining date ranges, undate could do this much better
• pandas datatype
• better logic for comparing, sorting, set calculations
• handle farther future dates; e.g. science fiction time horizons dataset
• JOSS submission: feature complete / stable
  • what would be the list of features that are 1.0 ? what's beyond that?

brainstorm/decide 1.0 features

• is calendar conversion 1.0?
• what about django implementation?

[rlskoeser]

process / procedure

regular meeting - monthly seems like the right frequency

• chance to discuss PRs or other decisions that require conversation
• thursdays are a pretty good day; this time works
  • RSK will send an invite
• use github discussions questions ahead of time between meetings
• open up to community in next newsletter?
  • document what we're working towards - checklist for v1
    • invite people to contribute to that or help
    • would be great to have people contributing more examples of how this is useful,
      use cases with their data or projects
    • make more inviting: right now it doesn't say exactly what it does / what it is for
• PRs not reviewed within a month can be merged
  • meeting can serve as a checkpoint
• contributor guidelines
  • have a document, but may not be sufficient
  • what contribution is enough to be included in the citation ?

[rlskoeser]

1.0 release target functionality (preliminary)

• EDTF support level 1 would be useful
  • level 2 has weird things like set representations, not sure how useful
  • we should use level 2 unspecified digit
  • can say we fully support 0 and 1 and specific features of level 2
• human readable dates formatting (import/output)?
  • recent discussion on dhtech slack
    • our built-in label could be useful here
    • harder question, maybe a 2.0, but would be really valuable
  • additional problems with internationalization, localization, language
• calendar conversion code from geniza codebase (specific calendars that are relevant )
  • julian, gregorian, hijri, anno mundi
• database/django implementation for storing these dates?
  • may not be required for 1.0, but Cole most likely to help here
  • have existing codebases to look at (s&co, geniza, python-edtf)
  • make sure it's not a barrier for others to use (keep django optional)
    • otherwise, could be a separate package
  • next month: discuss how we want to implement undates in database
• pandas/polars datatype ?
  • if this easy it would be nice to have; decide by next month how hard to implement
  • also make sure it's optional / doesn't pull in heavy dependencies
• determine date operations for 1.0
  • comparison, equality; anything else essential?

current planned/supported date formats seem sufficient for 1.0; more could be added later

It would be interesting to do benchmarking for date comparisons; what is the performance hit for undate objects vs python datetime objects. What is the impact if someone is using this for a large project? Could check with synthetic data in pandas

todo:

• RSK: identify code from past projects we could think about adapting
• submit to US-RSE ? poster/talk/presentation?
  • notebook: shows how to use it; tutorial - but more DH context appropriate
  • poster: overview
  • but talk could go into how the humanities / domain matters, room for discussion