Closed Bug 680924 Opened 13 years ago Closed 12 years ago

Auto-lock threads in the support forum (questions) after some time

Categories

(support.mozilla.org :: Questions, task, P2)

Product:
support.mozilla.org
Component:
Questions
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
2012.12

People

(Reporter: cww, Assigned: willkg)

References

Details

(Whiteboard: u=contributor c=questions p=1) 

https://support.mozilla.com/en-US/forums/contributors/707526

I'd like to lock threads when they match all of the below conditions:

* >180 days after when it was asked
* No answers in the past 60 days
* < 5 "I have this problem too" votes in the past 30 days

Threads should be unlockable by the OP (if possible) and moderators (which is already the case).  Numbers should be easily tweakable.

IDEALLY display a message at the top: "This thread is out of date and possibly not relevant. Please [search for a newer one] or [ask a new question]."
(In reply to [:Cww] from comment #0)
> Threads should be unlockable by the OP (if possible) and moderators (which
> is already the case).  Numbers should be easily tweakable.

Whoa, questions here.

* Once it's unlocked, it'll just get locked again, unless we change what "locked" means in general, or there's some activity from the 2nd two conditions.
* Define "tweakable". If you "tweak" them do you want us to go unlock all the threads that have already been automatically locked? This would make me sad.

> IDEALLY display a message at the top: "This thread is out of date and
> possibly not relevant. Please [search for a newer one] or [ask a new
> question]."

This is something we _may_ be able to do. Lock is currently a boolean value, which is a very small integer in the questions table, possibly 1 bit. Making a schema change to that table would be very time consuming, and would likely require significant downtime (i.e. more than a few minutes) at least for questions (assuming we could find a way to not take down all the slaves with the schema change) or read-only mode for a while.

Life with RDBMSes.
>Once it's unlocked, it'll just get locked again, unless we change what "locked" means in general, or there's some activity from the 2nd two conditions.

I imagine that if a thread is unlocked, that the unlocking person should post something (which would register as an answer).  A red bar that says "Note: please comment in this thread to prevent it from being archived again in 12 hours" would suffice (although frankly, I don't care for the first implementation).

>Define "tweakable". If you "tweak" them do you want us to go unlock all the threads that have already been automatically locked? This would make me sad.

And please do NOT go back and unlock threads, that's just confusing.  I definitely meant tweaking for the future.

>Lock is currently a boolean value, which is a very small integer in the questions table, possibly 1 bit.

is_locked is actually a tinyint.  So I guess I'm asking for a second status (2?) that means "archive" and then the corresponding UI if that condition is met.  If I'm wrong about that, feel free to drop this feature (or we can discuss it for future).  Of course, we COULD add an additional column.... (Mostly kidding.)
Regarding the status, to make it even more simple, we could merge the copy about "Obsolete thread + ask a question here" with the actual locked thread copy.

The proposed solution in Comment 2 is cleaner but adds complexity that we may skip.
Putting this on the radar for 2012.5
Priority: -- → P2
Whiteboard: u=contributor c=questions s=2012.5 p=
No problems going on in this one but:

- The other bug was defined with the original creator of this bug (CWW)
- The other bug is part of a more comprehensive strategy around old threads. See this: https://etherpad.mozilla.org/WgW19nnCKM and this: https://etherpad.mozilla.org/WgW19nnCKM
- The conditions for this bug needs to be tweaked to fit into the strategy.
- Initial input from UX (Crystal) was received while drafting this approach.
- This bugs affects to answered and no answered threads and now we are proposing a more granular approach.

The most important thing is to get it done anyway.
Whiteboard: u=contributor c=questions s=2012.5 p= → u=contributor c=questions s= p=
(In reply to Ibai from comment #6)
? Typo identical links
> See this: https://etherpad.mozilla.org/WgW19nnCKM and this:
> https://etherpad.mozilla.org/WgW19nnCKM

> The most important thing is to get it done anyway.
OS: Mac OS X → All
Hardware: x86 → All
I'm not sure why has this fall through the cracks but I'm adding it to the next sprint bucket to start the conversation again.
Target Milestone: --- → 2012.12
Assumption:
We are going to write a cron job that goes over all unlocked questions over 180 days old and locks them.

1pt
Whiteboard: u=contributor c=questions s= p= → u=contributor c=questions p=1
Hi!

Do this mean that we are not checking if they have additional activity? (votes, answers, etc).

While I have no problems with it (it's based on the chart I put together with Cww https://docs.google.com/spreadsheet/ccc?key=0Ap1xJcDYQ9zjdHBRSnQzdGxSOV9MT1RhR1R6TGxJU0E#gid=0), he had some concerns about locking threads with recent activity. (https://etherpad.mozilla.org/WgW19nnCKM)
(In reply to :ibai from comment #11)
I am okay with adding more conditions to locking. I just wanted to eliminate the complexity of allowing moderators to force them to unlocked as it creates a third state that we don't have (unlocked, locked, and REALLY unlocked - please don't auto lock me again). They can unlock and create some activity (based on the conditions we choose) so that it doesn't get automatically locked again though.

Makes sense?
Right now we don't have a condition whereby an older (but still relevant) thread can be kept alive by activity. This could be a concern, I guess but the solution definitely isn't "have a super-unlocked mode"

In a future revision, based on feedback, I think we should have a rule like "never lock a thread that has new posts (votes don't count) in the last month", lock everything started over 6 months ago. For now, the 6 month rule should be fine.
Grabbing this one. When there's a consensus on what to implement, I'll go do it.
Assignee: nobody → willkg
Will, we should be good to go with Ricky's assumption. The original requesters (cww and myself) agree that is a good first step.

Thanks!!
Sorry if I wasn't clear: Let's do the lock everything started over 6 months ago. From comment 10, it sounds like it's just a cron job so we can modify it with more criteria on what to lock and not-lock in the future.
Will, just to be sure: The threads should be closed, but they should still show up in the search results.

In that regard these threads are different than the questions with no answers. Showing them in search results made no sense, but here it does make sense.
The same of course for the robot.txt file, these questions should be found by search engines.
Per https://support.mozilla.org/forums/contributors/708453#post-47403, we probably want to make sure that locking the question doesn't update the "updated" field so that it doesn't get bumped to the top of /questions. Is this acceptable? We won't know when it was locked.

Otherwise, we should change the default to sort by posted date instead of updated date.
It's acceptable. As commented in the thread, if they are properly locked, I don't see any usecase where knowing when was locked is relevant.

This is similar to this: https://bugzilla.mozilla.org/show_bug.cgi?id=701385
Thanks Ricky! I was right about to bring up my comment here as I was scared you guys were gonna overlook it.

I believe it doesn't matter when a thread was locked. If the thread was created in 2010 thru December 2011. I really do not care when that thread was locked at all. We can always go by the last post in the thread as to when that topic was last accessed.

For more recent threads, it may be worth knowing when it was locked (for the use case of detecting prematurely locked threads) but that was the idea behind my Locked filter idea that I wanted. If we could create an additional field called "locked date", then sort by that when we create the Locked filter (which I think will be a good filter for moderators). I'll file a bug.

So please make sure auto-locking threads don't add a modified or updated timestamp. Instead we could add a boilerplate message inside the thread when a locked status is detected that reads: This thread was locked after having no activity in 6 months.
Ok. I worked through all the comments and I think the following has consensus:

1. write a new cron job that runs nightly that locks all questions that were created more than 180 days ago

2. locking a question shouldn't change any of the "updated" related fields--it shouldn't create new activity


Additionally, we should verify that:

3. locked questions with answers should show up in search results and be findable by search engines

4. locked questions with NO answers should NOT show up in search results or be findable by search engines


Is that right?
That's correct from my point of view.
Looking at the things to verify aren't affected by auto-locking:

1. All questions are indexed regardless of whether they're locked or not. I'm not going to change that. If someone wants that changed, they should create a new bug.

2. Questions with no answers and are older than 30 days have a meta tag telling search engines not to show them. I'm not going to change that, either. If someone wants that changed, they should create a new bug.
Auto-lock cron job is in a pull request: https://github.com/mozilla/kitsune/pull/683
Landed in master in https://github.com/mozilla/kitsune/commit/17508157537539a4f30c0646fa1aa26b0de801dd

Pretty sure Rehan pushed this to production tonight.

Tomorrow in the wee hours of my morning, the cron job will run and around 160K questions will get auto-locked.

Everything else that's in this bug that wasn't covered by these changes should get spun out into new bugs.

Marking as FIXED.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Thanks, Will! All your statements in comment 22 and comment 24 are correct and intended.
See Also: → 770136, 914266, 943426
See Also: → 602990
See Also: → 1519900
You need to log in before you can comment on or make changes to this bug.