Hmm.
This seems interesting and compelling, but I think encoding "this specific time at this specific timezone" into the foundation of the system will exclude a potentially significant number of people that may otherwise contribute to its success.
First of all, let's see how far away I am from PST... okay, 7AM PST is 1AM the next morning in AEST (in Australia). Imposing a globally-fixed time across the world, irrespective of timezone, falls on the suboptimal side of exclusive for a lot of people, since there are always going to be more people outside of any given timezone than within.
Secondly, I look at 7AM a bit deer-in-headlights: I'm incidentally temporarily using an offset sleep schedule at the moment while I rectify some environmental issues, so that time happens to be just about the mathematically least optimal moment in the day for me to approach a conveyor belt of unexpectedness with anything resembling interest. Most likely I would instead demonstrate the fastest possible method ever seen of permanently disassembling the conveyor belt, then go back to sleep :)
The above two points are my reasons why this approach would not be ideal for me. I suspect that a lot of other people would probably present unique anecdotes of their own with vaguely similar sentiment.
I would recommend a call waiting-like architecture instead. Have a giant queue of things on the server. Offer some small percentage of available tasks to a given user*, then hide those from everyone else. When the first user picks the thing(s) they want**, re-mark the unselected things as available. Do this for everyone at once.
* It will both be technically easier and socially more interesting for users to list their experience then get delivered a precomputed list of tasks, than simply go "ok here's _everything_". The 'everything' approach has terrible UX, with tasks disappearing as others "steal" them, but the precomputed ideology of "this list was calculated before you arrived" feels more like TV - the list of things the user can see is all there is. This architecture should age very well, too, allowing you to do all kinds of optimizations over time in terms of figuring out who visits and when and what tech they like and whatnot, then precalculate optimized views for each user before they arrive. You'd need a few hundred people before you'd be able to build that correctly though.
** Definitely let users pick more than one thing to add to their local queue. That way they can headscratch about (or get their brain into the zone for) complicated thing #2 while breezing through trivial thing #1. If someone queues a task they decide is actually too hard, make it feel like it's not at all the end of the world for the user to release the task back into the queue. This covers queuing up multiple things as well.
Also, make it possible for users to see all tasks they ever selected, including what they didn't complete or immediately released without starting - the user might have fat-fingered their mouse (or brain) and might want to go manually complete (or help completing) the task outside of the website. (Completely +1 avoiding the rabbithole of "wait, no, I actually wanted that task, yank it off of whoever is doing it")
In practice (from an architecture-design perspective) I reckon about 50 things and 3 or so users would probably look pretty similar to 1000 users and 150 things and 5000 users and 500 things.
In closing, even with the queue approach described here, I see the fundamental idea as very distinctly different from the asynchronicity and absolutely-unbounded-complexity of Stack Overflow. Here are 5 things. Which can you do **right now** in 15 minutes? That does not exist. It sounds awesome.
Also, SO's success, _despite_ the unboundedness issues, absolutely proves that there are people out there who will literally spend hours and hours figuring out other people's problems for free. The idea of making this process ADHD/anxiety-friendly, unintentionally or not, is why I initially said this was compelling. May you scale well :P
NB. Have you thought about supporting collaboration? That would be the next logical step for something like this - and it's so logical, it's unfortunately what everyone using the platform would likely clamor for. I recognize that it's extremely hard to even just collaboratively edit documentation etc, let alone work on solving open-ended problems with arbitrary tooling. Precisely figuring out and publishing your stance on this - eg, "nope, not interested", "sounds interesting, patches welcome", "sounds interesting, patches welcome if maintenance on offer", etc - from the start might be a good idea. (FWIW "patches welcome" can often come across as very unempathetic and ivory-towered, if you will, especially when it sticks around for a long time and gives the impression progress isn't happening. Articulation is hard, etc...)