This is Part of https://github.com/publiclab/plots2/issues/8513
When a wiki is added or edited or when a comment is added bump up the topic card. Only display the name of the wiki in the list and not any kind of individual edit tracking.
Refer To https://github.com/publiclab/plots2/pull/8935#issuecomment-755508002
Look into re-using @activity from the previous dashboard method
Hi @ebarry and @jywarren 😄
For this issue, currently, we have no specific order in which the topics are displayed on the dashboard. I am assuming, it should be according to the most recently updated based on this issue's requirement...
Research notes are different from wikis and if comments and wikis bump up a topic, should research notes also bump up a topic as well?
Also, currently, we post the 3 most recent notes on the topic card and this issue recommends adding the name of a wiki that has been edited on the topic card. Should it come after the 3 notes listed?
The comments should also bump up a topic according to this issue, should comments be posted within the topic card as well?
This would mean that the topic card might contain wikis and comments in addition to the notes...
Attaching a topic card to see how it currently looks on the site..
Hi, i think this may be a pretty complex issue, because wikis, notes, and comments all may have different ideal sorting, and so a query incorporating them all may be challenging. But let's slowly work through ideas without letting it block other tasks!
My thoughts are currently:
These may be feasible to solve with only 5 or so topics, but let's keep in mind some people may have dozens of followed topics, making the query potentially inefficient.
Let's start by sharing thoughts and ideas on this before diving too deep into a specific problem solving path. What do folks think on these challenges and questions?
Thanks for sharing your thoughts on the issue @jywarren I'll reread the points you've shared to understand... and comment on my thoughts as well...
I think this is also a good time to plug in this issue..where we are removing empty topics on the screen https://github.com/publiclab/plots2/issues/8964 I think it also relates to the discussion happening here....
Great breakdown of these issues! Glad to speak about these slowly and carefully while letting other work advance.
Comment activity has become central to community life on publiclab.org. Comment activity is where the largest number of people interact with each other. Notes that may gain high readership but do not spur activity in the comments have less interaction in my book. As a result, comments are where staff (at least the ones who have dedicated time to support community emergence) focus their energies; to add support, staff will join the conversation in the comments. I think the point can be argued that comment activity in a topic is equal in relevance if not greater in relevance to a new note being posted as evidence that "a topic is active." We can recall that topics being active is the core concept of ordering topics on the dashboard. For these reasons i suggest that it will be worth figuring out (across databases) how comments can also order topics by activity on the dashboard.
Hi, i think this may be a pretty complex issue, because wikis, notes, and comments all may have different ideal sorting, and so a query incorporating them all may be challenging. But let's slowly work through ideas without letting it block other tasks!
My thoughts are currently:
- topics are currently by most recent note created timestamp, i believe
- adding most recent wiki update (not published/created) could bump it up but a) how do we create a combined query with 2 different sort params and b) would people be confused to see a bumped up topic with no visible new content on it?
- comments introduce another layer of complexity too - i assume it'd be by comment creation timestamp, but it is a different database entirely, so mixing them in may be tough.
These may be feasible to solve with only 5 or so topics, but let's keep in mind some people may have dozens of followed topics, making the query potentially inefficient.
Let's start by sharing thoughts and ideas on this before diving too deep into a specific problem solving path. What do folks think on these challenges and questions?
Hi @jywarren ...just got done rereading the notes you shared...
For this topics are currently by most recent note created timestamp, i believe
...I am not sure if this is the case, because we currently use the current_user.subscriptions.include(:tag)
to display the list of topics on the dashboard...and I checked the new_note
method in the node.rb file, it does not update a tag or tag_subscription when a new note is created...I thing the order of the tags on the new dashboard has not been specified..unless I am wrong...
Hi @jywarren, I checked whether the topic cards are displayed according to the most recently updated, and discovered that they are not.
I created a new research note within the test tag and when I reloaded the page, it was not at the top of the list.
Before
Notes Creation
After
However, it's great that the notes within the topic cards are ordered according to the most recent.
I have been thinking of a way in which we can:
:tag
@pagy, @tag_subscriptions = pagy(current_user.subscriptions(:tag).includes(:tag).where.not(tid: exclude_tids))
updated
column within the tag model, instead, we could create a whole new column node_update
that can store a hash which can also be natively created using MySQL as JSON within the tag model and orderednode_update
which contains thenode
and type
node_update{date: 01/01/21, type: comment}Tag.find_nodes_by_type(subscription.tag.name, type = 'note', limit = 3).where.not(nid: shown_nids)
Tag.find_nodes_by_type(subscription.tag.name, type = subscription.tag.node_update[:type], limit = 3).where.not(nid: shown_nids)
The problem with this approach would be keeping track of the shown_nids...since different tags display different notes, comments, and wiki IDs...but if we consider that whenever a node is updated or created, we update the node_update column within each tag that the node has been modified, this might not be an issue since both/several tags would have the same node_type to display...
Or the shown_nids could store hashes of the node ids of different type that way, the query becomes..
Tag.find_nodes_by_type(subscription.tag.name, type = 'note', limit = 3).where.not(nid: shown_nids[subscription.tag.node_update[:type]])
where shown_nids looks like this...
shown_nids{wikis: [1, 3, 4...n], notes: [8, 9 , 7], comments: [8, 9, 7]}
Let me know what you think @jywarren and I'll keep sharing my thoughts as I think about this...
Reading through this now, thanks @RuthNjeri !!!
@ebarry @RuthNjeri i'm thinking on the way the tag cards will try to display most recent updated content, and had an idea -- what if a small "new" badge appears next to the "2 notes | 5 wikis" bottom-left items corresponding to what was the new content? We could do a couple small queries to check, perhaps a Tag method called most_recent_activity_type. Would something like this work for community reps, @lizbarry?
It's a bit odd to count all comments, though; could we say 2 notes | 5 wikis | • new comment (bullet is the badge in this example) and only show that 3rd item if it is comments driving this?
and if not, @lizbarry would you want to /not/ show a list of notes on a topic if it is a wiki which drove it to the top?
So Ruth, I guess I'm warming up to your idea of tracking the exact item that caused the Tag timestamp to get updated. I had thought maybe we could approach the idea more slowly but since there's been added emphasis on including comments, perhaps we'd better seriously consider this. I wonder if you added a second column to Tag
alongside the new timestamp in #9165, for a pointer to the exact record. We could make it a string, and have 12345
indicate a node id, while c12345
would be a comment id. Although with wikis we are tracking revisions, we can still point to the wiki itself using just an nid.
What do you think of this as a variation on your hash idea?
@jywarren that sounds like a great idea...it's pretty straightforward..we'll see how it looks and performs after the implementation.
This has been completed in #9165 and #9203
Most helpful comment
So Ruth, I guess I'm warming up to your idea of tracking the exact item that caused the Tag timestamp to get updated. I had thought maybe we could approach the idea more slowly but since there's been added emphasis on including comments, perhaps we'd better seriously consider this. I wonder if you added a second column to
Tag
alongside the new timestamp in #9165, for a pointer to the exact record. We could make it a string, and have12345
indicate a node id, whilec12345
would be a comment id. Although with wikis we are tracking revisions, we can still point to the wiki itself using just an nid.What do you think of this as a variation on your hash idea?