Hello
One of the inconvenience of the discussion page in wikipedia is the fact that does not have a mail-client type of interface/display. That is neither there is a email-summary type of display, nor a display which would allow to display the threads easily.
Are there any plans to include such a feature.
A possibility to would be to have a input and output filter for a neutral mbox format. For example the Debian bug track system has such a possibility.
Regards
Uwe Brauer
On 31/10/05, Uwe Brauer oub@mat.ucm.es wrote:
One of the inconvenience of the discussion page in wikipedia is the fact that does not have a mail-client type of interface/display. That is neither there is a email-summary type of display, nor a display which would allow to display the threads easily.
Are there any plans to include such a feature.
This has been discussed before (I haven't any links to hand, but the usual Googling with "site:mail.wikipedia.org" should turn things up from these lists), but the central problem is that the current setup has no internal representation of a single thread, let alone a single comment, only of a whole page (roughly equivalent to a forum, or a mailbox). The individual threads could potentially be interpretted out by looking at headers, though these aren't used entirely consistently, but it would require quite complex and unreliable pattern matching to separate what humans can easily see as the individual comments.
Furthermore, this is in some ways an *advantage* - all the old-fashioned wiki processes, like refactoring and so on, can take place on the discussion page, unrestricted by structure imposed by the software. One intriguing compromise was the "LiquidThreads" proposal, at http://meta.wikimedia.org/wiki/LiquidThreads, but I'd consider it more of an "idea" than a "planned feature"...
-- Rowan Collins BSc [IMSoP]
"Rowan" == Rowan Collins rowan.collins@gmail.com writes:
Rowan> This has been discussed before (I haven't any links to hand, Rowan> but the usual Googling with "site:mail.wikipedia.org" should I did not find any of these, most likely my googling ability is poor.
Rowan> turn things up from these lists), but the central problem is Rowan> that the current setup has no internal representation of a Rowan> single thread, let alone a single comment, only of a whole Rowan> page (roughly equivalent to a forum, or a mailbox). The Rowan> individual threads could potentially be interpretted out by Rowan> looking at headers, though these aren't used entirely Rowan> consistently, but it would require quite complex and Rowan> unreliable pattern matching to separate what humans can Rowan> easily see as the individual comments. Right, that is what I thought.
Rowan> Furthermore, this is in some ways an *advantage* - all the Rowan> old-fashioned wiki processes, like refactoring and so on, Rowan> can take place on the discussion page, unrestricted by Rowan> structure imposed by the software. One intriguing compromise Rowan> was the "LiquidThreads" proposal, at Rowan> http://meta.wikimedia.org/wiki/LiquidThreads, but I'd Rowan> consider it more of an "idea" than a "planned feature"... The idea sounds appealing and I would support it, however nothing has been implemented so far, as I understand
Uwe
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Uwe Brauer wrote:
The idea sounds appealing and I would support it, however nothing has been implemented so far, as I understand
Uwe
That seems like a really interesting proposal, though it also seems like it would require a lot of work, and probably a seperation of "old-style" and "Liquid" discussion pages, as old talk pages would take a hell of a lot of work to convert- work that seems hard to justify in the long run. - --Chris
-----BEGIN PGP SIGNED MESSAGE-----
Moin,
On Monday 31 October 2005 20:57, Christopher E. Granade wrote:
Uwe Brauer wrote:
The idea sounds appealing and I would support it, however nothing has been implemented so far, as I understand
Uwe
That seems like a really interesting proposal, though it also seems like it would require a lot of work, and probably a seperation of "old-style" and "Liquid" discussion pages, as old talk pages would take a hell of a lot of work to convert- work that seems hard to justify in the long run. --Chris
OTOH, the currenty wikipages are not really suited to discussions at all - I'd rather not have someone edit my "posts" - whether it be for fixing the speling or whatever.
When all you have is a hammer, everything looks like a nail - but I think a new disccusion support would be very good to have, even if it is a lot of work. The longer the old sytle pages are the only possibility, hte longer we will get more and more of them. :)
Best wishes,
Tels
- -- Signed on Tue Nov 1 00:01:40 2005 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email.
"To get something done, a committee should consist of no more than three persons, two of them absent." -- Unknown
On 10/31/05, Tels nospam-abuse@bloodgate.com wrote:
OTOH, the currenty wikipages are not really suited to discussions at all - I'd rather not have someone edit my "posts" - whether it be for fixing the speling or whatever.
When all you have is a hammer, everything looks like a nail - but I think a new disccusion support would be very good to have, even if it is a lot of work. The longer the old sytle pages are the only possibility, hte longer we will get more and more of them. :)
I don't know about that, I often get into discussions where we alternate between wikimode and thread mode. I think the fear of editing comments comes from a lack of trust in the system and the other editors. Often in a discussion I'll post a list or a fragment of text, and multiple people with work on it. I don't see what the harm is in leaving the possibility of editing other peoples words, if someone does it in an objectionable way they will be caught and hung like the evil creatures they are. ;)
Really, the only two problems I've had is tracking changes across multiple parts of a page, but viewing diffs from my last edit fixes that, and getting notified which watchlists mostly fix.
Too bad there isn't a way to watchlist sections. :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Gregory Maxwell wrote:
On 10/31/05, Tels nospam-abuse@bloodgate.com wrote:
OTOH, the currenty wikipages are not really suited to discussions at all - I'd rather not have someone edit my "posts" - whether it be for fixing the speling or whatever.
When all you have is a hammer, everything looks like a nail - but I think a new disccusion support would be very good to have, even if it is a lot of work. The longer the old sytle pages are the only possibility, hte longer we will get more and more of them. :)
I don't know about that, I often get into discussions where we alternate between wikimode and thread mode. I think the fear of editing comments comes from a lack of trust in the system and the other editors. Often in a discussion I'll post a list or a fragment of text, and multiple people with work on it. I don't see what the harm is in leaving the possibility of editing other peoples words, if someone does it in an objectionable way they will be caught and hung like the evil creatures they are. ;)
Really, the only two problems I've had is tracking changes across multiple parts of a page, but viewing diffs from my last edit fixes that, and getting notified which watchlists mostly fix.
Too bad there isn't a way to watchlist sections. :)
I think what you allude to in wikimode discussion forums could be solved by establishing a Scratch: namespace that mirrors the global namespace (e.g.: Scratch:Template:NPOV) that is not considered to be "finished." During development of new formats, or extensive editing, provisional changes could be placed under Scratch, and such suggestions could be referenced from LiquidThreads.
- --Chris
On 01/11/05, Christopher E. Granade cgranade@greens.org wrote:
I think what you allude to in wikimode discussion forums could be solved by establishing a Scratch: namespace that mirrors the global namespace (e.g.: Scratch:Template:NPOV) that is not considered to be "finished." During development of new formats, or extensive editing, provisional changes could be placed under Scratch, and such suggestions could be referenced from LiquidThreads.
Well, my initial reaction to this was "Yuk!" - the whole wiki is supposed to be subject to "extensive editting". Even by having a separate discussion namespace, we've rather removed the incentive to refactor discussions into content or summaries, to our own detriment. Splitting it even further into mostly-stable articles, hard-structured discussions, and unstructured "scratch buffers" would be like having an open-access CMS-cum-wiki, a forum system, and a traditional wiki operating in parallel, which all seems rather stifling. I know that's not what you were suggesting, but it's a kind of worst-case scenario of going down that path.
OTOH, I guess there is some kind of logic to saying that if we're going to force discussion pages to act like classical discussions, we need somewhere else to put their other purposes - and it's true that people already use them as "scratch". I just think we need to be careful in making things too structured, lest we lose the immediacy that is the whole point of being a wiki in the first place.
-- Rowan Collins BSc [IMSoP]
On Tuesday 01 November 2005 00:04, Tels wrote:
When all you have is a hammer, everything looks like a nail - but I think a new disccusion support would be very good to have, even if it is a lot of work. The longer the old sytle pages are the only possibility, hte longer we will get more and more of them. :)
just do not forget the one thing: in a wiki, you can refactor a discussion, in a usual forum this is impossible. i know this is not a common practice on wikipedia, but it is on other wikis, and it makes it much easier to read a diskussion later.
daniel
OTOH, the currenty wikipages are not really suited to discussions at all - I'd rather not have someone edit my "posts" - whether it be for fixing the speling or whatever.
Well, I for one would object to any system that doesn't allow me to edit other people's comments. It's too useful to let traditionalism and conservatism ruin it. It's not just about fixing atrocious spellings, it's also about removing objectionable parts of comments without removing the entire comment, or about summarising an unnecessarily long piece of prose. I don't see any point in listing the advantages here since wikis have shown time and again that they work, and Wikipedia wasn't the first. Yes, it defies the well-established and widely loved web forum paradigm where everyone "owns" their own comments, but we're not a web forum, we're a wiki, and wiki is our paradigm.
Timwi
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Timwi wrote:
OTOH, the currenty wikipages are not really suited to discussions at all - I'd rather not have someone edit my "posts" - whether it be for fixing the speling or whatever.
Well, I for one would object to any system that doesn't allow me to edit other people's comments. It's too useful to let traditionalism and conservatism ruin it. It's not just about fixing atrocious spellings, it's also about removing objectionable parts of comments without removing the entire comment, or about summarising an unnecessarily long piece of prose. I don't see any point in listing the advantages here since wikis have shown time and again that they work, and Wikipedia wasn't the first. Yes, it defies the well-established and widely loved web forum paradigm where everyone "owns" their own comments, but we're not a web forum, we're a wiki, and wiki is our paradigm.
Timwi
Any model, if over applied, is harmful. Making things into discussion fora that do not lend themselves to such a model can only result in the imposing of restrictions upon content which are harmful to the capability of the model.
Thus, in applying a model, it is important to recognize what it was intended for, and what it is good at doing. A Wiki model is good for quasi-static documents (depends on time of access, but not on query), whereas a forum is good for an ongoing discussion. What about a discussion that is itself a document? I see two approaches to this problem: 1) Implement the new LiquidThreads model, which combines the two models. 2) Add discussion-specific metadata syntax to the Wiki syntax to allow for specialized handling of discussions.
Expanding on this second point, consider something like this:
Current format: ==NPOV Complaint== This page is not NPOV! --Someuser :Why not? --Author ::Because of... :We need more justification than that. --Otheruser ::Well, there's...
Proposed format: @topic ==NPOV Complaint== @comment This page is not NPOV! --Someuser @/comment @c:Why not? --Author @/c @c::Because of... @/c @c:We need more justification than that. --Otheruser @/c @c::Well, there's... @/c @/topic
where @c is shorthand for @comment, and the colons following the @c tell MW how nested it is. If you find this markup ugly, suggest something else; I thought of this off the top of my head. - --Chris
Any model, if over applied, is harmful.
Agree. But you didn't elaborate on this fully. Discussion threads and wiki are not mutually exclusive models.
I am strongly in favour of LiquidThreads as long as it doesn't let users claim ownership over "their" comments (which the current proposal proposes to do).
Timwi
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Timwi wrote:
Discussion threads and wiki are not mutually exclusive models.
Not in general, no, but they disagree on some specific points, such as content ownership. In such cases, we need to specify how to resolve the conflict. The "right" answer may be to allow specific sites to configure options. I can easily imagine a set of config options that specifies LiquidThreads content-ownership model behaviors.
$ltAuthorOwnsComment = false; $ltAdminOwnsComment = true;
or perhaps
$ltOwnsComment = $ltAdmin;
where $ltAdmin is a class that LiquidThreads instantiates before processing the config file, and can recognize as a criterion. This latter approach would allow for finer-grained access control by allowing for new classes to be created as combinations of provided classes.
$ltOwnsComment = ltAnd($ltAdmin, $ltAuthor);
- --Chris
-----BEGIN PGP SIGNED MESSAGE-----
Moin,
On Tuesday 01 November 2005 17:36, Timwi wrote:
Any model, if over applied, is harmful.
Agree. But you didn't elaborate on this fully. Discussion threads and wiki are not mutually exclusive models.
I am strongly in favour of LiquidThreads as long as it doesn't let users claim ownership over "their" comments (which the current proposal proposes to do).
I do think these are two seperate points:
* how to improve the discussion pages on a wiki * whether each author own his/her comment or not.
Thinking about this, a wiki article is "owned" by multiple authors, none of which are readily apparent (you have to check the history and even than it is hard to track who "owns" what). OTOH, it is written in NPOV, and checked by a lot of people.
Discussions, OTOH, also involve personal opinions. Danger lies ahead when the opionion can be changed, but is still labeled (or signed, if you wish) with the original authors name.
The current model doesn't even have a way to handle this, let alone to prvent it (if you wanted to prevent it).
Just imagine that this discussion we have is on a wiki, this is the latest edition (you would need to check the history, aka mailing list archives to see the full revisions) and it contained:
On Tuesday 01 November 2005 17:36, Timwi wrote:
Any model, if over applied, is harmful.
Agree. I am strongly in favour of LiquidThreads.
See the danger? (for the record, the above quote of three lines was written/shortened by me, not Timwi).
The current model only relies on "Prinzip Hoffnung", e.g. that is you *hope* that the reader checks the history, or someone checks and edits the discussion page back.
If we can improve the discussion page itself, *and* prevent misrepresentation at the same time, well, that would be great :)
Best wishes,
Tels
- -- Signed on Tue Nov 1 18:20:44 2005 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email.
"What is fair use? Fair use is not a law. There's nothing in law. Right now, any professor can show a complete movie in his classroom without paying a dime - that's fair use. What is not fair use is making a copy of an encrypted DVD, because once you're able to break the encryption, you've undermined the encryption itself." - Jack Valenti
I do think these are two seperate points:
- how to improve the discussion pages on a wiki
- whether each author own his/her comment or not.
But the point is that the answer to the second influences whether the solution proposed for the first is seen as an "improvement". I feel that if the ability to edit other people's comments is taken away from me, I can't label it an "improvement".
Discussions, OTOH, also involve personal opinions. Danger lies ahead when the opionion can be changed, but is still labeled (or signed, if you wish) with the original authors name.
We already have this "danger", and we've had it since the beginning of Phase II, and it has not turned out to be a great problem, so this is not an argument.
Just imagine that this discussion we have is on a wiki, this is the latest edition (you would need to check the history, aka mailing list archives to see the full revisions) and it contained:
On Tuesday 01 November 2005 17:36, Timwi wrote:
Any model, if over applied, is harmful.
Agree. I am strongly in favour of LiquidThreads.
See the danger?
A fallacious argument by false dilemma, or by lack of imagination, or whatever you wanna call it. You almost provided the answer to this one yourself:
(for the record, the above quote of three lines was written/shortened by me, not Timwi).
And that is what it should say.
COMMENT #328645 by [[User:Timwi]]
Agree. I am strongly in favour of LiquidThreads. (This comment was last edited by [[User:Tels]] <date/time>.)
If <date/time> is a minute ago, I better check the diff. If it was an hour ago, I can probably assume that your edit was harmless.
Therefore, again, your "danger" is not an argument against the ability to edit comments.
If we can improve the discussion page itself, *and* prevent misrepresentation at the same time, well, that would be great :)
It's really easy.
Timwi
"Timwi" == Timwi timwi@gmx.net writes:
Hello
Timwi> We already have this "danger", and we've had it since the Timwi> beginning of Phase II, and it has not turned out to be a Timwi> great problem, so this is not an argument.
Just imagine that this discussion we have is on a wiki, this is the latest edition (you would need to check the history, aka mailing list archives to see the full revisions) and it contained: On Tuesday 01 November 2005 17:36, Timwi wrote:
Any model, if over applied, is harmful.
Agree. I am strongly in favour of LiquidThreads.
See the danger?
Timwi> A fallacious argument by false dilemma, or by lack of Timwi> imagination, or whatever you wanna call it. You almost Timwi> provided the answer to this one yourself:
(for the record, the above quote of three lines was written/shortened by me, not Timwi).
Timwi> And that is what it should say.
Timwi> COMMENT #328645 by [[User:Timwi]]
Timwi> Agree. I am strongly in favour of LiquidThreads.
Timwi> (This comment was last edited by [[User:Tels]] Timwi> <date/time>.)
Timwi> If <date/time> is a minute ago, I better check the diff. If Timwi> it was an hour ago, I can probably assume that your edit was Timwi> harmless.
May be I miss here something important, (or you are talking about a feature yet to be implemented) but I just did that evil thing we are discussing. I went to a discussion page, which contained 2 comments, mine and one from another author. I "bravely" deleted the final dot of his last sentence, using an external editor.
And no when I later looked at it from show different versions I could see the chanced but the time stamp you mentioned I could not see, either it that display nor in the source file.
Another important point. Recently I wrote a comment in another discussion page (that one quite huge), again using an external editor. By accident it seems that I changed the coding of the page so, some non ASCII symbols changed. Now you might say that this is the danger which may occur also when I edit an article, however I consider it more annoying in a discussion, where my intention was just to add a single comment.
Conclusion in a discussion page every comment should be protected somehow.
Uwe Brauer
Uwe Brauer:
Another important point. Recently I wrote a comment in another discussion page (that one quite huge), again using an external editor. By accident it seems that I changed the coding of the page so, some non ASCII symbols changed.
This happens if you use an editor which is not capable of editing UTF-8. You can set
Transcode UTF-8=true
in ee.ini under [Settings], but your editor will still mangle characters that are not part of the iso8859-1 character-set. The best thing to do is to use a UTF-8 editor (or, if you already do, set the encoding to UTF-8 when editing wiki pages). I personally use Kate for KDE, which I have found to be an excellent editor for both text and code.
Best,
Erik
"Erik" == Erik Moeller erik_moeller@gmx.de writes:
Erik> Uwe Brauer:
Another important point. Recently I wrote a comment in another discussion page (that one quite huge), again using an external editor. By accident it seems that I changed the coding of the page so, some non ASCII symbols changed.
Erik> This happens if you use an editor which is not capable of Erik> editing UTF-8. You can set
Erik> Transcode UTF-8=true
I know, the problem is (X)emacs has no full UTF-8 support, however it supports iso8859-1. I think my error was not to restrict that set to the german symbols and thats why the error occurred.
Erik> in ee.ini under [Settings], but your editor will still mangle Erik> characters that are not part of the iso8859-1 Erik> character-set. The best thing to do is to use a UTF-8 editor Erik> (or, if you already do, set the encoding to UTF-8 when Erik> editing wiki pages). I personally use Kate for KDE, which I Erik> have found to be an excellent editor for both text and code.
Another option would be to use recode. I might try that.
"Erik" == Erik Moeller erik_moeller@gmx.de writes:
Erik> This happens if you use an editor which is not capable of Erik> editing UTF-8. You can set
Erik> Transcode UTF-8=true
I have that line, however when I "download" article that is, use the external editor _before_ I edit anything I note that for example the German quotation marks like ,,this" are displayed as ?this?, so it seem *my editor* is not the culprit but ee-helper.
Am I correct, or what is my mistake?
Uwe
"Erik" == Erik Moeller erik_moeller@gmx.de writes:
Erik> Transcode UTF-8=true
Erik> in ee.ini under [Settings], but your editor will still mangle Erik> characters that are not part of the iso8859-1 Erik> character-set. The best thing to do is to use a UTF-8 editor Erik> (or, if you already do, set the encoding to UTF-8 when Erik> editing wiki pages). I personally use Kate for KDE, which I Erik> have found to be an excellent editor for both text and code.
May I suggest something different in addition. I recently tried latex-->html-->wiki(pedia)
Since I did not use utf8, the non ASCII symbols got decoded as SGML entities. That text was well understood by wiki it seems.
As far as I can see, when I set Transcode UTF-8=false then your script tries to use some iso8859-x setting. Could it use sgml setting instead?
Thanks
Uwe Brauer
-----BEGIN PGP SIGNED MESSAGE-----
Moin,
On Tuesday 01 November 2005 20:42, Timwi wrote:
I do think these are two seperate points:
- how to improve the discussion pages on a wiki
- whether each author own his/her comment or not.
But the point is that the answer to the second influences whether the solution proposed for the first is seen as an "improvement". I feel that if the ability to edit other people's comments is taken away from me, I can't label it an "improvement".
I have to disagree (because I am not opposed to locking comments).
Discussions, OTOH, also involve personal opinions. Danger lies ahead when the opionion can be changed, but is still labeled (or signed, if you wish) with the original authors name.
We already have this "danger", and we've had it since the beginning of Phase II, and it has not turned out to be a great problem, so this is not an argument.
I consider it a (current) problem, maybe not at wikipedia, but on other wikis.
Just imagine that this discussion we have is on a wiki, this is the latest edition (you would need to check the history, aka mailing list archives to see the full revisions) and it contained:
On Tuesday 01 November 2005 17:36, Timwi wrote:
Any model, if over applied, is harmful.
Agree. I am strongly in favour of LiquidThreads.
See the danger?
A fallacious argument by false dilemma, or by lack of imagination, or whatever you wanna call it. You almost provided the answer to this one
Yes I did. That was intentional. I never said that comment locking is the only solution, but also that comment labeling (like "last edited by") is a method.
yourself:
(for the record, the above quote of three lines was written/shortened by me, not Timwi).
And that is what it should say.
COMMENT #328645 by [[User:Timwi]]
Agree. I am strongly in favour of LiquidThreads. (This comment was last edited by [[User:Tels]] <date/time>.)
If <date/time> is a minute ago, I better check the diff. If it was an hour ago, I can probably assume that your edit was harmless.
Therefore, again, your "danger" is not an argument against the ability to edit comments.
I think you misunderstood me. I said that we should improve the discussion page:
#1 with threads etc #2 doing something against falsely labeled comments #2a by locking them #2b OR by labeling them with the last change #2c whatever else we can come up with
You say that you cannot accept improvements on #1 when 2a is implemented and therefore would rather do nothing.
I disagree, for me either 2a OR 2b would be good. But my point is, that no matter what we choose, we should do SOMETHING. E.g. either 2a, 2b or something else should be done, preferable in conjunction with #1 (doesn't make much sense, technically, anyway).
If we can improve the discussion page itself, *and* prevent misrepresentation at the same time, well, that would be great :)
It's really easy.
<flame>Then why wasn't it done already? :-P </flame>
(Yes, that was a joke, laugh, it is funny.)
Best wishes,
Tels
- -- Signed on Wed Nov 2 17:24:39 2005 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email.
"Any sufficiently rigged demo is indistinguishable from an advanced technology." -- Don Quixote, slashdot guy
Note this:
- how to improve the discussion pages on a wiki
- whether each author own his/her comment or not.
and this:
#1 with threads etc #2 doing something against falsely labeled comments
is not the same thing. That's where the misunderstanding came from.
You say that you cannot accept improvements on #1 when 2a is implemented and therefore would rather do nothing.
No, I said that I wouldn't consider #2a ("locking comments") an improvement. I would consider #1 (threads) an improvement.
for me either 2a OR 2b would be good.
There doesn't seem to be any disagreement between us then. It was only a misunderstanding.
Timwi
-----BEGIN PGP SIGNED MESSAGE-----
Moin,
On Tuesday 01 November 2005 17:01, Christopher E. Granade wrote:
Timwi wrote:
OTOH, the currenty wikipages are not really suited to discussions at all - I'd rather not have someone edit my "posts" - whether it be for fixing the speling or whatever.
Well, I for one would object to any system that doesn't allow me to edit other people's comments. It's too useful to let traditionalism and conservatism ruin it. It's not just about fixing atrocious spellings, it's also about removing objectionable parts of comments without removing the entire comment, or about summarising an unnecessarily long piece of prose. I don't see any point in listing the advantages here since wikis have shown time and again that they work, and Wikipedia wasn't the first. Yes, it defies the well-established and widely loved web forum paradigm where everyone "owns" their own comments, but we're not a web forum, we're a wiki, and wiki is our paradigm.
Timwi
Any model, if over applied, is harmful. Making things into discussion fora that do not lend themselves to such a model can only result in the imposing of restrictions upon content which are harmful to the capability of the model.
Thus, in applying a model, it is important to recognize what it was intended for, and what it is good at doing. A Wiki model is good for quasi-static documents (depends on time of access, but not on query), whereas a forum is good for an ongoing discussion.
I have to stongly agree. Part of the problems with the current discussions are:
*people editing other people's comment, making it appear that person X said Y, while they instead did say "!Y". (I can see lawsuits happen already... ) * people forgetting to sign their name/date, re-arrangement of comments any any other things that make it virtually impossible to reconstruct a discussion (remember, a discussion not only needs to track who said what, but also when, e.g. in which order where things said)
Yes, all changes are theoretically in the history, but good luck in reconstructing the page after some amounts of edits.
* you cannot collapse parts of a discussioin thread, because there is no structure/tree/thread etc - it is all a flat text. * likewise, seeing hat changed last on the discussion page involves the cumbersome history - you cannot simple read the last entries on a long page after some time because they are all merged into the same flat text.
A discussion thread is simple not the same as an article, and I think the wiki principle cannot work good for it. However, see below:
What about a discussion that is itself a document? I see two approaches to this problem: 1) Implement the new LiquidThreads model, which combines the two models. 2) Add discussion-specific metadata syntax to the Wiki syntax to allow for specialized handling of discussions.
What I had in mind that the discussion page could be constructed from a series of "posts". Each post would be a wiki-mini-article in itself. Thus you get the tree structure (can collapse threads sort them etc), plus the "show me the latest posts", and you still have the "edit other people's text" feature. You need no new markup, it probably suffices to have a front-end that can collect the posts (all articles in name-space "MyArticle::Discussion::Post?) and display them on one page, with edit buttons etc per post.
You could even make it so that when the original author requests this, only admins can edit/delete this post (in case of trouble). If the author does request it, anybody can edit the text.
You could even have a "this post was last edited by XYZ on ABC" - thus showing immidiately that the original author wasn't the last one to touch the text and thus giving you a hint to look at the history.
Currently you would need always check the history to spot malicous modifications.
Threading by subject, time etc are all possible because these are just rearangements of the post articles.
Btw, even if the main wikipedia does not use this new discussion style, a lot of small wikis could benefit greatly from an improved discussion page. The current model ends in quite a chaos after a while.
Expanding on this second point, consider something like this:
Current format: ==NPOV Complaint== This page is not NPOV! --Someuser
[snip]
Proposed format: @topic ==NPOV Complaint== @comment This page is not NPOV! --Someuser @/comment @c:Why not? --Author @/c @c::Because of... @/c @c:We need more justification than that. --Otheruser @/c @c::Well, there's... @/c @/topic
where @c is shorthand for @comment, and the colons following the @c tell MW how nested it is. If you find this markup ugly, suggest something else; I thought of this off the top of my head.
Oh, please not more markup to remember, parse and translate. I think a real one-article-per-post model would solve the problem more elegant. ;)
Btw, I do not know what Liquidthreads is, but if it works like what I proposed, just count me in favour of it :)
Best wishes,
Tels
- -- Signed on Tue Nov 1 17:43:13 2005 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email.
"You know the world is going crazy when the best rapper is a white guy, the best golfer is a black guy, the tallest guy in the NBA is Chinese, the Swiss hold the America's Cup, France is accusing the U.S. of arrogance, Germany doesn't want to go to war, and the three most powerful men in America are named 'Bush', 'Dick', and 'Colon'. Need I say more?" -Chris Rock
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tels wrote:
Oh, please not more markup to remember, parse and translate. I think a real one-article-per-post model would solve the problem more elegant. ;)
Btw, I do not know what Liquidthreads is, but if it works like what I proposed, just count me in favour of it :)
Best wishes,
Tels
I only said it was a solution- not a good one.
BTW, LiquidThreads is documented at: http://meta.wikimedia.org/wiki/LiquidThreads
- --Chris
-----BEGIN PGP SIGNED MESSAGE-----
Moin,
On Tuesday 01 November 2005 18:16, Christopher E. Granade wrote:
Tels wrote:
Oh, please not more markup to remember, parse and translate. I think a real one-article-per-post model would solve the problem more elegant. ;)
Btw, I do not know what Liquidthreads is, but if it works like what I proposed, just count me in favour of it :)
Best wishes,
Tels
I only said it was a solution- not a good one.
:)
BTW, LiquidThreads is documented at: http://meta.wikimedia.org/wiki/LiquidThreads
So far, it seem a sensible proposition. The technical details are of course, technical details.
Best wishes,
Tels
- -- Signed on Tue Nov 1 18:31:10 2005 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email.
Ich bin mit der Gesamtsituation unzufrieden!
On 11/1/05, Tels nospam-abuse@bloodgate.com wrote:
What I had in mind that the discussion page could be constructed from a series of "posts". Each post would be a wiki-mini-article in itself. Thus you get the tree structure (can collapse threads sort them etc), plus the "show me the latest posts", and you still have the "edit other people's text" feature. You need no new markup, it probably suffices to have a front-end that can collect the posts (all articles in name-space "MyArticle::Discussion::Post?) and display them on one page, with edit buttons etc per post.
<
You could even have a "this post was last edited by XYZ on ABC" - thus showing immidiately that the original author wasn't the last one to touch the text and thus giving you a hint to look at the history.
<
Threading by subject, time etc are all possible because these are just rearangements of the post articles.
Yes and yes. I would dearly like to see the above implemented. A system optimized for threaded discussions, rather than what one could hack up with the current transclusion implementation.
SJ
SJ wrote:
On 11/1/05, Tels wrote:
Threading by subject, time etc are all possible because these are just rearangements of the post articles.
Yes and yes. I would dearly like to see the above implemented. A system optimized for threaded discussions, rather than what one could hack up with the current transclusion implementation.
Transclusion hacks make the Baby Cthulu cry.
And trust me, you *don't* want to see the Baby Cthulu cry!
-- brion vibber (brion @ pobox.com)
Timwi <timwi@...> writes:
OTOH, the currenty wikipages are not really suited to discussions at all - I'd rather not have someone edit my "posts" - whether it be for fixing the speling or whatever.
Well, I for one would object to any system that doesn't allow me to edit other people's comments. It's too useful to let traditionalism and conservatism ruin it. It's not just about fixing atrocious spellings, it's also about removing objectionable parts of comments without removing the entire comment, or about summarising an unnecessarily long piece of prose. I don't see any point in listing the advantages here since wikis have shown time and again that they work, and Wikipedia wasn't the first. Yes, it defies the well-established and widely loved web forum paradigm where everyone "owns" their own comments, but we're not a web forum, we're a wiki, and wiki is our paradigm.
Timwi
Who are you to decide what is objectionable, or unnecessarily long, especially in someone's opinion based comment? This is EXACTLY what a lot of people are talking about when they dislike the idea of someone editing their comments.
Just because something is status quo doesn't mean that it is working. The discussion pages are probably one of the worst features of mediawiki IMO. I hate the idea of someone editing my comments. 99% of the time, people who are reading the discussion section will NOT check the history to see if what someone said is really what someone said.
I believe the proposed idea is quite a good balance between the current model, and a traditional forum/thread style model. It still allows editing (when users allow it), and refactoring. But it could also allow an easier model to track threads, reply to comments, get notification when a person responds to your posts/replies, etc, etc...
I think your objection to a new system is conservatism at its best. The new model could offer quite a bit of benefit.
Ryan Lane
Who are you to decide what is objectionable, or unnecessarily long, especially in someone's opinion based comment?
Strawman argument: I didn't say I "decide" anything. If anyone can edit, anyone can revert; the "decision" is ultimately that of the community, not of any individual. The purpose of the comment is (and will always be) to reflect a given user's opinion, and the community will ensure this will be met.
On the contrary, who are you to decide that nobody should be allowed to edit something, ESPECIALLY in a system where you are perfectly free to simply NOT SUBMIT whatever it is you don't want edited? We already have mailing lists where you can publish stuff that you don't want edited.
This is EXACTLY what a lot of people are talking about when they dislike the idea of someone editing their comments.
And the fact that it is a fallacy is EXACTLY what I'm talking about when I dislike the idea of giving in to it.
Just because something is status quo doesn't mean that it is working.
Nor does it mean that it is _not_ working. I see very little of the problems you have described, and even the problems that you have described are false dilemmas, i.e. they can perfectly well be addressed without preventing anyone from editing something. Example:
99% of the time, people who are reading the discussion section will NOT check the history to see if what someone said is really what someone said.
Right, so it needs to be made easier to check this, and/or there needs to be some sort of visual indication that there is a chance that it might not be what someone said. Both is addressed by my suggestion of adding a little "This comment was last edited by <username> <date/time>" with a link to a diff between the comment's original author's latest revision and the current revision. It surely does not mean it's necessary to make editing of any comment impossible.
I believe the proposed idea is quite a good balance between the current model, and a traditional forum/thread style model.
The proposed idea *is* a traditional forum/thread style model, with only two additional features (users can allow other users to edit their comments, and the concept of "channels"). It is to the wiki philosophy like Everything2 is to Wikipedia.
Ideologically, it's kind of like allowing people to submit articles and then keep them protected so only they can edit them. You're going to tell me that it's not the same thing because comments express a person's opinion, but this is why I added the word "ideologically". If it was just about letting people's paranoia free reign, then we could as well just use a box-standard web forum. In fact, it would already be possible _theoretically_ to move all discussions to a mailing list and use the Talk namespace only for the summaries/refactorings. Why don't we do this? Because IT'S NOT WIKI.
I think your objection to a new system is conservatism at its best.
It would be conservatism if I was an avid Talk-page participant. However you will notice that I am actually quite a bit more active on the mailing lists than the Talk pages.
The new model could offer quite a bit of benefit.
You have not convinced me of such a "benefit" of making it completely impossible to edit some comments. You have shown some drawbacks of the current system, but as I said, concluding from it that editing needs to be made impossible is a false-dilemma fallacy.
Timwi
wikitech-l@lists.wikimedia.org