sandboxnu / boba-buddies

Sandbox's virtual water cooler conversation app.

boba-buddies

Sandbox's virtual water cooler conversation app.

How to Contribute :D

At the current state of things, feel free to take on any open issues and make a PR for it.

Tech Stack

TypeScript
Node.js
Slack Bolt API
Jest Framework for Testing

Wiki

https://www.notion.so/Boba-Buddies-WIP-c90d9071bfad43b4aa679aee7b0eb913#00415aa2d4c14edc979dd3589cf2fdfb

boba-buddies's Issues

Implement Pairing & Intros Flow

Write a script that does the following:

• Retrieve all members in a channel
• Pair off members
  • Keep track of past pairings to avoid doing it again
    • If we have to pair people again (unlikely) send a cheeky message saying "oops! sorry! deal with it!"
    • Write basic JSON or text file or something with pairings (must be sophisticated), so that the "checking up" functionality can do its job
• Open a DM with members (for each pairing)
• Send intro message
  • Icebreaker — what's your hot take? favorite fruit? favorite boba flavor? ... (we can come up with these ourselves and be creative) (but the ones we mentioned have to be there)

OFC ask me/the channel if you have questions on this.

Register new Slack app to Sandbox workspace

Leaving this as a placeholder for myself, I'll take care of this

Task is to register a Slack app for boba buddies to the Sandbox workspace (this will mostly be a non-coding task). It'll probably involve making a new channel for testing as well.

Aggregate statistics into "BobaBuddies Wrapped"

This was requested as a feature we could add similar to "Spotify Wrapped" or the one that DonutPals sends out at the end of the semester. Essentially, we'll want to track some data every time a person meets their boba buddy throughout the semester and compile them into something like a personalized report for every user.

You can refer to this thread as reference and inspiration: https://sandboxneu.slack.com/archives/C02CNKJ3EQJ/p1642014766001400

Utilize DynamoDB

ah yes, instead of relying on json files for sophisticated json-as-a-database, we should try to leverage DynamoDB with the AWS credits we have already.

This way, we don't have to store json files in memory if we were to deploy a server on a EC2 instance.

Write a nice README

Should include at least:

• purpose of project
• how to develop

Prevent spamming the CheckIn button

pretty self explanatory

With the kekyes or kekno buttons for checking in on pairs, we wanna make sure people don't spam these buttons since they'll increment our data incorrectly.
So maybe we could somehow edit the checkin message after someone clicks the yes or no button.

Initialize Slack Bolt API

https://slack.dev/bolt-js/tutorial/getting-started

Do this to get the repo set up with a hello world

Cron Job Setup Research

as part of the deployment for the bot later on, we'll want to consider automating it by setting up a cron job. this is less coding and more of a research oriented task.

the main idea is: if we want to set up cron jobs for the BobaBuddies bot to do some action every two weeks, what are the steps to achieving that?

here's a couple resources I briefly found that you can reference:

• https://crontab.guru/
• https://dev.to/killianfrappartdev/a-simple-slack-bot-with-crontab-and-javascript-6ka
• https://ostechnix.com/a-beginners-guide-to-cron-jobs/

Set up bot message for checking if pairs have successfully met (or not)

Basically, once we have finalized how lambdas work, we can work on setting up the user facing slack messages. Connectivity to the aws lambda and what not will be a separate ticket.

The message entail having the bot ask whether a pair have met or not and the user would likely click on a "yes we have met" button. The message should be similar to this snippet:

Add action buttons in intro

Donut does a great job of enabling quick action through buttons like this:

We should do something similar

Shuffle pairs randomly V2

As we have it right now, generating/shuffling new pairs every cycle doesn't account for new members who might join the boba buddies channel midway through the semester. In this case, they might not be accounted for when new pairs are made.
Technically, we could just randomly shuffle to the best to our ability and hope there won't be duplicate pairs across the semester.

I've found another way to go about this from the great stackoverflow via bruteforce:

1. permute all possible pairings into empty set - order doesn't matter
   1a. if there exists a new member, then permute all possible pairings with them and append to set
   1b. or if someone left the channel early, yeet all related pairings from set
2. every 2 weeks, pop the minimum disjoint pairs needed from the set
   2a. if there is a loner, add it to the last pair
3. repeat steps 1-2 if set of all pairings is empty, meaning everyone has met at least once

Setup GitHub Actions as CronJobs

tako brought up a great point about leveraging GitHub Actions to automate the Slack Bot. From a glance this seems feasible, but more research can be done. There are a couple things we'll want to integrate with GitHub Actions:

1. Creating new pairs and sending out icebreaker msgs
2. Send out the mid-point check-in message

Here a few resources to look over related to this work:

• https://docs.github.com/en/actions/security-guides/encrypted-secrets
• https://crontab.guru/
• https://dev.to/anshuman_bhardwaj/free-cron-jobs-with-github-actions-31d6
• https://docs.github.com/en/actions/quickstart

make our json as a database more sophisticated

from our last meeting, we agreed that we should keep track a couple more statistics in our s3 file to create our own bobabuddies wrapped.

Currently, i believe the json file in s3 only keep tracks of number of pairs overall.
So, we now want to add onto this and keep track of each person's

• number of times met with their buddies
• longest streak of meeting their buddy
• current streak of meeting their buddy

Just so we don't forget, the bobabuddies wrapped we'll create is being sent biweekly, so we want to make sure data is "reset" accordingly. This would probably be used when tracking the number of pairs met in each cycle as well as before each semester to start a clean state.

Deploy app

We want this app deployed eventually, so that it can run its matching/messaging job weekly, and also listen for responses in those match channels.

Simplest way (maybe not most efficient) IMO is to just run the app on an AWS EC2 or equivalent, and put the script that does the matching stuff on crontab.

Write some sick lambda handlers

This is after we get some of the lambda workflow set up after stealing borrowing some of Graduate's aws credits.

Basically, the lambda handlers are where the business logic will be stored with recording statistics like whether a pair has met or not. I'm not exactly sure what the parameters would be when the request url is hit from the user/slack bot side, so you might wanna look into that. I suspect we have an event type enum with some sort of data passed into the payload?

I think this can be a good reference for fleshing out the logic: https://medium.com/glasswall-engineering/how-to-create-a-slack-bot-using-aws-lambda-in-1-hour-1dbc1b6f021c

Update wiki

wiki is outdated after we integrated dynamodb and eventually the addition of a cronjob/github action flow

Keep track of past pairings

We should keep track of past pairings so that generatePairings (in utils/) doesn't pair the same people twice.

• If we have to pair people again (unlikely) send a cheeky message saying "oops! sorry! deal with it!"
• Write basic JSON or text file or something with pairings (must be sophisticated), so that the "checking up" functionality can do its job

checkIn message history doesn't filter right

this shit don't filter right??

In the checkIn.ts file, we run a filter on the message history of a pairing's group chat to see if they've talked to each other or not. But I think it's not filtering right since it'll send the incorrect message when no one has said anything yet.

Another thing is that if two people have already met, then the slack bot will just reuse that group chat made previously and not create a new one. This will also send an incorrect message because it'll think the new pairing have messaged each other when they didn't yet.

boba-buddies/utils/checkIn.ts

Line 28 in 6bfcebe

const userMessages = historyResponse.messages.filter(message => message.user !== BOT_USER_ID);

Testing Lambda Setup

I believe we have decided on leveraging AWS lambdas to handle the responsiveness of slack messages for our bot. So we want to set up some dummy lambda/endpoint to see how the flow would work and then build upon it afterwards.

I suppose the deliverables would involve demo-ing to the team some type of user interaction (DMs, clicking button, or etc) with the BobaBuddies bot that would hit the request url to fire off the lambda handler.

Implement "check-in" flow

Implement the check-in flow to make sure people meet

• Retrieve pairings.json or whatever sophisticated storage we use for pairings
• Check DM with those two pairings and bobabot
• If messages, do nothing, or maybe say something fun like "good to see you guys getting along!"
• If no messages, randomly select and ping somebody to start the conversation

Any questions, ask the channel or DM me!