Archiving Posts

[Samantha_O]

So we had a process of "archiving" posts that were over 1 year old within our Community.  Our process was to go board by board, find any post that was created over a year ago, post a new reply to the thread with a message stating "the thread was archived, but saved for education purposes and to create a new post if they need help," and blocking new replies.

We stopped this process because we thought that there should probably be a little more going into what gets archived besides just the date on the post.  So I wanted to get some thoughts on this.  I saw this post, and while there is some great information there, it does not seem like the right fit for our Community and the posts that we have.  We also are currently not deleteing any posts, just commenting & blocking new replies. 

How do you archive within your Community?  Do you have a specific Archive board?  How do you determine what gets archived and what does not? 

Thanks in advance

[JasonHill]

Hi @Samantha_O

Manual archiving is a huge amount of work. I could never justify that time spent archiving when it could be put towards helping existing users. As you mention, even if you are archiving everything it is a very labourious process. And if you are trying to assess every post and make a judgement call about whether it should be closed or not, that it even more work. 

At my previous community, we got a third party developer to create a simple system in which posts created more than xx days ago are automatically closed to new comments. It's something that the Lithium platform should definately offer. You can see an example here - http://community.myob.com/t5/Getting-started-with/MYOB-Accounting-Plus-we-need-to-purchase-new-softw...

Basically we were just hiding the Reply buttons and putting a message at the top of the thread that says "This thread is now archived and closed to new comments. If you have a question please post a new topic." The change was very positively received. We received no negative feedback following its introduction. We have had the auto-archive set at 6 months to be conversative but I think 3 months for a vibrant support community would be fine.

I think search should play a big role here. If Community Managers could set the timeframe for how far back search produces results, then the need for archiving is reduced or even eliminated. Search would provide always relevant and recent results. You can add your thoughts on this post - http://community.lithium.com/t5/Product-Ideas/Limit-search-timeframe-to-eliminate-archiving/idi-p/20...

Good luck,

Jason

[Samantha_O]

Thank you for the response Jason!

[allisonn]

It's very disappointing Lithium doesn't have a better way to archive posts. I know it's come up several times in the Product Ideas. I agree, it isn't worth the manual effort if you have a large community, but if we see a reply on a really old post, we sometimes reach out to the user and ask them to repost or move it ourselves.

[allisonn]

@JasonHill was the old community on Lithium or a different platform?

[JasonHill]

It was a Lithium community @allisonn.

See above for a link to an old example post that has been closed for comments.

Jason

[allisonn]

Thanks... I read this too early in the morning 🙂

[Wendy_S]

some great related discussions might be here too. Our superduper Jason is part of that thread too
http://community.lithium.com/t5/Strategy-and-Best-Practices/What-s-your-process-for-locking-threads/...

[Wendy_S]

By the way, we never ended up doing manual locking (or archiving) as we did not have the magic formula either and their are so many pro's and con's to doing this. We did search for very old unanswered threads (plus 1 year topics with no response) and we cleaned them up (moved into an archive board) as we figured these would not get a response anymore and if they do, it's really too late to the game. We now have a response rate of over 95% so the likelyhood of topics getting a response has grown tremendously in our past year(s)

[Gina]

For one of my previous communities, we archived the customer service section about every 90 days.  While other sections in the community were more product focused and therefore had long-term benefit, we found that the customer service issues were too individual customer specific.  We extracted any good customer service solutions and used that as the basis to author TKB articles.

[VF_MikeHales]

Looking to ape the archiving by too old+no reply but is there a way to hack the search query string to exclude certain boards - my results are pulling all content from archived boards!

[Wendy_S]

Our developer build a component that allows us to archive topics that have not seen activity in a specified date range, board by board.

@fuenteso. Can you help Mike out a bit?

[Samantha_O]

Anything that you can share would be appreciated, @fuenteso!  The archive tool that you built is really interesting and in my opinion, really crucial to Communities. While we wait to see if Lithium will make a standard Community solution, any way to make this process easier is going to be helpful!

[VF_MikeHales]

That would be great. Manual process is killing me! Still Spotify is getting a good workout

[fuenteso]

Hi,

Sure. It's a two part tool; we have a custom component on each of the category/board pages visible only to admins/mods where they can select a time range (two simple form date fields), the board we want to 'clean' and the destination board (or archive board). Additionally we added a few options in the form of checkboxes to archived only solved threads, or archive them by original post date instead of conversation.last_post_date.

This component then calls an endpoint and send all this information as parameters. This endpoint uses an API v2 call to pull the threads

SELECT count(*) FROM messages WHERE conversation.last_post_time <= ${endDate} AND conversation.last_post_time > ${startDate} AND depth = 0 AND board.id='${board}'

Then loop through the list and move each thread individually. We add a couple of tags to preserve the original board id and mark the thread as Archived.

<#assign apiResults = rest('/messages/id/${post.id}/tagging/tags/add?tag.add=Archived') />
<#assign apiResults = rest('/messages/id/${post.id}/tagging/tags/add?tag.add=source-board-id:${post.board.id}') />
<#assign apiResults = rest('/messages/id/${post.id}/move/board/id/${moveTo}?move_message.include_replies=true&move_message.ignore_notification=true') />

It might be a good idea to pull the threads in batches. For example we're processing 100 threads at a time (getting the total number of threads in scope, dividing it by 100 and then use that "page" number with OFFSET to )

<#assign resultPages = (postCount/queryLimit)?int+1 /> 
<#list 0..resultPages as page>
<#assign postsToArchive = rest(apiVersion, "/search?q=" + "SELECT id, board, conversation, view_href, metrics, post_time FROM messages WHERE conversation.last_post_time <= ${endDate} AND conversation.last_post_time > ${startDate} AND depth = 0 AND board.id='${board}'${notSolvedQuery} ORDER BY conversation.last_post_time DESC LIMIT ${queryLimit} OFFSET ${page*queryLimit}"?url).data.items />
...
<#/list>

I also added an extra step to make sure the post's conversation.last_post_time fell into the specified date range. I think there was a bug on the API call that was returning threads that didn't meet the contraints.

Finally, the endpoint returns a JSON with useful information, like the IDs of all the threads that were moved. You can choose to create a report with this information or just ignore it.

Hope that helps, let me know if you have any questions.

[VF_MikeHales]

This looks awesome, I've not got this deep into the code before, so please excuse my ignorant questions.
First block is an endpoint?
Next 2 blocks are new components I create and then drop into pages?

[fuenteso]

Hi @VF_MikeHales

Not exactly, that's like a general description of how it works.

I can share with you the actual code but since it was built specifically for our community it needs a certain degree of personalization for it to work on a different environment (archive board structure, board names, roles, styling, etc). 

[VF_MikeHales]

That would be awesome and if you could mark the site-specific parts that would be great. Have managed to batch process my entire community down to one year but anything that can help automate in the future would be super cool.
Thanks again

[Samantha_O]

@fuenteso, if the offer is an open one, would you mind sharing this with me, too?  I'm happy to send along my email address if that is easiest for you. 

Thanks! 

[Wendy_S]

I think @fuenteso deserves an extra call out this month 😉

[fuenteso]

I can try to point the easy changes (like board or role names) but I can't know exactly what parts will need to be modified to fit your community structure.

For example, the component has a drop down to pick the destination board. In our English community all the archive boards are on the same Category, so the component requires that Category ID to pull the board's names and ID to set the destination for the archived threads. Our non English communities decided they wanted to have the archive boards inside their corresponding product boards, so I had to modify some parts of the component to make it happen.

Like I said, I'm happy to share the components but unfortunately I can't guarantee they will work on your communities "out of the box". 

I'll attach the components and a brief explanation on my next reply.

Cheers!

[fuenteso]

Hi everyone!

Here are the components. 

archive-threads.ftl: Is the custom component used on the Category/Board pages, this is the one that we added to our quilts.

archive-endpoint.ftl: Is the endpoint that archives posts based on conversation.last_post_date. 

archive-endpoint-post-date.ftl: This is a slightly modified version of the endpoint to have to option to archive posts by original post date, not conversation.last_post_date. 

text-keys.txt: Text keys used on the component.

This is the UI the Admin/Mod sees on the page. They have to select a range of dates, source board (if it's on a Category page) and destination board. We also have a few optional fields there:

When you click "Archive" the endpoint starts processing the request and it will return a small report containing the request details and which threads were moved. The custom component uses Javascript to translate this report into a readable format and display it on a new window.

In our experience, due to endpoint timeouts, it's better to archive threads in small batches, otherwise you will get a timeout error (warning: some threads might have been archived even if you see this error). You can run the tool without checking "Move posts" to see if the batch is small enough before actually doing any archiving.

Hope that helps!

[JasonHill]

Awesome work @fuenteso. Many thanks for sharing with everyone.

Jason