HR recently switched to an externally hosted applicant tracking system called Jobvite. It's sadly proprietary, but very feature-rich and used by many tech companies, including e.g. Mozilla. Basically the previous process was for candidates to be dumped in a shared inbox, where recruiters and hiring managers would have to keep track of them with the aid of tracking spreadsheets and lots of emails. An ATS automates a lot of the tracking and workflows, and helps ensure that people don't get dropped. It also sends hiring managers reminders to submit all the required hiring documentation, etc. So in general it's a good thing, although we sometimes curse at aspects of its UI.

The rationale for the iframe is to automate the job listings on the WMF site and surface the various Jobvite features.

Yes, that means that the user's browser will contact hire.jobvite.com when loading the page (although all its resources will be loaded in the context of the iframe). AFAICT the main issue here is to clarify in the footer that job applications and job descriptions are run through an external service called Jobvite and subject to the Jobvite privacy policy, to avoid any confusion.

Whether the iframe is a good idea still remains to be seen. Jobvite makes it unnecessarily hard to link to JDs directly (because their ideology is that everyone should come through some social media funnel, I think), and the navigation is heavily JS dependent right now. So we might want to switch back to a hybrid format. The job pages are also still actively being re-designed, and the setup might change significantly in coming weeks.

Erik

Erik Moeller wrote:

The rationale for the iframe is to automate the job listings on the WMF site and surface the various Jobvite features.

Right. But any feature comes with an associated cost. :-)

Yes, that means that the user's browser will contact hire.jobvite.com when loading the page (although all its resources will be loaded in the context of the iframe). AFAICT the main issue here is to clarify in the footer that job applications and job descriptions are run through an external service called Jobvite and subject to the Jobvite privacy policy, to avoid any confusion.

Well, it's a lot more than that, surely. It reads to me like you're kind of down-playing the implications when you say "yes, that means the user's browser will contact hire.jobvite.com." This particular data is treated as sacrosanct within the Wikimedia community (for better or worse). <iframe>s have serious privacy and security issues. If they didn't, they'd be an awfully convenient tool for implementing all kinds of neat ideas both between Wikimedia wikis and between Wikimedia wikis and the outside world. But they're banned in MediaWiki by default (with good reason).

Through a loophole (allowing raw HTML on wikimediafoundation.org), they're allowed in this specific case, but it's a matter of figuring out whether Jobvite's privacy policy is compatible with Wikimedia Foundation's, I think.

Whether the iframe is a good idea still remains to be seen.

Indeed. I've commented out the iframe for now while discussion continues. Once there's a clearer understanding of the implications of using this code and whether this particular third-party's policy is compatible with Wikimedia's.

I say "compatible" as it's a passive read action of wikimediafoundation.org that will trigger data being sent to Jobvite. Adding a footer might be nice, but if the user doesn't consent to Jobvite's privacy policy, simply reading wikimediafoundation.org has already sent their data to the other server, correct? In my mind, that means a footer or additional warning text is insufficient.

MZMcBride