-
Notifications
You must be signed in to change notification settings - Fork 9
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
Google Docs changelog channel #201
Comments
TBD: Handling suggestions? |
Ways this could goThis concept could (in theory, given adequate work, etc etc) mean any of 4 options:
For all combinations, there are of course varying levels of detail we might imagine viewing and varying degrees of aggregation we might desire / tolerate. I've tried to enumerate most of the useful points in this possibility space below. Reading snapshot information about doc contentThis feels useless so I haven't thought much about how hard it would be. Reading transitions on doc contentEasy: This difference is due to Google's Drive API making it easy to get attribution data (and some other little bits) but not easy to get either the actual content of the change at any particular revision. Brute force approaches like "download and parse both entire versions of the answer, and provide a diff between the versions" are possible, as plain-text exports of Docs are available for historic versions but this feels sorta tricky for small benefit, as the lack of context around a text change could often limit the utility anyway. Reading snapshot information about suggestionsEasy: Reading transitions on suggestionsThis seems like the most useful case so I've done a bit of digging. There are some challenges around this because I haven't yet found a way to get information about the creation of a suggestion, and attribution also seems difficult. This means even this simple-looking information seems difficult to get or derive: Thankfully though, I don't think that is exactly the kind of output we want anyway, and the data we have readily available is quite compatible with aggregations that preserve the information we do care about, like suggestion count and total size, so the following is actually quite easy to implement: The approach?So far it looks like doing anything with the actual document content is either (often both) tricky or useless so it looks like the most useful versions of this (and also coincidentally the easiest ones!) will provide insight into suggestions. Instantaneous snapshot views and state transitions both seem useful to look at, so I've outlined some ideas how these might work below. Streaming state transitions into Discord in real-ish timeWe can't easily do Actually Real Time:tm: streaming of suggestion notifications into Discord as there seems to be no way to subscribe to a streaming feed of suggestion events. But we can approximate this behaviour (latency of 0-10 minutes) as follows:
This also has the convenient side effect of reducing latency of getting new answer Doc content into Coda as well, which seems nice! User-prompted posting of info snapshots into Discord on demandWe could also make this sort of data interactive. Stampy the bot could query our questions API in Coda for something like, "which Docs have the most suggestions" or "which Docs have the largest combined word count across all their suggestions" and post appropriate responses into Discord. This behaviour might be triggered in a manner roughly similar to how we drop questions into Discord, where an editor could manually trigger it with something like "Hey Stampy, which answer Docs do we need to check out?" and Stampy could also periodically push an appropriate answer Doc into some editor channel. |
Update on this: We now have the current number of suggestions and the current total size of the markdown those suggestions would yield stored in Coda for the example question. It currently disregards the size of any suggested deletions, so deleting 200 bytes of text and replacing it with 150 bytes appears as a 150 byte change rather than 350. Deleting 200 bytes and replacing it with nothing would register as a 0 byte change so this is still incomplete, but it's relatively close. As soon as I have a Discord webhook URL that I can send messages to (this is going to become a blocker shortly @robertskmiles so if you can generate one or give Plex permission to do so, that would be A+), I'm going to start feeding what I have into the wiki-feed channel in Discord to see what happens. |
IMHO the most important notifications from GDocs are about new suggestions ("Suggestions were added to <title> , currently X open suggestions.") and when content loads into Coda after suggestions are approved ("New version of <title> loaded to Coda .") - perhaps no more details needed in notifications, but content diffs would be nice in Coda. |
@plexish Are you happy with the data we're seeing come through in #wiki-feed in Discord? If so we can probably close this as completed. |
Data looks good, but let's make the layout a little more conversational? Instead of
How about
|
oh, and does this note when people make direct edits to the Gdocs rather than suggestions @ChrisRimmer? Just prev length and new length would be pretty helpful, even if exact diffs are more hassle than it's worth. |
Pull diffs from each doc updated in the answers folder and subfolders every x minutes, put them into a Discord channel.
The text was updated successfully, but these errors were encountered: