Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Autosubscribe users to their pages' discussions #77

Open
rossjrw opened this issue Aug 7, 2023 · 1 comment
Open

Autosubscribe users to their pages' discussions #77

rossjrw opened this issue Aug 7, 2023 · 1 comment
Labels
feature A new feature

Comments

@rossjrw
Copy link
Member

rossjrw commented Aug 7, 2023

The frontmatter of a thread, if the thread is a page discussion, contains the slug of the page that it discusses. This is the only available information about the page.

From this, I can in theory track the page and who created that page, and autosubscribe that user to it if they're not already. This is easier said than done for several reasons:

  • There are several Wikidot calls in between me and the author information.
  • Several of the wikis that use the notification service have attribution metadata that is entirely external, and not consistent between wikis.

It doesn't make much sense to reinvent the wheel here (like I have before... rossjrw/tars#170 rossjrw/tars#221).

If I ask SMLT nicely I might be able to use Crom as a centralised source of attribution data. The wikis that Crom covers broadly overlaps with the wikis that notifier covers.

I will need to bear in mind the following...

  • Attribution metadata can change over time. How will I keep my internal records as up-to-date as they need to be while minimising load on Crom?
  • Should I be recording attribution metadata in my database at all?
  • What happens if attribution metadata changes, but I don't refresh my cache in time, and the wrong person gets notified?
    • In theory the right person would be notified once the cache refreshes, because I track whether someone has been notified about a post per user rather than per post. BUT that wouldn't happen if they were notified in the meantime, because I only track the date of the most recent post they were notified about, and assume they were already notified about anything posted before then.
  • I could reduce load generally by only handling author stuff, say, in a cleanup task that runs daily. Effectively these new autosubscriptions would be run at daily intervals. Hourly users wouldn't receive these notifications for 23 of 24 runs, 8hourly users for 2 of 3 runs, and daily+ users would be unaffected.
    • This will be really hard to document in a way that makes sense to users.
    • I also just flat out don't like it. I want each run of each channel to be the same.

I will need to discuss with SMLT the best ways of doing these things.

@rossjrw
Copy link
Member Author

rossjrw commented Feb 11, 2024

Had a thought following a PM from a user: users are currently autosubscribed to threads they have the first post in. If this issue is implemented, should this still be the case for discussion threads?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature A new feature
Projects
None yet
Development

No branches or pull requests

1 participant