2014-09-07 0:33 GMT+02:00 Erik Moeller erik@wikimedia.org:
On Sat, Sep 6, 2014 at 2:14 PM, Romaine Wiki romaine.wiki@gmail.com wrote:
I am an admin on Commons, and I regularly have to remove an image on a
talk
page because it is for example a violation of copyright. I see no way to remove the copyright violation from the message.
Another thing I tried is the removal of a personal attack or a privacy issue. It is common on nl-wiki to remove a personal attack out of a
message
and replacing it by a template which says what happened. This is
impossible
to do.
Please see my response to Todd here explaining the current permissioning:
https://lists.wikimedia.org/pipermail/wikimedia-l/2014-September/074358.html
Okay. One point I miss there, which I tried to mention in the post I typed before I saw this one, is that there is a fundamental question to be answered. The question is: who is in control of the content of pages. Should the software be in control of pages or the local community? Maybe this sounds strange, but the community has now the ability to rearrange a talk page to reflect better the needs.
I know examples of people who added a new header about the same topic which was discussed above, and then the two headers were merged into one. Or the order of the messages being changed. To split up a topic into two topics to keep the subject on topic. Rearranging large topics by adding 3rd and 4th degree headers in what messages are grouped. These changes are now used to keep the overview over an topic.
But hiding a complete message while only a very small part, usually one or two words, is requested to be hidden, is unbalanced.
If a template is changed, its parameters on the various places where the template is added need to be changed as well. This is done by hand or
with
a bot (like AWB), both ways seems impossible with flow.
Flow doesn't automatically update template output -- it retains the output as it was when the user posted the comment. We can argue whether that's good or bad behavior, but it's worth doing so in the context of real examples. When would this cause problems?
Contrary to some descriptions, it's not quite the same as {{subst}}ing the template. You can still get back to the wikitext used produce the output, and change it, and potentially re-parse it. It just doesn't do so automatically (which is also not an inherent limitation).
Interesting way of handling templates. I need to think of what consequences that would have, how it influences the way of using talk pages.
One question that already comes in my mind is what happens when in one message a template is added, the template got deleted and later the user who posted the original message wants to change the text. Will the template stay look the same as the original post or will it be updated with saving the change? (Sorry, I have not tested this yet.)
If someone added a message to the wrong page, it is relocated to another talk page. Seems impossible to do here. If a message is considered to be inappropriate for a certain page, it is relocated, seems impossible with Flow.
It doesn't support any kind of moving yet, that's still (like many features) to be developed, but unlike talk pages, it's architecturally viable to move a whole thread and its history, rather than copying and pasting content around, losing history, as we currently do routinely.
Good to read that it is something which is already thought of. I think it is considered more important to have the possibility to move a text (with a link to the source page for the history) than having the history with it. But I think it can be an improvement if moving is possible with history.
Another thing I noticed is that I can't get a complete overview of all messages added to a certain talk page. After 10 messages, everything is hidden. A quick ctrl + F is impossible. When I know there was a
discussion
about a specific thing, I want to check the talk page easily by searching it completely, not possible. It is very annoying that I can't get a complete overview of all messages on a talk page, this is a basic need!
Of course, which is why it's a high priority feature.
Good to know.
To answer the question, To Flow or not to Flow, it does not flow. I am
not
able to do simple edits which are done every day.
It's a system in early development, and has never been advertised as anything else. To draw conclusions about what it can and cannot do is, by definition, premature. A much more useful discussion is whether a system like it (provided some of its properties are clarified and improved) is desirable, and if not, what alternative ways there are to make talk pages more user-friendly, and what the limitations of those methods are. Also, to the extent that there are aspects of the Flow architecture that really are dealbreakers, we should fix them now.
Someone (a user) gave me today another impression, it is good you tell me this so I can correct that.
As I wrote to Risker, I think it's worth considering spending some development time on turning something like the Teahouse gadget (which allows one click insertion of replies on the Teahouse Q/A page) into a Beta Feature after some further improvement, to see just how useful it could be for the common case. If there's an 80/20 rule and in 20% of cases it just gives up and edits the section, that might still be a time-saver and convenience. There might even be other relevant gadgets already in some languages/projects -- worth a closer look, for sure.
Flow is a long term bet that an architecture of tructured comments will ultimately have fewer hard and fast limitations on how collaboration in wikis can work, and will accrue usability benefits very quickly (as it already has done, like faster posting and replies) due to its architecture. So far we've only invested in the long term bet -- some rebalancing of effort towards the short term may be valuable, and may lead to interim milestones that impact users today rather than years from now. I can't answer when you'd hit the boundaries of what you can do with the free form text on talk pages today, but I don't think anyone's really tried yet. (Magnus, I am sending brain waves in your direction! ;-)
I do hope that the performance for end users will be kept taken care of and that it stays very quickly.
I think I have a good change to use the maximum of talk pages. As my talk page is often used as some sort of help desk and to-do list in one, I archive parts of it after checking if I have completed the subject, done the request, solved the issue, etc. I do not automatically archive but do archive manual after checking if the message is no longer needed.
In Flow I miss the option to copy the source code, even if it was only a part, to quote someone including the wikisyntax that user added.
I must say, I like the the situation of the VisualEditor. It is there very easy to edit, but if you need you can still access and edit the source code. I can understand that viewing a complete talk page in source code modus is not possible, but for topics such should be possible I think.
Thanks for the answers and explanations.
Romaine
Erik
-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe