Standardize recruiter classes

[polvanrijn]

Each Recruiter subclass should implement the following methods:

• list_experiments(self, filter=None), will do an API call and list all available experiments (i.e. all HITs on Mturk and all studies on Prolific), maybe provide a filter argument, e.g. filter={"status": ["COMPLETED", "ACTIVE"]} or filter={"sandbox": True} (equivalent to hits() on mturk)
• list_submissions(self, filter=None), filter is a dictionary for optional filtering
• get_details(self), returns all experiment details (equivalent to hit_details() on mturk)
• get_qualifications(self) returns a JSON with the qualifications
• get_total_cost(self), can return 0 for HotairRecruiter
• get_cost_breakdown(self), returns a dictionary, where the keys are different aspects of the cost, e.g. on Prolific base pay, bonus, and fee.
• compensate_participant(amount, **kwargs) (static), participants may be identified differently, e.g. on mturk participants are associated via email + worker id, on Prolific study ID and submission ID
• get_meta_information(self) returns a dictionary with meta information, e.g. a URL to the Prolific dashboard (e.g., https://app.prolific.com/researcher/workspaces/studies/<experiment_id>/submissions) or to the experiment settings (e.g., https://app.prolific.com/researcher/workspaces/studies/<experiment_id>) and other recruiter specific metrics, e.g. median completion time and average wage per hour.

Each recruiter should also have the attribute currency, default it can be None.

The API calls should be implemented in their respective Service.

[pmcharrison]

Is it perhaps worth breaking this into two steps:

• Refactoring the existing code such that shared interfaces (i.e. methods of the same name) are used where possible across the recruiters, leaving NotImplementedErrors for cases where something hasn't been implemented yet for a given recruiter?
• Then implement the missing functionalities in the relevant recruiters?

[pmcharrison]

I am wondering, if all of these things are implemented in the service, then maybe it's redundant to make them methods of the recruiter? Maybe they should just be accessed directly via recruiter.service?