
GitHub giveth; Wikipedia taketh away - fern12
https://go-to-hellman.blogspot.com/2018/01/github-giveth-wikipedia-taketh-away.html
======
sshine
Interesting points.

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/](http://oedb.org/ilibrarian/top-7-alternatives-to-wikipedia/)

~~~
fredley
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.

~~~
sshine
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](https://en.wikipedia.org/wiki/Wikipedia:VisualEditor)

~~~
cabalamat
> 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.

------
avian
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.

~~~
MaxBarraclough
It's disheartening enough to see your well-crafted bug-report go unanswered.

------
bArray
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.

------
flixic
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.

~~~
cabalamat
> but the value is in the fact that there is one Wikipedia

Why?

~~~
flixic
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.

~~~
avian
> Single source of truth

[https://en.wikipedia.org/wiki/Wikipedia:Verifiability,_not_t...](https://en.wikipedia.org/wiki/Wikipedia:Verifiability,_not_truth)

------
kawsper
> 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.

------
z3t4
Github is immutable, while Wikipedia is mutable with r/w conflicts and
corruption.

------
gluejar
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!

------
_joe
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.

------
pvdebbe
> most trusted

I don't personally know anyone who actually trusts Wikipedia. Everyone uses it
for sheer laziness, as they admit.

------
mosselman
"...annoyance at the legalistic (and typically white male) Wikipedian."

How are skin color and gender relevant to the article or the point being made?

~~~
dang
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? Since discussions are
highly sensitive to initial conditions, 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](https://news.ycombinator.com/newsguidelines.html)

~~~
mosselman
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.

~~~
dang
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.

