When I run /shop, the following occurs

it's your one stop shop!

On file upload it currently says "thanks for sharing, thanks for sharing!" it should say "screenshots of code don't count as proof"

Adding a README file/intro on how things in the project is laid would help others to help/engage in the codebase.

Bring back the /extend command, but instead of extending the session in the database (internally), just create a new one that's the remaining amount + 60 (or user set amount).

add media sent in threads to the top level hack hour message

the shop (/shop) should list:

• total 🎟️
• current 🎟️ available for spending
• 🎟️ locked up in current orders

I know you can run /shop to see these things, but from a user experience side it might make sense to also have a dedicated command for this.

Explicitly mention that posting in the thread flags it for re-review & if it was rejected for lack of proof they can include commits

currently when we detect if a 'scrap' has been posted we check for github.com/user/repo links– that shouldn't count the same way a specific commit link counts b/c users are spending 5 sessions & all link "github.com/user/repo", which means I can only approve 1 of the hours

Potentially use a new object Transaction that'll keep track of verified hours coming in as well as hours used in redemptions

Currently sessions are associated with scrapbooks in airtable with a random order (I suspect it's the order they were selected in slack at the "select the sessions you want to scrapbook" step). We should sort those by creation date to make sure that sessions are in order.

This was a useful command to browse sessions & their approval states, but was removed during rewriting & revisions.

Already started an implementation in the dev branch but needs more work

make arcade orders viewable with a /orders command

We're getting rate-limited hard by slack & usability goes down when more than 50 active hack hours are running at the same time.

I'd like to setup a message queue for anything that's not 100% critical & send the message out with logic to prevent us getting ratelimited like this

Hey hackclub HQ. It seems really unoptimal that we are using a minutes counter stored in a prisma database to record session time. Prisma takes around 2ms to update a record (https://benchmarks.prisma.io/?active_query=update). We are doing up to 4 update queries per session per minute, let's say about 2 on average. If we consider about 10k active users this comes down to 2ms * 10_000 * 2 = 40 seconds. This clock requires about 40 seconds of processing time per minute. If we go up to about 15k active users our time to update the records becomes longer than a minute.

I don't quite get why we would even store such often accessed data in a database. Numbers are about 8 bytes of data in javascript. We have an id which we need to store as well which are a 24 char long string which is 48 bytes. Together that comes to about 56 bytes. Take that times 15k (for every session we have) and it takes about 840000 bytes of memory to store this. That is 0.8 MB, not even a single megabyte.

Furthermore, we could use timestamps to make the whole act more efficient. We just store the timestamp when a session has started + additionally an minute offset integer, in which we will store the current minutes after we pause a session.

We can then calculate the elapsed time by using basic math let elapsed = now - sessionStarted + minuteOffset.

This is trivial to implement and still it improves the performance by a ton. Database queries are very slow. We should avoid them whenever possible. Yet we still do 2 for every session every minute. Why?

Must #scrapbook at least once every 25 hours! If you're scrapbooking more hours then that it probably means people aren't shipping quick and shipping often.

The endpoint /api/clock/:slackId considers the start time + duration as the end time and ignores pauses in the session. Relavent code

This results in lower than actual values being returned, sometimes into the negatives, for sessions that have previously been paused.

We have a bunch of people not going through the tutorial all the way and just hanging out as partial users– we're going to now require people get through the tutorial by making /arcade only work for full users.