Invstigate subtree-watching needs

RESOLVED FIXED

Status

RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: jbennett, Assigned: jbennett)

Tracking

Details

(Whiteboard: [specification][type:bug])

(Assignee)

Description

5 years ago
What did you do?
================
Before trying to implement it, we need to do some time-boxed investigation of whether it's worth doing subtree-watching as a standalone thing, or waiting for a more general notification system to be in place.

Specific questions that need answering:

1. How to differentiate "watch this page" from "watch this and all its subpages".

2. What happens when I unwatch a subpage -- does it pull that subpage and its subpages off my watch list?

3. Notifying when a new page is added to the watched tree.

4. Notifying when a page is removed from the watched tree.

5. Handling frequency of notifications sensibly (perhaps a once-a-day thing) so as not to overwhelm people during spam attacks.

If any of these -- though especially (5) -- seem like we'd just end up rewriting the whole thing when a real notification system lands, we should hold off on subtree watching until then.

What happened?
==============
N/A

What should have happened?
==========================
N/A

Is there anything else we should know?
======================================
(Assignee)

Updated

5 years ago
Blocks: 842340
Some thoughts (if not answers)...

> 1. How to differentiate "watch this page" from "watch this and all its
> subpages".

I'd assumed we'd have separate options in the menu for each, but maybe that's not the best way. For that matter, maybe we want buttons rather than menu options, to make the feature more discoverable. These are interesting questions and I'm not sure of the answer...

> 2. What happens when I unwatch a subpage -- does it pull that subpage and
> its subpages off my watch list?

This one is a weird one. We may have to resort to popping up a box asking what to do here... but if you unwatch a subtree (or a page in a subtree) that complicates dealing with the rest of the tree.

> 3. Notifying when a new page is added to the watched tree.
> 4. Notifying when a page is removed from the watched tree.

Both important points. These are obviously key events. Also need to be sure that new pages in the subtree are considered part of the subtree (that is, we track by tree, not by the pages in the tree, which are in the list of pages the user is watching).

> 5. Handling frequency of notifications sensibly (perhaps a once-a-day thing)
> so as not to overwhelm people during spam attacks.

Eventually this needs user preferences so they can set how often they want to be notified; I can see someone wanting immediate notifications if they're urgently waiting for a revision to come in, but typically they will want daily or weekly batches.

> If any of these -- though especially (5) -- seem like we'd just end up
> rewriting the whole thing when a real notification system lands, we should
> hold off on subtree watching until then.

Rather than "hold off on subtree watching," I would say "focus on the notification system", since subtree watching is pretty important.
(Assignee)

Updated

5 years ago
Assignee: nobody → jbennett
(Assignee)

Comment 2

5 years ago
So, after spending a couple hours poking around in the existing notification code, I think (5) above is really a blocker; what we have now has some of the features we want, but when we do notifications "for real", we're just going to end up rewriting whatever one-off stuff we try to do right now without it.

So I'm going to suggest we take sheppy's comment above, and focus on the notification system and getting it to be a bit more flexible and generic, and then maybe subtree watching can be the first test of that.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.