Skip to content
New issue

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

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

Already on GitHub? # to your account

Feature request: show change history in a time series somewhere #27

Open
zarvox opened this issue Jun 22, 2016 · 2 comments
Open

Feature request: show change history in a time series somewhere #27

zarvox opened this issue Jun 22, 2016 · 2 comments

Comments

@zarvox
Copy link

zarvox commented Jun 22, 2016

Related to #18, in a sense.

When collaborating with others, I often find I'm interested in looking at all the comments that have been added since I last checked. Today, that requires that I go through every annotation point, open up the comments, and see if there's anything new. As the number of annotation points grow, this becomes more and more burdensome to poll.

It'd be really helpful if there were a time-series feed of changes somewhere, where I could see when comments were added, and easily get back to the context of the conversation they apply to.

Another thing that would help with the "re-review" workflow is if new comments or other changes triggered notification of some sort, but that is more-or-less blocked on sandstorm-io/sandstorm#1889.

@simonv3
Copy link
Owner

simonv3 commented Jun 22, 2016

👍 yeah that makes a lot of sense to me.

I haven't had a lot of time to put into annotate recently, and probably not in the near future, so if anyone wants to take this on, it should be fairly straightforward!

I'm definitely open to other ideas, but does a "feed" object that gets created whenever someone adds or updates something on the db make sense? That way you could track on the user up to what feedId he's been notified of (I don't think we need to track whether the user has read each individual object).

@zarvox
Copy link
Author

zarvox commented Jun 23, 2016

I'm definitely open to other ideas, but does a "feed" object that gets created whenever someone adds or updates something on the db make sense? That way you could track on the user up to what feedId he's been notified of (I don't think we need to track whether the user has read each individual object).

The "feed" as you describe it sounds like a reasonable data structure for recording/publishing an event log to the UI for self-driven review of whether things have changed or not.

If the design were up to me, and implementation effort was no object, then if I were going to go to the trouble of tracking whether you've seen comments before or not, I'd track "read" states at the per-discussion-thread granularity, so I'd probably store a (user, thread ID, last seen comment ID) tuple. Rationale: If the challenge is in finding "what things haven't I looked at yet?" then I don't want the order I review things in to accidentally mark something I haven't seen as "read". I am likely to review all of the comments in a thread together, but may or may not finish looking at all changes in a single session, and would prefer not to lose them when I come back.

That said, I think you get at least half the value from just having the changelog in order somewhere, and I can scroll down to the last thing that looks familiar, and read the rest from there. :)

Thanks!

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants