GitHub giveth; Wikipedia taketh away(go-to-hellman.blogspot.com)
go-to-hellman.blogspot.com
GitHub giveth; Wikipedia taketh away
https://go-to-hellman.blogspot.com/2018/01/github-giveth-wikipedia-taketh-away.html
41 comments
Is editing Wikipedia easy? Although I'll agree it's a lot easier than pushing to GitHub, it's still way beyond the skills of the average Wikipedia reader. Click Edit on any article. It's a mess of opaque syntax, presented in a textbox. Above the textbox are two different warning paragraphs, one because I'm not logged in and another warning against copyright. Any casual user who clicked Edit out of a genuine desire to improve the article would probably just click away.
I would say the ease of editing needs to be much better than GitHub or current Wikipedia. A decent, WYSIWYG editor (with a Markdown mode, don't panic) with tools to make adding citations etc. possible for mortal users.
I would say the ease of editing needs to be much better than GitHub or current Wikipedia. A decent, WYSIWYG editor (with a Markdown mode, don't panic) with tools to make adding citations etc. possible for mortal users.
Wikipedia has had a visual editor for years. [1] But in both cases of Wikipedia and GitHub, not having to use specialized, stand-alone applications or syntax is only part of the complexity.
The two warnings are most certainly meant to discourage casual editors because of the risk of vandalism or subjective contributions. It is ambivalent to first encourage editing and then scare a number of people off afterwards.
> the ease of editing needs to be much better
I completely agree. And, as the article points out, with a heavy focus on revising the reward mechanism. And, if you ask me, with a focus on ownership. Perhaps categories of articles can be owned by groups/tags in which one can earn access and ownership. Just as when you earn enough points answering questions on StackOverflow with a certain tag, you can become a moderator for that tag.
[1]: https://en.wikipedia.org/wiki/Wikipedia:VisualEditor
The two warnings are most certainly meant to discourage casual editors because of the risk of vandalism or subjective contributions. It is ambivalent to first encourage editing and then scare a number of people off afterwards.
> the ease of editing needs to be much better
I completely agree. And, as the article points out, with a heavy focus on revising the reward mechanism. And, if you ask me, with a focus on ownership. Perhaps categories of articles can be owned by groups/tags in which one can earn access and ownership. Just as when you earn enough points answering questions on StackOverflow with a certain tag, you can become a moderator for that tag.
[1]: https://en.wikipedia.org/wiki/Wikipedia:VisualEditor
> Wikipedia has had a visual editor for years.
Also, it is not the lack of a visual editor that turned Wikipedia editors away. It was the projects anal notability policies. The number of wikipedia editors peaked in 2007-2008, long before the visual editor existed.
Also, it is not the lack of a visual editor that turned Wikipedia editors away. It was the projects anal notability policies. The number of wikipedia editors peaked in 2007-2008, long before the visual editor existed.
> Click Edit on any article. It's a mess of opaque syntax, presented in a textbox.
They've had visual editing for years: https://imgur.com/a/mnePe
They've had visual editing for years: https://imgur.com/a/mnePe
But that's not what's presented by default. I just tried again and got a popup asking me to switch (not sure why that didn't show up first time around), but the default button for the popup ('Start Editing') takes you to the old interface.
I just tried in a private window, and got this: https://imgur.com/a/isTAw
I guess this just proves OP's point: Wikipedia has been struggling to introduce visual editing because the current editing userbase rejected it.
I guess this just proves OP's point: Wikipedia has been struggling to introduce visual editing because the current editing userbase rejected it.
Also, getting the visual editor back once you say no thanks doesn't seem trivial. I had to look up how.
My guess is that regular contributors hardly use it, and its purpose is mostly symbolic rather than practical.
My guess is that regular contributors hardly use it, and its purpose is mostly symbolic rather than practical.
How I would love to see the data on how many edits submitted from the WYSIWYG tool are/aren't reverted.
Slightly less than with the text editor: https://meta.wikimedia.org/wiki/Research:VisualEditor%27s_ef...
> The drawback of GitHub is not just that pull-requests must be accepted by authorized users, but also the bureaucracy of learning version control. Compared to Wikipedia, anyone with domain knowledge can hit "Edit" and add their bit.
Editing from the site is incredibly simple.
Browse to a file, click `edit` and make your changes. Then at the bottom of the page, give a commit message and click "Propose file change".
Editing from the site is incredibly simple.
Browse to a file, click `edit` and make your changes. Then at the bottom of the page, give a commit message and click "Propose file change".
Indeed. I've had non-technical content writers feeling comfortable adding files directly to GitHub and writing Markdown in the them. Basically using it as a CMS.
Pull Requests and Branching remained confusing issues for them though.
Pull Requests and Branching remained confusing issues for them though.
> Most popular alternatives to Wikipedia, commercial and non-commercial, work with ownership of articles, or a stricter editorial policy.
I'm currently doing an inclusionist fork of Wikipedia -- http://www.wikifork.org/mw/index.php/Main_Page . Wikifork (when I get it up and running) will have much looser policies on notability than Wikipedia has.
I'm currently doing an inclusionist fork of Wikipedia -- http://www.wikifork.org/mw/index.php/Main_Page . Wikifork (when I get it up and running) will have much looser policies on notability than Wikipedia has.
Github has an Edit button, too. It will automatically fork the repo, make a commit, and then create a pull-request. Very handy.
Why don't you just open an empty repo, and start accepting pull requests. See what happens.
I wonder how many times the author spent time making a nice GitHub pull request for a popular repo. You know, taking care that you match the coding style, document your changes and reasons for them, make sure the CI tests pass, etc. only to see it sit in the tracker for months without anyone merging it or commenting. Then after a year or two, when you already forgot about it, you get a mail that someone closed your ticket for being outdated or not merging cleanly (to the master that had a year worth of work done on it since you last looked)
GitHub can be a source of bitter disappointment and annoyance just like Wikipedia.
GitHub can be a source of bitter disappointment and annoyance just like Wikipedia.
It's disheartening enough to see your well-crafted bug-report go unanswered.
This point now referenced in the article.
I agree with @Vorticalbox in the comments:
>(and typically white male) that is an unnecessary comment. Sex or gender, >even if they are the majority, has very little to do with the way wiki works. > >Even the minority groups will act the same way.
I would go further and say that it probably depends on what article you are editing as to what gender/ethnicity causes "disappointment and annoyance". I have no idea why it is suddenly popular (and not disputed) to make remarks like this in otherwise good articles.
That said, I think some of the ideas in this blog are not correct. One of Wikipedia's benefits is that it is consolidated into one effort, rather than many forks and a major distributed effort. Also as a number of comments have suggested, PR's can sit for a while before being rejected depending on how active a repository is. Other than having to use wiki markup (which in my opinion is confusing and terrible), there's a reasonably low entry barrier for contributers to jump over. Expecting people to use a form of Git (even with a UI) could end up being a lot of hassle.
>(and typically white male) that is an unnecessary comment. Sex or gender, >even if they are the majority, has very little to do with the way wiki works. > >Even the minority groups will act the same way.
I would go further and say that it probably depends on what article you are editing as to what gender/ethnicity causes "disappointment and annoyance". I have no idea why it is suddenly popular (and not disputed) to make remarks like this in otherwise good articles.
That said, I think some of the ideas in this blog are not correct. One of Wikipedia's benefits is that it is consolidated into one effort, rather than many forks and a major distributed effort. Also as a number of comments have suggested, PR's can sit for a while before being rejected depending on how active a repository is. Other than having to use wiki markup (which in my opinion is confusing and terrible), there's a reasonably low entry barrier for contributers to jump over. Expecting people to use a form of Git (even with a UI) could end up being a lot of hassle.
Wikipedia is like blockchain; sure you can fork it but the value is in the fact that there is one Wikipedia. That makes a lot of the problems worse.
> but the value is in the fact that there is one Wikipedia
Why?
Why?
Single source of truth. It would be too easy to split into "alternative facts" if people could successfully establish alternative Wikipedias.
Of course, seeing the direction the world is going, this may happen.
Also, while seeing the benefit of single Wikipedia, I also think it could benefit from larger number of pages about less important topics, not being that strict on what can and can't be a page topic. Extended Wikipedia of sorts.
Of course, seeing the direction the world is going, this may happen.
Also, while seeing the benefit of single Wikipedia, I also think it could benefit from larger number of pages about less important topics, not being that strict on what can and can't be a page topic. Extended Wikipedia of sorts.
> Single source of truth
https://en.wikipedia.org/wiki/Wikipedia:Verifiability,_not_t...
https://en.wikipedia.org/wiki/Wikipedia:Verifiability,_not_t...
> It would be too easy to split into "alternative facts" if people could successfully establish alternative Wikipedias.
Bear in mind that Wikipedia isn't the only website out there! But you make an interesting point about how authoritative it is perceived.
> I also think it could benefit from larger number of pages about less important topics, not being that strict on what can and can't be a page topic. Extended Wikipedia of sorts.
I agree, that's why I'm doing WikiFork.
Bear in mind that Wikipedia isn't the only website out there! But you make an interesting point about how authoritative it is perceived.
> I also think it could benefit from larger number of pages about less important topics, not being that strict on what can and can't be a page topic. Extended Wikipedia of sorts.
I agree, that's why I'm doing WikiFork.
> But I imagine that new and old contributors get some satisfaction when their contribution get "merged into master", no matter how much that sounds like yielding to the hierarchy.
I spent one day in my weekend upgrading a couple of Rubygems to be compatible with Ruby 2.5 after some things were deprecated. One of the authors just closed my PR, left no comments, and committed his own changes to master. His solution was a little bit different than my own, but he was able to commit to my branch.
A "Thank you", or a "Hey! I did not know that it was deprecated in 2.5, thanks!" would have been appreciated, and I felt a bit miffed even though it is not a big thing.
I spent one day in my weekend upgrading a couple of Rubygems to be compatible with Ruby 2.5 after some things were deprecated. One of the authors just closed my PR, left no comments, and committed his own changes to master. His solution was a little bit different than my own, but he was able to commit to my branch.
A "Thank you", or a "Hey! I did not know that it was deprecated in 2.5, thanks!" would have been appreciated, and I felt a bit miffed even though it is not a big thing.
Github is immutable, while Wikipedia is mutable with r/w conflicts and corruption.
Thanks for the comments, folks. Apparently this post is too controversial or off-topic (or maybe just deemed silly) for Hacker News - it's been removed from the ranking!
When you people will be able to scale git to accept the number of revisions Wikipedia has, and add several new ones per second with millisecond latencies, please let me know.
Also, only a programmer could think git is a friendlier interface than a wiki.
There are things that are wrong in the wiki comunity, none of which would be solved by using github instead.
Not to point out that the forking model would lead to fragmentation and GitHub is actually a privately owned for-profit platform, of course.
Also, only a programmer could think git is a friendlier interface than a wiki.
There are things that are wrong in the wiki comunity, none of which would be solved by using github instead.
Not to point out that the forking model would lead to fragmentation and GitHub is actually a privately owned for-profit platform, of course.
> most trusted
I don't personally know anyone who actually trusts Wikipedia. Everyone uses it for sheer laziness, as they admit.
I don't personally know anyone who actually trusts Wikipedia. Everyone uses it for sheer laziness, as they admit.
"...annoyance at the legalistic (and typically white male) Wikipedian."
How are skin color and gender relevant to the article or the point being made?
How are skin color and gender relevant to the article or the point being made?
Would you please not pick the most inflammatory and off-topic bit of an article and drag it in here to start a flamewar with? Threads are highly sensitive to initial conditions, so you can do a lot of damage this way.
This is covered by the following site guideline: Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. https://news.ycombinator.com/newsguidelines.html
This is covered by the following site guideline: Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. https://news.ycombinator.com/newsguidelines.html
Firstly, I am fine with you collapsing my comment. The following is just an addition to why I think it is somewhat relevant:
The author claims that there are social constructs in place at wikipedia that lead to a bad working environment for contributors. There is not evidence provided to support this, but there is this offhand sexist and racist comment that gives insight into the way in which this author processes information around him/her. I find this a relevant bit of information for evaluating the merit of the article.
What if you have an article with the title "SpaceX doomed to fail" "SpaceX could never succeed, their goals are unrealistic and they haven't done enough research.... The earth (which is flat by the way)..."
Attacking the author on his flat earth believes would be a no go according to that policy, but it does provide information about the value of the author as a credible source.
The author claims that there are social constructs in place at wikipedia that lead to a bad working environment for contributors. There is not evidence provided to support this, but there is this offhand sexist and racist comment that gives insight into the way in which this author processes information around him/her. I find this a relevant bit of information for evaluating the merit of the article.
What if you have an article with the title "SpaceX doomed to fail" "SpaceX could never succeed, their goals are unrealistic and they haven't done enough research.... The earth (which is flat by the way)..."
Attacking the author on his flat earth believes would be a no go according to that policy, but it does provide information about the value of the author as a credible source.
That's a good argument actually. I don't think it outweighs the fire hazard concern. In fact I'm sure it doesn't, because there's little chance the audience will react to the subtleties of what you're observing (especially if you don't say any of them to begin with!)—but only to the bait effect, and then we go down the same old spiral.
We've entered a new age of racism and sexism, where as long as whatever group you're targeting is perceived to be 'privileged', it's okay to be hateful and divisive.
IMO there's a simple rule of thumb. If you can't replace 'white male' with some other group without the statement becoming incredibly offensive to you, you probably shouldn't say it. E.g., I sincerely doubt the author would be okay with saying "(and typically female)" or "(and typically black)" in nearly any context, so I fail to see why he/she feels this is okay.
IMO there's a simple rule of thumb. If you can't replace 'white male' with some other group without the statement becoming incredibly offensive to you, you probably shouldn't say it. E.g., I sincerely doubt the author would be okay with saying "(and typically female)" or "(and typically black)" in nearly any context, so I fail to see why he/she feels this is okay.
In particular, are Wikipedians generally more white or male than GitHub users?
It read like low hanging identity politics fruit. I stopped reading after that statement.
Does the author have any evidence that's it's typically white males?
Is the author implying that white males are to blame for draconic / legalistic Wikipedia?
Has the author proven that draconic wikipedia editting is a bad thing?
Does the author show, in a mere three words) that they're both racist and sexist? (answer: yes).
I like how the author negates the entire point of their article just by casually mentioning thier unproven, unfounded bias. This person's thoughts are not worth anybody's time.
Is the author implying that white males are to blame for draconic / legalistic Wikipedia?
Has the author proven that draconic wikipedia editting is a bad thing?
Does the author show, in a mere three words) that they're both racist and sexist? (answer: yes).
I like how the author negates the entire point of their article just by casually mentioning thier unproven, unfounded bias. This person's thoughts are not worth anybody's time.
hh3k0(2)
Most popular alternatives to Wikipedia, commercial and non-commercial, work with ownership of articles, or a stricter editorial policy. [1] This includes Scholarpedia, Citizendium, Conservapedia. It comes at the cost of volume and recency. In a sense, Wikipedia deals with all the advantages and disadvantages of modern, free democracy.
An aspect that the article seems to miss is the different demographics of Wikipedia and GitHub. (There are a lot fewer high-schoolers vandalizing GitHub repositories out of boredom.) The drawback of GitHub is not just that pull-requests must be accepted by authorized users, but also the bureaucracy of learning version control. Compared to Wikipedia, anyone with domain knowledge can hit "Edit" and add their bit.
I would rather like to see a synthesis of StackOverflow's point system, so the quality of your contributions grants you privileges for certain sections of the site, applied to wiki articles.
Another difference for comparison between GitHub/StackOverflow and Wikipedia is that you have ownership of your contributions. I occasionally go back and revise the most popular StackOverflow answers I've made for posterity. It's been years since I last made a change to one of my Wikipedia contributions. The last I remember was that someone had restructured a part of an article I'd written from scratch and added wrong information.
[1]: http://oedb.org/ilibrarian/top-7-alternatives-to-wikipedia/