Hi,
FYI I'm not very satisfied with these plans. They are not in line with existing feedback, partly, and partly are not in line with the practices I've observed at various on-wiki village pumps. Please look at https://www.mediawiki.org/wiki/Flow/Prior_discussion-thread-roundup#Post_Mod... a bit more. I would like to encourage more thought put into this while performing programming work. And put early.
S Page wrote:
- To deal with spam topics and posts, we're going to append "(hide)"
(and delete | suppress for admins) to "created new topic"/"commented" lines on board and topic history pages. These will work the same as hide|delete|suppress actions do on Flow board and topic pages.
"Concerns about access to viewing or editing others' posts" in the link I gave has a bunch of topics about this. Looks like people want anyone to be able to delete others' comments. I haven't seen this as a problem for years. Please don't restrict delete to admins. (Suppress is another story and limiting it to admins makes sense.)
S Page wrote:
- We're going to rename Close topic to Lock topic. This better matches what
it actually does, which is prevent new posts and changes (with lots of bugs currently). To make it more obvious what Lock does, we'll remove the Reply and Edit links from a locked topic, instead of them failing on submit.
Note many use case of "This topic is closed" fit well with the Summarize topic action. People can and should put {{done}}, {{abandoned}}, {{answered}}, etc. templates and markup in a topic's summary.
This wasn't discussed with people at Talk:Flow before, but I plainly think that's a wrong way to do it.
The reason is that I follow-up a resolved topic rather often. "Hi this template is broken" "I fixed it in this edit" "thanks!" "[locks thread]" - and then I want to ask how to fix another one a day later, I tried the same fix but it didn't work?? I should spend hours of my time pressing UNLOCK when nothing should have locked it in the first place???
Hm. On the other side, with Flow, we don't have archives. We don't want old topics to resurface with 'thanks!' and go all way to the top of 'recently active' list.
OK, please redesign the LOCK feature a little. :-) 0) Please add a 'this answer solved the problem' button - anyone should be able to click it. It could go to 'this topic has 3 comments and 1 solution' subtitle in the topic title. 1) When a thread is active recently (less than N days), it can't be locked. People are able to follow-up within the same thread. 2) When a thread is inactive recently (active more than N days ago), it's automatically archived. This means it takes extra effort (and warnings dumped onto your head) when you try to reactivate it. 3) The number "N" should depend on a page activity. If a talk page of an article is dead, it makes no sense to archive anything, even if it's a year old. 4) It should be possible to 'HAT' a topic if it's inflammable before the N days time.
I hope this will ease usability too - it's much easier to click a specific message and click "it solves the problem" than go through the process of locking down the entire thread.
Related topics: https://www.mediawiki.org/wiki/Topic:S0duk9t3t90a4c67 - Stop making reply impossible to closed topics https://www.mediawiki.org/wiki/User:Gryllida/Flow - thoughts on moderation in Flow - DONTs: "Nothing should prevent anyone from replying to a message under any circumstances."
We'll probably begin developing these in the next two-week sprint. Hope this helps. -- =S Page Features engineer
svetlana
Hi Svetlana,
Yes, what you're describing is the problem that we've had with "Close".
In the feature that's live on the site right now, any user can Close a topic, which means:
* The topic header turns white, and there's a "Closed by user name" line. * The posts are hidden by default, so all you see is the topic header. You can click on the topic header to view the posts. * The main entry field for replies is suppressed. * The Reply links still appear on the individual posts, but if you try to post a reply, you get an error message.
This is a broken feature, and it doesn't even align well with what wiki communities mean when they "close" a discussion. It was a decent first draft, but it didn't land.
Redoing the moderation actions has been on my list of things to do since I joined the Flow team in April. Hide doesn't hide enough, and Close closes too much. These problems have come up several times recently, on Talk:Flow and on the mailing list.
We're going to be testing out Flow on a couple of mentorship spaces in the next month, and I've been concerned that when someone answers a newbie's question, they'll think that the next step is to "Close" the discussion, to mark that the question has been answered. (Wiki people like to keep things tidy.) That would lead to exactly the broken experience that you describe -- people closing and opening topics with every response, which would confuse and frustrate everyone.
Meanwhile, there's a bigger and more interesting idea that we're working on -- using "resolved" as a way to celebrate successful decisions, rather than hiding them or pushing them away. We're also starting to think about how to use the "Summarize" feature in a different way -- maybe encouraging people to use it as an editable scratchpad built into a particular spot in the discussion. That idea hasn't quite come together yet, but there's something interesting there that we're talking and thinking about.
So -- while that idea is still percolating on a back burner -- I wanted to take a step that would discourage people from using "Close" to penalize a successful conversation that's reached a happy conclusion. That's why we're changing that word to "Lock", which expresses more clearly that cutting off replies is a negative act which people shouldn't do very often, if at all. It definitely should not be the typical way for a conversation to end.
We're going to keep making changes like this -- small shifts and iterations that build over time. We have an unbelievably long list of features to build, experiments to try, horrible mistakes to make and learn from. We will be periodically breaking and fixing and re-breaking Flow on a regular basis, from now until a long while from now. That's the only way to build a big complicated feature like this. It's more of an art than a science, and it's not even that much of an art.
As a team, we're trying to be more open and transparent about the work that we're doing -- that's why we've started sending these emails out to a public list. We want to talk more about the problems that we're wrestling with, get more ideas and questions from the community, and then channel that energy into actually making changes and trying things out.
If you're on this mailing list, that means you're interested in seeing how the sausage gets made. It is not always pretty. But I'm glad that you're here, and that you're into it. That means you're on the team.
Danny
On Tue, Sep 2, 2014 at 6:02 PM, svetlana svetlana@fastmail.com.au wrote:
Hi,
FYI I'm not very satisfied with these plans. They are not in line with existing feedback, partly, and partly are not in line with the practices I've observed at various on-wiki village pumps. Please look at https://www.mediawiki.org/wiki/Flow/Prior_discussion-thread-roundup#Post_Mod... a bit more. I would like to encourage more thought put into this while performing programming work. And put early.
S Page wrote:
- To deal with spam topics and posts, we're going to append "(hide)"
(and delete | suppress for admins) to "created new topic"/"commented"
lines on
board and topic history pages. These will work the same as hide|delete|suppress actions do on Flow board and topic pages.
"Concerns about access to viewing or editing others' posts" in the link I gave has a bunch of topics about this. Looks like people want anyone to be able to delete others' comments. I haven't seen this as a problem for years. Please don't restrict delete to admins. (Suppress is another story and limiting it to admins makes sense.)
S Page wrote:
- We're going to rename Close topic to Lock topic. This better matches
what
it actually does, which is prevent new posts and changes (with lots of
bugs
currently). To make it more obvious what Lock does, we'll remove the
Reply
and Edit links from a locked topic, instead of them failing on submit.
Note many use case of "This topic is closed" fit well with the Summarize topic action. People can and should put {{done}}, {{abandoned}}, {{answered}}, etc. templates and markup in a topic's summary.
This wasn't discussed with people at Talk:Flow before, but I plainly think that's a wrong way to do it.
The reason is that I follow-up a resolved topic rather often. "Hi this template is broken" "I fixed it in this edit" "thanks!" "[locks thread]" - and then I want to ask how to fix another one a day later, I tried the same fix but it didn't work?? I should spend hours of my time pressing UNLOCK when nothing should have locked it in the first place???
Hm. On the other side, with Flow, we don't have archives. We don't want old topics to resurface with 'thanks!' and go all way to the top of 'recently active' list.
OK, please redesign the LOCK feature a little. :-) 0) Please add a 'this answer solved the problem' button - anyone should be able to click it. It could go to 'this topic has 3 comments and 1 solution' subtitle in the topic title.
- When a thread is active recently (less than N days), it can't be
locked. People are able to follow-up within the same thread. 2) When a thread is inactive recently (active more than N days ago), it's automatically archived. This means it takes extra effort (and warnings dumped onto your head) when you try to reactivate it. 3) The number "N" should depend on a page activity. If a talk page of an article is dead, it makes no sense to archive anything, even if it's a year old. 4) It should be possible to 'HAT' a topic if it's inflammable before the N days time.
I hope this will ease usability too - it's much easier to click a specific message and click "it solves the problem" than go through the process of locking down the entire thread.
Related topics: https://www.mediawiki.org/wiki/Topic:S0duk9t3t90a4c67 - Stop making reply impossible to closed topics https://www.mediawiki.org/wiki/User:Gryllida/Flow - thoughts on moderation in Flow - DONTs: "Nothing should prevent anyone from replying to a message under any circumstances."
We'll probably begin developing these in the next two-week sprint. Hope this helps. -- =S Page Features engineer
svetlana
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
On 09/02/2014 09:02 PM, svetlana wrote:
"Concerns about access to viewing or editing others' posts" in the link I gave has a bunch of topics about this. Looks like people want anyone to be able to delete others' comments.
The Flow team should correct me if I'm wrong, but my understanding is that "hide" is available to everyone, and deliberately similar to simply removing/deleting a wikitext post (when I say "deleting" here, I don't mean the actual action=delete as it applies to wikitext).
For wikitext, that removes the post/section from the page, but it's in history and can be re-added by anyone. For Flow, it hides it, but it can be unhidden by anyone.
Matt Flaschen
Yes, everybody has access to Hide and Unhide. It doesn't quite work the way that we want it to yet -- the current version of Hide collapses the conversation to a single line, but doesn't actually remove it from the page. That collapsed line is still a pretty shiny button that says "Click here to see the bad thing". :)
So we're going to make a change very soon that will actually take the Hidden topics off the page, and just have them accessible in the board history and contributions. I think that's a better match with the way it works on talk pages.
Danny
On Thu, Sep 4, 2014 at 6:54 PM, Matthew Flaschen mflaschen@wikimedia.org wrote:
On 09/02/2014 09:02 PM, svetlana wrote:
"Concerns about access to viewing or editing others' posts" in the link I gave has a bunch of topics about this. Looks like people want anyone to be able to delete others' comments.
The Flow team should correct me if I'm wrong, but my understanding is that "hide" is available to everyone, and deliberately similar to simply removing/deleting a wikitext post (when I say "deleting" here, I don't mean the actual action=delete as it applies to wikitext).
For wikitext, that removes the post/section from the page, but it's in history and can be re-added by anyone. For Flow, it hides it, but it can be unhidden by anyone.
Matt Flaschen
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
Hi
I have some questions, related to this discussion.
Why do you think it is it relevant to hide a topic, just in case of spam? Anyone can censor a topic, which is not really very friendly and cooperative. On the current talk system, when a subject is problematic, we suppress it. A "report as spam" button may be more relevant, with a confirmation by admins (for example)? Do you think Flow will provide a way to post for spam robots?
Do you imagine edit wars on hiding/unhiding topics? I do :-) Is there a feature to avoid/protect that?
When I hide, it is for everyone. Do you plan to create an 'ignore' feature which just hide the topic only for myself (like on GMail)?
(And Flow is alive on French Wikipedia, it is soooooo cool :-))
Have a good day, Benoît
Benoît Evellin Membre de Wikimédia France Conseil d'administration, secrétaire www.wikimedia.fr
2014-09-05 16:31 GMT+02:00 Danny Horn dhorn@wikimedia.org:
Yes, everybody has access to Hide and Unhide. It doesn't quite work the way that we want it to yet -- the current version of Hide collapses the conversation to a single line, but doesn't actually remove it from the page. That collapsed line is still a pretty shiny button that says "Click here to see the bad thing". :)
So we're going to make a change very soon that will actually take the Hidden topics off the page, and just have them accessible in the board history and contributions. I think that's a better match with the way it works on talk pages.
Danny
On Thu, Sep 4, 2014 at 6:54 PM, Matthew Flaschen mflaschen@wikimedia.org wrote:
On 09/02/2014 09:02 PM, svetlana wrote:
"Concerns about access to viewing or editing others' posts" in the link I gave has a bunch of topics about this. Looks like people want anyone to be able to delete others' comments.
The Flow team should correct me if I'm wrong, but my understanding is that "hide" is available to everyone, and deliberately similar to simply removing/deleting a wikitext post (when I say "deleting" here, I don't mean the actual action=delete as it applies to wikitext).
For wikitext, that removes the post/section from the page, but it's in history and can be re-added by anyone. For Flow, it hides it, but it can be unhidden by anyone.
Matt Flaschen
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
On 09/05/2014 01:49 PM, Benoît Evellin wrote:
Hi
I have some questions, related to this discussion.
Why do you think it is it relevant to hide a topic, just in case of spam?
It's not just for topics, but also for posts.
Another common reason (maybe even more common than spam) would be personal attacks. Although the policy is gray at least on English Wikipedia (https://en.wikipedia.org/wiki/Wikipedia:No_personal_attacks#Removal_of_perso...), personal attacks are sometimes removed without deleting them from history (essentially, the hide action).
Anyone can censor a topic, which is not really very friendly and cooperative. On the current talk system, when a subject is problematic, we suppress it.
The equivalent to hide also exists in wikitext:
1. Click edit 2. Remove the post in the edit box 3. Click save
Of course, this removal action is logged in both cases (wikitext and Flow), so any abuses are clearly visible.
Do you think Flow will provide a way to post for spam robots?
Yes, but the same tools to stop them are available, such as AbuseFilter. It will not be a worse problem.
Do you imagine edit wars on hiding/unhiding topics? I do :-) Is there a feature to avoid/protect that?
3 Revert Rule (https://en.wikipedia.org/wiki/Wikipedia:Edit_warring#The_three-revert_rule)?
(This is a rule on English Wikipedia that more than 3 reverts per 24 hours is grounds for blocking, in addition to the general rule against edit warring)
I agree with S that not every social issue needs a software solution.
Matt Flaschen
Hi
Thank you for your answers Matthew.
Benoît On 09/05/2014 01:49 PM, Benoît Evellin wrote:
Hi
I have some questions, related to this discussion.
Why do you think it is it relevant to hide a topic, just in case of spam?
It's not just for topics, but also for posts.
Another common reason (maybe even more common than spam) would be personal attacks. Although the policy is gray at least on English Wikipedia ( https://en.wikipedia.org/wiki/Wikipedia:No_personal_ attacks#Removal_of_personal_attacks), personal attacks are sometimes removed without deleting them from history (essentially, the hide action).
Anyone can censor a topic, which is not really very friendly and
cooperative. On the current talk system, when a subject is problematic, we suppress it.
The equivalent to hide also exists in wikitext:
1. Click edit 2. Remove the post in the edit box 3. Click save
Of course, this removal action is logged in both cases (wikitext and Flow), so any abuses are clearly visible.
Do you think Flow will provide a way to post for spam robots?
Yes, but the same tools to stop them are available, such as AbuseFilter. It will not be a worse problem.
Do you imagine edit wars on hiding/unhiding topics? I do :-) Is there a
feature to avoid/protect that?
3 Revert Rule (https://en.wikipedia.org/wiki/Wikipedia:Edit_warring# The_three-revert_rule)?
(This is a rule on English Wikipedia that more than 3 reverts per 24 hours is grounds for blocking, in addition to the general rule against edit warring)
I agree with S that not every social issue needs a software solution.
Matt Flaschen
_______________________________________________ EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
On Tue, Sep 2, 2014 at 6:02 PM, svetlana svetlana@fastmail.com.au wrote:
... S Page wrote:
- We're going to rename Close topic to Lock topic. This better matches
what
it actually does, which is prevent new posts and changes (with lots of
bugs
currently). To make it more obvious what Lock does, we'll remove the
Reply
and Edit links from a locked topic, instead of them failing on submit.
Note many use case of "This topic is closed" fit well with the Summarize topic action. People can and should put {{done}}, {{abandoned}}, {{answered}}, etc. templates and markup in a topic's summary.
This wasn't discussed with people at Talk:Flow before, but I plainly think that's a wrong way to do it.
The reason is that I follow-up a resolved topic rather often. "Hi this template is broken" "I fixed it in this edit" "thanks!" "[locks thread]" - and then I want to ask how to fix another one a day later, I tried the same fix but it didn't work?? I should spend hours of my time pressing UNLOCK when nothing should have locked it in the first place???
If you trust other people to delete (which is harder to revert), why not trust them to use Lock appropriately?
Social norms will develop around the facilities Flow provides, just as they have done for wiki edits to talk pages.
Hm. On the other side, with Flow, we don't have archives. We don't want old
topics to resurface with 'thanks!' and go all way to the top of 'recently active' list.
(The requested "+1" feature, if we implement it, could avoid this.)
OK, please redesign the LOCK feature a little. :-) 0) Please add a 'this answer solved the problem' button - anyone should be able to click it. It could go to 'this topic has 3 comments and 1 solution' subtitle in the topic title.
Right now, putting a {{Flow-closed | #<UUID>}} template in the summary could display "Topic solved \o/ _Jump to the solution post_" in the summary. That gets us 75% of the way there. (Someone who wants to contribute could write a gadget that appends a "This post is a solution" button to the Reply * Edit * Thank or the post actions menu.)
Flow has the notion of workflow_types, but it's probably premature to develop a workflow for Q&A when Flow isn't yet on use on any Q&A pages. We need to get general-purpose features working well.
- When a thread is active recently (less than N days), it can't be
locked. People are able to follow-up within the same thread.
That feels more like a social norm that communities will develop than a rule we should embed in software.
- When a thread is inactive recently (active more than N days ago), it's
automatically archived. This means it takes extra effort (and warnings dumped onto your head) when you try to reactivate it. 3) The number "N" should depend on a page activity. If a talk page of an article is dead, it makes no sense to archive anything, even if it's a year old.
2 and 3 describe Lock and suggesting it happens automatically. If a Flow topic is inactive, why do anything? It will be pushed out of view by newer active topics. If communities want this then it sounds more like a role for a bot, not Flow core code.
- It should be possible to 'HAT' a topic if it's inflammable before the N
days time.
I'm not sure what you mean, can't you do this using Summarize?
I hope this will ease usability too - it's much easier to click a specific message and click "it solves the problem" than go through the process of locking down the entire thread.
"It solves the problem" seems orthogonal to locking and unlocking. (/me fights urge to try to write first gadget.)
Thanks for your interest and suggestions!
You have misunderstood everything I said. However, I also had put it in a clumsy and ugly way.
My suggested changes are: - that 'lock' is renamed to 'archive' and is only available after the topic is inactive - that Flow provides a list of reasonably inactive topics to volunteers who would like to archive stuff -- the archival process should be semi-automated - that 'reasonably inactive' depends on the board activity - that portions of messages are possible to {{hat}} (hide from view with a 'show' button) where they are inflammable, to offset for lack of 'lock' means while a discussion is active - that 'this is solved' gets marked in individual posts and has nothing to do with locking topics
Rationale behind these changes is: - people should be able to follow-up a topic easily instead of being locked out and left confused - for this reason, 'reasonably inactive' should be a pretty high time frame - the 'this is solved' mark may be needed to be put early -- so due to the above it needs to be a separate action from locking/archival
svetlana