Feature request: Suggestion improvements (whitelisting, digests, reminders)

Use case:
I have several active suggestions (all fixes for errors) I made weeks (some even months) ago, which haven’t been merged yet. In almost all cases the authors of the targeted notebooks haven’t been active for a while, or may not even use Observable anymore.

I’m struggling to find a good way to deal with these suggestions. I could:

  1. just leave them, which clutters my suggestions list and requires me to keep the associated notebooks around.
  2. delete them, which makes the initial effort pointless and prevents the author (should they ever return) from ever merging them.

Both options are not great. I’d like to suggest a third option, consisting of multiple improvements, that might also help to increase overall engagement.

These changes target two primary goals:

  1. Allow authors to communicate more clearly how they will handle suggestions.
  2. Allow contributors to see wether suggestions for an author’s notebooks will have a chance of being reviewed.

Suggested changes:

  1. Allow users to configure wether they want to receive suggestions:
    • always
    • not from blacklisted users (to avoid suggestion spam; textarea, one username per line?)
    • only from whitelisted users (or team; textarea, one username per line?)
    • never
  2. When changing the option, automatically close affected open suggestions.
  3. When a user cannot create suggestions for a notebook, disable the “Suggest” option with a hint text (“Author has disabled suggestions”).
  4. Send out an email digest for received suggestions that are still open approx. 1-2 months after a user’s last login.
  5. Send an email reminder for every received suggestion that is still open and past a certain age (e.g. 3 months), add option to close suggestion from within the mail:
    • close only this suggestion
    • disable suggestions from this user
    • disable all suggestions
1 Like

By the way, I’m also interested in dissenting opinions:

  • If you see the use case as a non-issue: Which strategies do you currently employ? Or do you have a different point of view on the issue that you can share?
  • If you consider the changes as counter-productive: What problems do you see? Are there alternatives that you’d like to propose?
1 Like

If someone doesn’t like (or never looks at) your suggestion you could always publish a fork of the notebook. Viewers of the original notebook can at least see that there has been a fork.

Personally I can’t imagine wanting auto-merging of suggestions. YMMV.

clutters my suggestions list

This seems like a problem best tackled with UI improvements for browsing your own notebooks and filtering out stuff you don‘t care about, rather than with workarounds to make deleting them happen more often.

For what it’s worth, I’m not the biggest fan of the current ephemeral behavior of suggestion conversations, where as soon as the suggestion is cleared the whole conversation disappears. It makes me hesitate to put anything very important in those conversations, in case I might ever want to find it again.

Perhaps instead of clearing conversations and encouraging authors to delete suggestion notebooks to reduce clutter, it might be better to have some kind of way to archive those (or other) notebooks so that they can still exist but not show up in the standard lists of someone’s own notebooks.

1 Like

I didn’t suggest that. Can you tell me which part gave you the idea so that I can rephrase it?

What do you mean by “accept suggestions”?

Are you having trouble with suggestion spam?

Reworded “accept” to “receive”.

No, but any solution should include the possibility that some users may abuse the suggestions feature, or that suggestions by some users are consistently of low quality, or that an author doesn’t really care about dealing with suggestions at all.
By performing a prefiltering and disabling the menu option accordingly a user can immediately determine if their suggestion has a chance of being reviewed, thus potentially sparing both parties some frustrations. Added a “goals” paragraph to the topic.

I’m doubtful that your suggestions aren’t getting looked at because the author never wants to receive suggestions (or has anything against you personally). I doubt this pre-filter would get used all that much, and I don’t think it’s worthwhile for the team here to prioritize implementing this type of thing. Dunno.

More likely they are just busy or didn’t notice. Sort of like unsolicited emails that don’t get replies.

That’s what the changes in 4. and 5. are meant for. Currently a new suggestion triggers a single mail which is extremely barebones and doesn’t even mention ObservableHQ explicitely.

There are many authors who haven’t created or updated notebooks for months. Their reasons may vary widely (platform didn’t satisfy needs, not enough user feedback, changed tools/professions, simply forgot about observable).
By sending out reminders (which wouldn’t be unsolicited because 1. you’ve actively engaged on the platform before and 2. you would of course be able to disable them) in large intervals (and with branding - *hint* *hint*) the recipient may see that people engage with, and contribute to, their content, which might be incentive enough to pick observablehq up again as a tool and platform.

I mean unsolicited in the same way as reading someone’s personal webpage, finding a typo on it, noticing they have written their email address there, and sending them a message about the typo. By listing their email address they have nominally encouraged people to write to them. But that doesn’t mean that your particular email was solicited.

Even if the person cares about typos and has the best intentions, any particular email has a good chance of slipping through the cracks. People are busy, put things off and never get back to them, …

Changing suggestion emails to be clearer and more explicit might be a good idea. It’s possible that sendgrid isn’t the best tool for producing these kinds of emails; I am not at all an expert in this kind of thing.

If you want to poke the recipient of your suggestion, you can post a new comment on the suggestion and Observable will send an email notifying the recipient and including the text of your comment. (Personally, I don’t want automated reminders of open suggestions, just as I don’t want automated reminders of open issues or pull requests on GitHub. It would quickly be overwhelming!)

If you don’t like having the open suggestions around, you can close them. A closed suggestion is still mergeable, though it’s much more likely that the recipient of the suggestion won’t notice your closed suggestion.

And unfortunately, at the moment closing a suggestion means the recipient can no longer see any comments on the suggestion, though they can at least see the suggestion description. When we get around to redesigning the comment workflow, this is something we’d like to fix. (We hear you, @jrus!) We’d also like people to be able to comment directly on notebooks without needing to go through the suggestion flow, which is a bit heavyweight for brief discussions.

I also like the idea of archiving notebooks so they’re hidden (by default) from your notebook listings, but are still accessible. Possibly we could also do something smarter with forks, though it’s hard to tell when a notebook is forked whether the intent is to make a small change or to take that notebook off in a completely new direction.


One other thing that might make a difference in some cases is some ability to make a public suggestion with discussion visible to anyone (or possibly even open to public comment). At least the suggester wouldn’t be worried about “I just spent an hour fixing this bug and now nobody will ever see the fix” (or whatever), and the author might have a slight reputational incentive to respond.

I have appreciated reading the discussion here, but I can’t speak much to the main post since I personally haven’t minded keeping my suggestions open and the related old notebooks around.

I did this a few times before suggestions were implemented and I remember wishing I saw more of this happening so I didn’t feel so strange publishing trivial forks of other people’s content. I do strongly believe that making fixes public is the “right” thing to do, but this has also contributed to some clutter in my notebooks which is starting to get out of control. The archiving idea sounds nice, but I would also like to see some more notebook filtering options, e.g. a way to find / display only my notebooks which I haven’t assigned to a collection.

Thanks for the feedback, everyone! I’m going to mark this topic as solved, because the team has, at multiple times, hinted that they’re aware of the various issues surrounding suggestions (including the email problem) and are actively working towards a solution.
However, I’d like to keep the discussion going by sharing more aspects of the problem as well as my current workaround.

Additional aspects

Since this topic was created I’ve also raised issues regarding a lack of email branding and notifcations options. There are no UI hints either (no badges or highlights on the suggestion link, no entries in the activity feed), which means: Once you opt out of suggestion mails you essentially go blind.
It would be interesting to see if the number of open suggestions is larger on average for active users that have unsubscribed.


I’ve taken up @jrus’ and @bgchen’ advice and republished the forks. Both the intention and changes must be easy to spot, so I’ve come up with the following process:

I’ve created a public Suggestions collection that acts as label and filter. The steps for each fork are:

  1. Open the suggestion’s compare view in a new tab.
    We’ll need the COMPARE_URL and SUGGESTION_TITLE.
  2. Open the original notebook in a new tab.
    We’ll need the NOTEBOOK_SLUG later on.
  3. Edit the fork, and inject the following code into a new cell before the first cell (replacing the all-caps placeholders):
    html`<h1 style=display:none>suggestions:NOTEBOOK_SLUG</h1>
    This will prevent the fork from polluting our own slug namespace and provide a direct diff link and change description. It also provides a commentary that can be skipped easily by the original author should they still wish to merge.
  4. Add the fork to your Suggestions collection and publish.
    Note that published changes will alter the suggestion. Warning: Don’t unpublish, or you’ll have to restore and reshare the original changes!
  5. (Optional) Close suggestion.

Comments are, of course, lost when a suggestion is closed. If you want to keep them alive, you can inject cells with the following template to mimic comment styles:

html`<div style="white-space:pre-wrap;background:#fbf9f1;font:.875rem/1.25rem var(--sans-serif);padding:.5rem 1rem;max-width:640px">COMMENT_TEXT