Selwin Ong

Sounds good to me @parthvnp :)

> Should the on_status_change_callback be used a generic replacement for on_success, on_failure and on_stopped callbacks or should it be used alongside these variants. Not in the near future, though I...

Thanks for the PR! I really like the concept of having a centralized entry point, but I'm wary about jamming all the args and kwargs that `Worker`, `Queue` and `Job`...

> I personally think this is a more powerful way of enqueueing jobs (i've been using it in production for a while now), mainly because it allows for a single...

> When I've seen discussion about simplifying this or moving to a centralized object, I envision something along the lines of an RQConfig class that holds all the "settings" --...

Hello, may I know what's the use case for this? I don't think making the version number user configurable is a good idea.

Not yet, but we can already do `queue.enqueue(foo, on_success=do_something, on_failure=do_another_thing)` so this feature won't be hard to implement. I propose the following API: ```python queue.enqueue( foo, callbacks=Callback(on_success=foo, on_failure=bar, on_remove=baz) )...

> Which registry are you thinking of? ScheduledJobRegistry (in which case it would be the equivalent of cancelling a job)? I imagine this would be used as an error handling...

Will take a look at this

Yes it may. RQ is not designed for multiple jobs with the same ID to be executed simultaneously. If this causes error, you should try downgrading to an older version...