removing check for expiration on jobs

[vsoch]

Per suggestion of @cosden in #309, this PR will remove the job expiration date, and show all jobs that have not yet 404'd as links.

Signed-off-by: vsoch vsochat@stanford.edu

cc @usrse-maintainers

[cosden]

Thanks @vsoch. It looks good to me. It does just what it is intended to do!
Look at the difference! https://887-120906408-gh.circle-artifacts.com/0/usrse.github.io/jobs/index.html

I kept feeling like we were overlooking a problem that the expiration date solved. I think it's for jobs like this: https://cu.taleo.net/careersection/2/jobdetail.ftl?job=18969&lang=en&src=LinkedIn. It isn't going to expire...potentially ever.

I'd rather have multiple "closed" job postings than remove one that is still open, so how about we leave the expiration dates in, but as standard practice put them far in the future? Perhaps many months. Treat them as a back up in case jobs are removed but URLs don't break.

So I'm suggesting we don't merge, and go back and edit the expiration dates of all jobs to 6+ months, and then let the existing checks take care of things.

Thoughts?

[vsoch]

I personally like this strategy better to just leave jobs while the url is valid. It’s much simpler than trying to manage each alone with an expiration date.

[cosden]

I personally like this strategy better to just leave jobs while the url is valid. It’s much simpler than trying to manage each alone with an expiration date.

When you say "this strategy" which one do you mean? I've read it three times and can see it going either way. Should we (a) remove expiration dates entirely and only check urls, or (b) set expiration dates 6+ months away and keep the removal script when it hits this date, or (c) something else?

I like (b) as it will keep things up for a while as long as the url is valid. And if the url is valid but the position closes the expiration date will eventually remove it without manual intervention.

[vsoch]

Sorry wasn't clear! I was referring to the current pull request, so I like (a) removing expiration dates entirely, which is almost the same as putting a far away expiration date, but requires much less work.

[cosden]

OK! Got it. I didn't want to assume!

Honestly, (a) was my original thought too. But now my concern is with what we do with urls like these:
https://cu.taleo.net/careersection/2/jobdetail.ftl?job=18969&lang=en&src=LinkedIn
https://www.usajobs.gov/GetJob/ViewDetails/577014000
https://careersearch.stanford.edu/jobs/oncology-oncore-application-specialist-oncore-reporting-group-lead-9854?et=Ysg27Ti9

Some are obviously closed (would the url check get the first?), but the others are far more subtle.

And this one still looks to have active jobs, but it's at the higher level so the URL will likely never expire:
https://brainlife.io/docs/careers/jobs/

[vsoch]

yeah, there could be some trailing links. I'm not on the usrse committee so I think it's up to you :)

[cosden]

I don't want to play that card :). And you're the defacto website committee chair.

Here's another one that will likely persist for ages, but won't get caught by the URL checker: http://carver.cs.ua.edu/RSE.htm. If you click on the link it's gone.

If no one else chimes in, I say we leave it as is with expiration dates, and I'll go through and update dates on active postings.

[vsoch]

Sounds good to me! I'll close the PR here then.