The FlaggedRevs code shudders forward! This is not "happening news" yet, it's sort of pre-news ... but! Progress! :-D
Once it's fit for public use, the plan is still to put it on de:wp and see how that goes. (Not sure yet what criteria will be used to decide if the trial is a success, failure or what.)
- d.
---------- Forwarded message ---------- From: P. Birken pbirken@gmail.com Date: 14 Jan 2008 04:19 Subject: [Wikiquality-l] Current Status To: Wikimedia Quality Discussions wikiquality-l@lists.wikimedia.org
A happy new year to everybody. Thanks to Aaron and Tim, the code is now fit for large-scale applications. The next step (large-scale betatest or immediate deployment) is now under discussion, I'll keep you in the loop.
The current version of the extension using a set of parameters that shows most features, but will not be used in this form, can be found on test.wikipedia.org and you can give yourself rights by logging in and going to http://test.wikipedia.org/wiki/Special:Userrights.
If you find any bugs or points you want to discuss, right now would be a good time :-)
Best,
Philipp
_______________________________________________ Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
On 14/01/2008, David Gerard dgerard@gmail.com wrote:
The FlaggedRevs code shudders forward! This is not "happening news" yet, it's sort of pre-news ... but! Progress! :-D
Once it's fit for public use, the plan is still to put it on de:wp and see how that goes. (Not sure yet what criteria will be used to decide if the trial is a success, failure or what.)
Sorry to be so pessimistic, but since we've taken more than two years as a community to accept a trivial revision of the software that permits non-administrators to revert vandalism in a single step, and we're still wobbly about that, what possibility does this large-scale and revolutionary change have of ever being accepted on English Wikipedia?
http://en.wikipedia.org/w/index.php?title=Wikipedia:Requests_for_rollback&am...
Tonay Sidaway wrote:
On 14/01/2008, David Gerard dgerard@gmail.com wrote:
The FlaggedRevs code shudders forward!
Sorry to be so pessimistic, but since we've taken more than two years as a community to accept a trivial revision of the software that permits non-administrators to revert vandalism in a single step, and we're still wobbly about that, what possibility does this large-scale and revolutionary change have of ever being accepted on English Wikipedia?
Yes, I'd say you're being unduly pessimistic. Rollback was a trivial, unimportant change that a few people wanted. Flagged revisions is an important, beneficial change that everybody wants. There *is* a difference (I hope).
On 1/14/08, Steve Summit scs@eskimo.com wrote:
Yes, I'd say you're being unduly pessimistic. Rollback was a trivial, unimportant change that a few people wanted. Flagged revisions is an important, beneficial change that everybody wants. There *is* a difference (I hope).
Maybe. Groups of people tend to be highly risk averse. It's to me unproven that decision making processes based on large groups are capable of large scale innovation. This is the one thing that I find disconcerting about the rollback episode: if we need 80%+ of support for everything, how can we ever hope to make changes to the fundamentals, like getting rid of wiki syntax in favor of rich text editing, or implementing a better discussion system?
Sometimes, some people _will_ be unhappy, and sometimes you _will_ have to allow yourself to make a mistake, if you want to be able to also improve.
The problem is that we have been basing changes around the idea of consensus decision making. If you reduce or alter the threshold required for decision making, you are essentially introducing a new principle of authority. This may not be bad, but obviously people will feel disenfranchised to some extent if decisions are taken based on something other than the established metric.
To my mind, an element of leadership is required in order to efficiently manage Wikipedia. Efficiency isn't necessarily a shared goal, however; I would suggest that there are a number of people who view the community and its style of management as an element nearly as crucial as the encyclopedia itself. I think it would be foolish of Wikipedia to ignore the lessons learned about representative leadership of large communities: consensus management works especially well in a small community - as the number of individuals involved expands, consensus becomes harder to reach and other forms of management must be considered.
The method of addressing this problem of organization, which is systemic, is not to ride roughshod over current practices and ignore opposition. Fix the underlying problem first, and we won't have Rollbackersaurus redux.
On Jan 14, 2008 11:12 AM, Erik Moeller erik@wikimedia.org wrote:
On 1/14/08, Steve Summit scs@eskimo.com wrote:
Yes, I'd say you're being unduly pessimistic. Rollback was a trivial, unimportant change that a few people wanted. Flagged revisions is an important, beneficial change that everybody wants. There *is* a difference (I hope).
Maybe. Groups of people tend to be highly risk averse. It's to me unproven that decision making processes based on large groups are capable of large scale innovation. This is the one thing that I find disconcerting about the rollback episode: if we need 80%+ of support for everything, how can we ever hope to make changes to the fundamentals, like getting rid of wiki syntax in favor of rich text editing, or implementing a better discussion system?
Sometimes, some people _will_ be unhappy, and sometimes you _will_ have to allow yourself to make a mistake, if you want to be able to also improve. -- Erik Möller
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: http://lists.wikimedia.org/mailman/listinfo/wikien-l
Persons interested in FlaggedRevs might be interested in the Help Wikihttp://www.pj.tsone.info/helpwiki, a MediaWiki website devoted to working on new versions of Help Guides for Wikipedia, which runs the extension.
Just a thought; feel free to sign up and leave a note at Permissions for the reviewer flag if you'd like to try it out! Cheers, Anthony
User:AGK en.wikipedia.org
On 14/01/2008, Nathan nawrich@gmail.com wrote:
The problem is that we have been basing changes around the idea of consensus decision making. If you reduce or alter the threshold required for decision making, you are essentially introducing a new principle of authority. This may not be bad, but obviously people will feel disenfranchised to some extent if decisions are taken based on something other than the established metric.
To my mind, an element of leadership is required in order to efficiently manage Wikipedia. Efficiency isn't necessarily a shared goal, however; I would suggest that there are a number of people who view the community and its style of management as an element nearly as crucial as the encyclopedia itself. I think it would be foolish of Wikipedia to ignore the lessons learned about representative leadership of large communities: consensus management works especially well in a small community - as the number of individuals involved expands, consensus becomes harder to reach and other forms of management must be considered.
The method of addressing this problem of organization, which is systemic, is not to ride roughshod over current practices and ignore opposition. Fix the underlying problem first, and we won't have Rollbackersaurus redux.
On Jan 14, 2008 11:12 AM, Erik Moeller erik@wikimedia.org wrote:
On 1/14/08, Steve Summit scs@eskimo.com wrote:
Yes, I'd say you're being unduly pessimistic. Rollback was a trivial, unimportant change that a few people wanted. Flagged revisions is an important, beneficial change that everybody wants. There *is* a difference (I hope).
Maybe. Groups of people tend to be highly risk averse. It's to me unproven that decision making processes based on large groups are capable of large scale innovation. This is the one thing that I find disconcerting about the rollback episode: if we need 80%+ of support for everything, how can we ever hope to make changes to the fundamentals, like getting rid of wiki syntax in favor of rich text editing, or implementing a better discussion system?
Sometimes, some people _will_ be unhappy, and sometimes you _will_ have to allow yourself to make a mistake, if you want to be able to also improve. -- Erik Möller
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: http://lists.wikimedia.org/mailman/listinfo/wikien-l
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: http://lists.wikimedia.org/mailman/listinfo/wikien-l
On 14/01/2008, Erik Moeller erik@wikimedia.org wrote:
This is the one thing that I find disconcerting about the rollback episode: if we need 80%+ of support for everything, how can we ever hope to make changes to the fundamentals, like getting rid of wiki syntax in favor of rich text editing, or implementing a better discussion system?
To put it mildly, the community is very conservative and will fight even beneficial technical changes tooth and nail, when those changes are presented as a change of culture. Other changes go through under the radar without discussion. For instance, the introduction of per-edit reverts ("Undo") came in without discussion or controversy, although it made it very easy for any editor to perform reverts that were previously almost impossible to perform because there were more recent edits. Had this quite powerful facility been presented in similar terms to the (arguably much less powerful) rollback feature, I don't think we would have switched it on yet.
As it happens, the developers didn't ask and hardly anybody noticed. Which is as it should be.
On 1/14/08, Erik Moeller erik@wikimedia.org wrote:
if we need 80%+ of support for everything, how can we ever hope to make changes to the fundamentals, like getting rid of wiki syntax in favor of rich text editing, or implementing a better discussion system?
Interesting thought. People talk a lot about a "rich text editing" interface, one that would permit a page to be edited by manipulating shapes on the screen or whatever. I assumed that the interface would then produce matching wiki-text, and then save it as if it had been created "the normal way".
I wasn't aware that anybody envisioned this to be a departure from the existing wiki syntax, which in most situations is much more concise than the rendered html (that which gets sent to the browser when reading the page).
If "getting rid of wiki syntax" means that users/browsers/clients who are unable to use (or do not wish to use) the rich text editor must edit the raw html, it sounds like a bad idea. Granted, maybe you had some other intermediate "proto-markup" in mind, but until I see it I shall have to assume it would only create a needless learning curve with little actual benefit.
One (tangentially related and obviously optional) feature I think would be cool, regardless of whether "rich text editing" is enabled, is a browser plug-in for parsing wiki-text on the client side[1], just as it would for html, except with significantly faster page-loads for users who connect through dial-up or... well... nevermind... ;)
As for the discussion system problem, yes it does seem silly to commit to the database several hundred Kb of wikitext when a user edits WP:AN/I to add a one-line comment (or even just to fix their own typo in a previous edit).
So maybe some forum-like software could be added, but then the garden-variety user might lose the ability to remove blatant trolling from an otherwise sober discussion, and have to wait for assistance from above. So maybe we solve that by designating moderators... more access-level creep... which as we have recently been reminded by the rollback fiasco, would require additional RFA-style voting creep... and maybe we'll want to solve that by handling all "votings" like the board of trustees elections (secret ballots tabulated in some smoky room toward the back)... thereby adding more feature creep to make the voting creep less visible, and to help reduce discussion creep[2]!
Maybe we don't want all that. Maybe it's comforting that discussion and collaborative editing can occur in the same place at the same time.[3]
If user convenience is the primary concern, perhaps a decent compromise would be a less intrusive feature, one which adds a "reply" link next to each signed comment. User submits comment via an initially blank form. Software decides where to insert it and how deeply to indent it. Simple as that[4]. And if it somehow ends up in the wrong place, there will (thankfully) still be an "edit" button up at the top! :)
It is a wiki, after all.
Anybody who's ever had to sift through eleventy-three dozen flavors of stationery in search of a blank sheet would probably agree that general-purpose software has its advantages.
So, Erik, to make a long reply short, extra features like the ones you're talking about need not require 80% support or even 1%, as long as they are optional and fairly self-contained. Of course then people will be at each other's throats debating whether or not something should be "enabled" or "disabled" by default.
—C.W.
[1] "content-type: x-mediawiki" or whatever. [2] And whole-lotta-mostly-redundant-revisions-in-the-database creep, of course ;) [3] The implications of this might not be obvious on the first read. I would try to explain but i'm not sure it's needed. To anticipate every possible type of confused reply is logorrheaic and futile, nevermind that I'll probably be lucky to get any reply at all. [4] Though I'm not aware of one, may be a javascript hack that does this. To take credit for the ideas of others is not my intention.
if we need 80%+ of support for everything, how can we ever hope to make changes to the fundamentals, like getting rid of wiki syntax in favor of rich text editing, or implementing a better discussion system?
The issue there isn't community support, it's development. There is work being done on the parser that might make implementing WYSIWYG possible in the future, but I wouldn't expect it any time soon. Once the feature is implemented, the community can decide whether to use it or not, but it's really a personal choice, so I imagine the developers would just implement it on Wikimedia sites unilaterally and let individuals use it if they like.
On 18/01/2008, Thomas Dalton thomas.dalton@gmail.com wrote:
if we need 80%+ of support for everything, how can we ever hope to make changes to the fundamentals, like getting rid of wiki syntax in favor of rich text editing, or implementing a better discussion system?
The issue there isn't community support, it's development. There is work being done on the parser that might make implementing WYSIWYG possible in the future, but I wouldn't expect it any time soon.
It's actually progressing :-) See http://www.mediawiki.org/wiki/Markup_spec/ANTLR - advantage of [[ANTLR]] is that describing MediaWiki wikitext in it appears mathematically possible (it isn't possible in EBNF), disadvantage is that the compiled parser is presently slooow and it can't replace the present parser without providing almost complete compatibility as fast or faster. This work is mostly being done by Steve Bennett; discussion happens on wikitext-l.
(We presently don't have a defined syntax at all - wikitext is quite literally defined as "whatever the parser does." But we need a defined syntax so that a WYSIWYG editor not only knows what it's writing, but what it's reading. And once we have a defined syntax, 100% compliant reimplementations of the parser in any programming language are possible. Anyone who wants to further this work, please feel free to (a) work on the ANTLR grammar (b) make the PHP rendered by ANTLR faster ;-) )
Once the feature is implemented, the community can decide whether to use it or not, but it's really a personal choice, so I imagine the developers would just implement it on Wikimedia sites unilaterally and let individuals use it if they like.
A good WYSIWYG interface option (where a user can use rich text or raw wikitext) would be the sort of thing to include in MediaWiki by default, I think. Rich text by default, raw wikitext as a user preference. Something like FCKeditor could do a *perfect* job if it only had a defined grammar to work from and to.
- d.
Everybody does not want it. There *are* plenty of dissenters, some of which are actually informed. So it is not that simple.
Also, one of the reasons people opposed rollback was due to the bureaucracy crap. I opposed it as I'd rather it be granted automatically by the software, since all it does is speed up something people can already do.
Steve Summit wrote:
Tonay Sidaway wrote:
On 14/01/2008, David Gerard dgerard@gmail.com wrote:
The FlaggedRevs code shudders forward!
Sorry to be so pessimistic, but since we've taken more than two years as a community to accept a trivial revision of the software that permits non-administrators to revert vandalism in a single step, and we're still wobbly about that, what possibility does this large-scale and revolutionary change have of ever being accepted on English Wikipedia?
Yes, I'd say you're being unduly pessimistic. Rollback was a trivial, unimportant change that a few people wanted. Flagged revisions is an important, beneficial change that everybody wants. There *is* a difference (I hope).
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: http://lists.wikimedia.org/mailman/listinfo/wikien-l
On 14/01/2008, Voice of All jschulz_4587@msn.com wrote:
[flagged revs]
Everybody does not want it. There *are* plenty of dissenters, some of which are actually informed. So it is not that simple.
This is of course why there will be tests and then a live trial on de:wp before anyone else puts it into place. At least we won't be trying to test it on en:wp first.
- d.
On 14/01/2008, Steve Summit scs@eskimo.com wrote:
Flagged revisions is an important, beneficial change that everybody wants.
We don't know if it is beneficial. I would suggest it would be unwise to draw conclusions until we get more information.
On 14/01/2008, Steve Summit scs@eskimo.com wrote:
Flagged revisions is an important, beneficial change that everybody wants. There *is* a difference (I hope).
Well, proof of the pudding, I tried it out on the wikiQA server.
Basically: - it gives semiprotection-like features to an article, but that are permanent, as in a lot of people's edits may not appear for indefinite periods, if people don't feel they are making a contribution, they won't - the UI is confusing (as in the software did weird things that were not obvious, and I'm a software engineer, if it's not obvious to me it's probably a bad idea, if setting an article in a weird mode confuses me, then imagine what joe user would think) - the QA server didn't work as advertised on described features e.g. people didn't get automatically promoted to be able to do QA, but the documentation implied it would happen (a bug or misconfigured) - the QA server gave whole new ways for guys like WillyOnWheels to vandalise
It seems overcomplicated and rather overambitious, and not especially well thought out.
If it ever works it will be because of a whole bunch of extra bots, processes and admin leg work; and a lot more developer graft.
I'd say this could be a disaster; I'm hoping not, but I'm not betting either way.
I'd only use test.wikipedia for testing it, I have no idea how up to date the QA wiki is.
Also, *what* about it is confusing specifically?
Ian Woollard wrote:
On 14/01/2008, Steve Summit scs@eskimo.com wrote:
Flagged revisions is an important, beneficial change that everybody wants. There *is* a difference (I hope).
Well, proof of the pudding, I tried it out on the wikiQA server.
Basically:
- it gives semiprotection-like features to an article, but that are
permanent, as in a lot of people's edits may not appear for indefinite periods, if people don't feel they are making a contribution, they won't
- the UI is confusing (as in the software did weird things that were not
obvious, and I'm a software engineer, if it's not obvious to me it's probably a bad idea, if setting an article in a weird mode confuses me, then imagine what joe user would think)
- the QA server didn't work as advertised on described features e.g.
people didn't get automatically promoted to be able to do QA, but the documentation implied it would happen (a bug or misconfigured)
- the QA server gave whole new ways for guys like WillyOnWheels to
vandalise
It seems overcomplicated and rather overambitious, and not especially well thought out.
If it ever works it will be because of a whole bunch of extra bots, processes and admin leg work; and a lot more developer graft.
I'd say this could be a disaster; I'm hoping not, but I'm not betting either way.
-- -Ian Woollard
We live in an imperfectly imperfect world. If we lived in a perfectly imperfect world things would be a lot better. _______________________________________________ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: http://lists.wikimedia.org/mailman/listinfo/wikien-l
On 14/01/2008, Tony Sidaway tonysidaway@gmail.com wrote:
Sorry to be so pessimistic, but since we've taken more than two years as a community to accept a trivial revision of the software that permits non-administrators to revert vandalism in a single step, and we're still wobbly about that, what possibility does this large-scale and revolutionary change have of ever being accepted on English Wikipedia? http://en.wikipedia.org/w/index.php?title=Wikipedia:Requests_for_rollback&am...
Oh, that's easy. We'll hold a poll on IRC #wikipedia-en-cabal from 23:59 until 00:01 during the World Cup. That should be sufficient to demonstrate binding WP:CONSENSUS.
(I used to joke that "consensus" meant a 7:3 straw poll on an obscure talk page somewhere. [[Talk:Stephen Fry]] shows it as three votes to one.)
- d.