2014-09-07 0:33 GMT+02:00 Erik Moeller <[email protected]>:
> On Sat, Sep 6, 2014 at 2:14 PM, Romaine Wiki <[email protected]>
> 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
> [email protected]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[email protected]?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[email protected]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:[email protected]?subject=unsubscribe>
