Yes, I'll implement point a), but for point b), as I said above, it's not a good idea. Single worker offers are the common case while a job is running (e.g. as it finishes the first series of tasks and launches another), and it fundamentally wouldn't make sense to delay them to wait for multiple workers to finish because then you'd be wasting cluster resources. It's not just an issue when a job begins -- this aggression logic degrades locality throughout the job runtime. For example, if you have a job with cached data (process-local) that is running multiple tasks per core, some tasks will be scheduled non-locally in the current code, leading to a very expensive transfer of a block across nodes when you could've just waited a few of seconds to run on the right node. With my new code, it's still very easy to minimize the initial wait if that's a concern, and you get the additional bonus of making the process-local wait time different from the node/rack one.