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

Include a creation date field for learning resources (particularly OCW courses) in API responses #423

Open
2 tasks
mbertrand opened this issue Jan 29, 2024 · 3 comments
Labels
product:mit-open Issues related to the MIT Open product

Comments

@mbertrand
Copy link
Member

mbertrand commented Jan 29, 2024

User Story

It would be useful to include a "creation_date" field in the learning_resources API response for courses, particularly for OCW, that approximates the date that the course was created on. This is not the same as the currently existing LearningResource.created_on field which is omitted from the API and is based on the date that the resource was created in the mit-open database.

It's not a field that's required to be included for a record to be created, but given the range of dates that OCW courses have been published over, it would be helpful for a user to have when evaluating content.

Description/Context

For a course creation field, one thing that has to be considered is how to calculate this for non-OCW courses too. OCW is a bit unique in that "Quantum Physics I Spring 2013" is considered a different course than "Quantum Physics I Spring 2016", whereas for all other sources, those would be two different runs of the same course.

Acceptance Criteria

  • A creation_date field is included in the learning_resources API response.
  • A creation_date field is included in the learning_resources_search API response.

Plan/Design

Add a creation_date field to the LearningResource serializer (or alternately, the Course serializer).

Approximate the value for this field based on semester and year of the OCW course's one LearningResourceRun: Since courses are broken out into semester/year, the easiest way to list those would be ballpark dates, e.g. fall 2017 could be 2017/08/01, winter 2009 could be 2019/01/01, etc... If the semester isn't clear, defaulting to the first of the year would be a good proxy.

For non-ocw courses, use the earliest start_date value from all the course's runs. Or do we want the latest start_date instead as an indicator of how current it is?

Add this field to the search index schema as well.

@ChristopherChudzicki
Copy link
Contributor

In light of the fact that not all OCW courses have years/semester info (and that is expected for "evergreen" courses) maybe OCW courses could expose their first_published_to_production value?

That might yield better results, too. It seems to me that the "Fall 2024" inferred date might be significantly behind the actual publication date, which could bump courses downwards in a "new courses" listing. (If we used the field for such a thing.)

@pdpinch
Copy link
Member

pdpinch commented Feb 5, 2024

maybe OCW courses could expose their first_published_to_production value

Sorry, I had assumed this is what we would do for this issue.

Do all (published) courses in OCW has a first_published_to_production value?

@ChristopherChudzicki
Copy link
Contributor

Do all (published) courses in OCW has a first_published_to_production value?

  • Yes, in OCW Studio database
  • Not present in github / hugo output in s3 buckets

The ETL pipeline draws from the s3 bucket, so we'd probably want to do some work on the Studio side to include the value in github, and on hugo-themes to include the value in output.

@pdpinch pdpinch added the product:mit-open Issues related to the MIT Open product label Apr 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
product:mit-open Issues related to the MIT Open product
Projects
None yet
Development

No branches or pull requests

3 participants