Responding to modal interactions in the app DM is quirky UI, best to put everything in the same place (the log channel).

Theory is a change in the resolution flow is inadvertently nullifying the gifts

See checklist here: https://api.slack.com/start/distributing/guidelines

• Remove @channel from messages
• Automatically add bots to log-channel when set
• Remove messaging functionality for apps, put ephemeral messages in log channel
• Audit error messages
• Add help messages to all slash commands
• #60
• Add explanations for different scopes

We are getting rate limited by trying to sync the workspace every time someone opens the home screen. We should restore the specialized "sync" slash command, or find a different place to include it.

Reduce precision to 10-points, penalty at 20 points per heart.

• Sort chores by point values
• Sort chores by speeds
• Sort things alphabetically by category and name

Specifically, include the minimum quorum in each poll.

Essentially, adjust the current month's issuance rate based on last month's surplus, such that this the sum of this month's new points plus last month's leftover points is equal to some constant. This is to prevent a slow points inflation as unclaimed points accrue month-over-month.

https://docs.newrelic.com/introduction-apm

Display the house heart values during the karma update

Currently, times are all GMT, which means that users in California get cut off at around 4pm on the last day of the month.

Use the user's tz offset when displaying points values on the home screen, and calculating penalties.

Requires another trip to the database after posting the message

Need to store channel and ts from the initial message

Many of the functions involving voting are time-based, and currently many checks are done in javsascript, in between calls to the database. More sophisticated SQL should be able to incorporate these checks directly (such as disallowing votes past the end of the poll, or calculating poll). It's not immediately obvious how to do this, so punting it for later, as doing the logic in javascript gets the job done for now.

Examples:

https://github.com/kronosapiens/mirror/blob/master/src/modules/polls/models.js#L23
https://github.com/kronosapiens/mirror/blob/master/src/modules/polls/models.js#L43
https://github.com/kronosapiens/mirror/blob/master/src/modules/polls/models.js#L51

getActiveResidentCount is over-counting residents who are on break. This is due to an incorrect SQL query which returns a false negative in the case that a resident has already entered a break in the past.

Fixed in 603b918

• More sparkles as someone completes more chores (e.g. one sparkle per 25)
• Add newline before app buttons
• Add chore ranking to ranking options
• Add tips to chore slash commands
• Message when loading house acct

After discussion, update the default parameters for chore penalties & hearts regeneration to:

• 10 chore points per 1/4 heart loss
• 1/2 heart regeneration per month at baseline
• 1 heart regeneration for the karma winner
• Drop the chore points surplus rate from 10% to 5%

Under this scheme, 80 points / month becomes a steady state for residents, losing and regaining a half-heart. At 105 points per person per month, we may observe a small inflation effect, ideally counteracted by the "points sink" effect of crossing 100 in a month. Will have to observe what happens in practice over the next 2-3 months.

Would require re-implementing gifts as debits against the month's chore balance, vs a deduction from a specific claim.

With people going out of town for long periods of time and having subletters, it would be useful to support an additional state for residents beyond "active" or "inactive", which is meant to mirror their state on Slack. By introducing an admin-settable "exempt" state which would exclude residents from chores, we could allow residents to remain in Slack without having them counted as part of the house's live-in community.

Note that this functionality should be used for people away for one month or more. For shorter absences, the breaks functionality should be used.

For a first implementation, we will introduce the minimal change -- exclusion from chore points. In the future we may adjust the semantics to exclude additional behaviors.

Spec:

1. Admin should be able to toggle exempt true/false

• Takes effect immediately when being set to true
• If being set to false, the activeAt timestamp should be updated

3. If exempt == false, behavior remains the same as currently

4. If exempt == true:

• user is excluded for the purposes of chore points issuance
• user cannot claim chores

5. Regardless of status:

• user chore preferences remain in effect
• user hearts behavior remains in effect
• user things behavior remains in effect
• user can still vote in polls

Having a single /mirror-sync slash command for all apps is confusing.

• #84
• Implement parallel flow for Things

• Add ability for users to input quantities for regular buys
• Remove quantity from Things entries in DB, add to metadata

For some reason, with postgres the knex updatedAt functionality doesn't actually update by default, which seems odd but so it goes. If we're going to have those columns, they might as well work.

One winner per 5 residents, rounding up.

• Update slack log level to "Info"
• Add a per-endpoint log including residentId at beginning of each request
• Add log event whenever a database struct is created

Add additional constraint of min(numUniqueRecipients, CEIL(numResidents / 3))

Currently we don't automatically resolve polls for Chores & Things. We should work that in somewhere, transparently.

After closing this issue we can do a release, I think.

Currently the metadata columns can be set to null. This requires additional redundant handling in the codebase. Making the columns not-nullable with a default value of {} would allow easier handling downstream.

• Update schema to make columns not-nullable with default values
• Update existing entries to have default values where null
• Update existing tables to use default values for new entries

Reference SQL:

-- 1. Update existing NULL values to an empty JSON object
UPDATE your_table_name
SET metadata = '{}'
WHERE metadata IS NULL;

-- 2. Alter the table to set the default value and add the NOT NULL constraint
ALTER TABLE your_table_name
ALTER COLUMN metadata SET DEFAULT '{}',
ALTER COLUMN metadata SET NOT NULL;

The following tables have a metadata column:

• Poll
• Chore
• ChoreValue
• ChoreBreak
• ChoreProposal
• Heart
• HeartChallenge
• Thing
• ThingBuy

Use this to record when a buy is fulfilled

And figure out a nice way to render it

Closed with 5c59d7d

Don't require chores from before someone moves in.

I've done something and broken the messages event subscription, I need to fix it.

There's currently one production deployment, so clean up all the migrations manually before releasing version 0.1.0.

TODO:

• Add houseId to the ChoreValue table (see #39)
• Manually add missing houseId values to all tables
• Manually remove null and value constraints on ChoreClaim to allow for improved gifting (see #30)
• Consolidate interval update migrations into the main migrations and delete initial Heart migrations
• Update production migrations table to reflect new state
• Cross fingers

Allow residents to propose arbitrary purchases with a higher bar for approval and a longer voting window.

• Add frontend support to UI
• Update rendering of resolved Things to support special buys

Use https://api.slack.com/methods/conversations.invite

Also, I think parseThingsAdd and parseThingsDel can probably be removed.

"You sped up X and slowed down A, B, C"