Wikipedia needs an IDE, not a WYSIWYG editor • Hacker News Board

Re: Wikipedia needs an IDE, not a WYSIWYG editor

#61

Post by FireBeyond » Sat, Oct 25, 2014, 3:42 PM UTC

joshvm wrote: post #43

Tomte wrote: post #35

Earlier quoted context omitted.

> editors have gotten into turf wars over articles they feel some sense of ownership over That's exactly what killed my one and only attempt to substantially improve an article (not just typo-fixing and stuff): The two guys with a lot of edits on that page couldn't stand someone else editing "their" article. Sure, they tried to bring up superficial disagreements about the content, but that could have been resolved tr…

You fix it by social engineering. If you go in and blam an entire page, no doubt the original authors will cry foul; it probably took them a fair amount of time, even if what they wrote wasn't particularly good. It's also fairly rude without at least giving them a chance to improve sections. Incremental editing will also give you a far stronger case when they get arsey, particularly if your inclusions are better than…

"It's also fairly rude without at least giving them a chance to improve sections."

To me, this only furthers and enhances problems with ownership. If my first approach to "collaborative editing" is "give the original writers a chance to improve" rather than "collaborate" and "edit", then it only enhances the perception or "reality" that that article belongs to them.

Re: Wikipedia needs an IDE, not a WYSIWYG editor

#62

Post by tim333 » Sat, Oct 25, 2014, 3:47 PM UTC

mxfh wrote: post #48

bjelkeman-again wrote: post #7

Earlier quoted context omitted.

As you say, dealing with the UI is fine. Dealing with the bureaucrats isn't. Having your account banned and your new article marked for spam by a very abrasive person, when trying to add legitimate content, rather than being supported through the maze of rules, as happened to a colleague the other day. That is a problem which stops meaningful content being added.

Editing is smallest issue with Wikipedia. For anybody who does an occasional 5-10 edits per year. The admins leave no moment unused to point out that you're doing something wrong (most likely based on Guideline CA 13, where CA stands for cryptic abbreviation₁) and in a lot of cases you're left to the god will of a single person. The whole appeal system needs to be streamlined, it can't be that there a multiple entry…

I put up another GitLab article for you - the previous was deleted for lack of links indication notability. I linked a couple of TheNextWeb articles that will hopefully do. It's kind of hard work this stuff finding references and the like. (I'm not an admin, just an occasional contributor).

Thinking about those kind of issues I think they could improve the friendliness of the process by sending helpful / apologetic emails along the lines of "Dear Mr X, Sorry we had to take down your article because we need ... blah blah... If you can find the references just click this and do this. Best, Wikipedia team." Rather than the current situation where the article just disappears and there are somewhat cryptic comments under the talk tab. I don't think it would be terribly hard to implement.

Re: Wikipedia needs an IDE, not a WYSIWYG editor

#63

Post by tree_of_item » Sat, Oct 25, 2014, 3:48 PM UTC

gwicke wrote: post #4

tree_of_item wrote: post #2

This isn't really feasible, as Mediawiki's markup is far too hard to parse[0]. You can't just write an IDE for wikitext in a nice language, you'd need to instrument Mediawiki itself somehow to give fine grained information. [0] http://www.cs.rmit.edu.au/adcs2010/proceedings/pdf/paper%204...

Nothing beats being told that what you just did is in fact not feasible ;) Check out this page: https://www.mediawiki.org/wiki/Parsoid This is the bidirectional conversion engine between wikitext and HTML+RDFa that powers VisualEditor and several other tools. It tracks source range to DOM structure correspondence as proposed in the post. At this point, the IDE is basically a user interface and performance problem. Th…

Sure, it claims to do this, but I'm still a bit skeptical that this is actually compliant. What do you make of the paper I linked to? That blog post only glosses things like context-sensitivity.

Re: Wikipedia needs an IDE, not a WYSIWYG editor

#64

Post by mxfh » Sat, Oct 25, 2014, 4:31 PM UTC

tim333 wrote: post #62

mxfh wrote: post #48

Earlier quoted context omitted.

Editing is smallest issue with Wikipedia. For anybody who does an occasional 5-10 edits per year. The admins leave no moment unused to point out that you're doing something wrong (most likely based on Guideline CA 13, where CA stands for cryptic abbreviation₁) and in a lot of cases you're left to the god will of a single person. The whole appeal system needs to be streamlined, it can't be that there a multiple entry…

I put up another GitLab article for you - the previous was deleted for lack of links indication notability. I linked a couple of TheNextWeb articles that will hopefully do. It's kind of hard work this stuff finding references and the like. (I'm not an admin, just an occasional contributor). Thinking about those kind of issues I think they could improve the friendliness of the process by sending helpful / apologetic e…

Thanks for your efforts (though you might have violated some policy, don't ask me), I (User:Diskurs), I already added external sources for review here:

https://en.wikipedia.org/wiki/User_talk:Mark_Arsten#GitLab_....

feel free to add them.

I don't understand were wikipedia's fixation (other than the name and origin) comes from to handle everything as a wiki page, were any kind of ticketing system might be way more transparent.

Re: Wikipedia needs an IDE, not a WYSIWYG editor

#65

Post by gwicke » Sat, Oct 25, 2014, 4:39 PM UTC

tree_of_item wrote: post #63

gwicke wrote: post #4

Earlier quoted context omitted.

Nothing beats being told that what you just did is in fact not feasible ;) Check out this page: https://www.mediawiki.org/wiki/Parsoid This is the bidirectional conversion engine between wikitext and HTML+RDFa that powers VisualEditor and several other tools. It tracks source range to DOM structure correspondence as proposed in the post. At this point, the IDE is basically a user interface and performance problem. Th…

Sure, it claims to do this, but I'm still a bit skeptical that this is actually compliant. What do you make of the paper I linked to? That blog post only glosses things like context-sensitivity.

This depends on the definition of compliant. By the paper's feature-based approach, Parsoid would be 'compliant' with the PHP parser.

There is more to compliance than a simple feature comparison though, most of which can only be identified by large-scale testing. Each night, we have been running tests on a sample of 160k articles from 16 languages to check our progress. In this test setup, 99.99995% of articles round-trip perfectly from wikitext to HTML and back. Currently the focus is on visual diffing to identify remaining rendering differences.

There is still a good amount of work left until Parsoid is ready to replace the PHP parser, but most of this is actually not relevant to you if all you'd like to do is extract semantic information.

Regarding the paper: The authors correctly describe some of the issues inherent in wikitext parsing. Its conclusions are however based on strong assumptions about the implementation strategy. For example, they do not consider the option of flattening a PEG parse tree back to tokens in order to implement context-sensitive and generally unbalanced parts of the syntax. Similarly, the analysis of the parsing complexity seems to assume a lack of transclusion limits.

Re: Wikipedia needs an IDE, not a WYSIWYG editor

#66

Post by tim333 » Sat, Oct 25, 2014, 5:26 PM UTC

mxfh wrote: post #64

tim333 wrote: post #62

Earlier quoted context omitted.

I put up another GitLab article for you - the previous was deleted for lack of links indication notability. I linked a couple of TheNextWeb articles that will hopefully do. It's kind of hard work this stuff finding references and the like. (I'm not an admin, just an occasional contributor). Thinking about those kind of issues I think they could improve the friendliness of the process by sending helpful / apologetic e…

Thanks for your efforts (though you might have violated some policy, don't ask me), I (User:Diskurs), I already added external sources for review here: https://en.wikipedia.org/wiki/User_talk:Mark_Arsten#GitLab_.... feel free to add them. I don't understand were wikipedia's fixation (other than the name and origin) comes from to handle everything as a wiki page, were any kind of ticketing system might be way more tra…

I stuck in the Chicago Trib reference.

>I don't understand were wikipedia's fixation (other than the name and origin) comes from to handle everything as a wiki page

I think that's where a lot of problems come from and I think it's a tech issue that they built a wiki system and used it for everything and it's hard to change now it's ingrained. My guess with your appeal and the links is no one looked at it because it's not like an email system where someone gets it in their inbox, it's more that some one has to check on that page and maybe Bob thinks Joe is doing it or visa versa, perhaps.

Re: Wikipedia needs an IDE, not a WYSIWYG editor

#67

Post by d23 » Sat, Oct 25, 2014, 6:41 PM UTC

> This tension is irresolvable: the terms “WYSIWYG” and “abstraction” are literally antonyms.

Except they aren't. WYSIWYG is an abstraction over the code layer that works in the terms of "bold", "italics" and "underline".

Re: Wikipedia needs an IDE, not a WYSIWYG editor

#68

Post by hnriot » Sat, Oct 25, 2014, 6:51 PM UTC

Tomte wrote: post #53

joshvm wrote: post #43

Earlier quoted context omitted.

You fix it by social engineering. If you go in and blam an entire page, no doubt the original authors will cry foul; it probably took them a fair amount of time, even if what they wrote wasn't particularly good. It's also fairly rude without at least giving them a chance to improve sections. Incremental editing will also give you a far stronger case when they get arsey, particularly if your inclusions are better than…

I tried to improve a very small section, about six or seven sentences. It was clearly wrong, I had lots of citations, but they preferred a wrong "my" article to a better "our article". After the second or third edit, incorporating their feedback, someone called it "vandalism" and reverted everything. Wikipedia is broken.

this hasn't been my experience at all, I guess it depends which areas you're contributing to. I've contributed to CS and art pages, with good success, I stay clear of opinion pages, or contentious topics.

Re: Wikipedia needs an IDE, not a WYSIWYG editor

#69

Post by contingencies » Sat, Oct 25, 2014, 10:38 PM UTC

I must say that Wikipedia community has become very effective at giving partisan editors tools to target undesirable editors - a Byzantine collection of policies which admins overzealously enforce without a second thought, and without thinking of a big picture. Admins in fact are incentivized not to involve themselves, which basically gives the enforcement gun to POV-pushers which are intimately acquainted with all the glorious details of the relevant wikilese. I urge admins to think outside the policy-enforcing request-observing mode.

https://en.wikipedia.org/wiki/User:Ivan_%C5%A0tambuk

Re: Wikipedia needs an IDE, not a WYSIWYG editor

#70

Post by aaron695 » Sun, Oct 26, 2014, 5:43 AM UTC

My understanding is they don't want more idiots editing, it's a 'feature' that it's tricky to edit.

I also considered the decline is that it's kinda 'complete' it's not like the old days where it was easy to contribute something important and meaningful.