[flomo]

I started doing so, until I realized the only way you could really contribute an article was to enlist for a lifetime of janitorial duty. Otherwise, whatever work you did quickly degenerates into run-on sentences and trivia.

The article's point resonated with me, because it seems that the whole process is based on the assumption that you're a no-lifer who spends all day patrolling Wikipedia.

They advertised themselves as the "open source encyclopedia", but they have not adopted any other concepts from the software development world, such as "quality assurance" and "stable releases".

[binbasti]

They advertised themselves as the "open source encyclopedia", but they have not adopted any other concepts from the software development world, such as "quality assurance" and "stable releases".

Adopting the concept of forking, distributing the whole thing, and making it easy to push and pull in changes from any source would be a great goal.

Someone already started hacking on a tool for converting the dumps to Git repos, which may or may not be a suitable base to build upon: https://github.com/scy/levitation

[flomo]

I'm suggesting a much simpler concept. Article changes shouldn't "go live" until there is consensus that they've passed basic proofreading and quality checks. This would give editors time to review changes in batch rather than feeling like they must monitor everyone else's edits in real time.

(It's interesting to think about, but Wikipedia could never conceptualize distributed branching when they are currently doing the equivalent of developing right on the production server.)

This idea has been discussed many times over the years, but never adopted for whatever reason. My suspicion is the active Wikipedians have this system of scoring Wikipoints for quickly reverting vandalism and bad edits, and don't want a system which encourages actual editing.

[riffraff]

how would they distribute the thing, if not through the dumps? I mean, using an scm to distribute it (I asked the freebase guys the same thing) would save time/bandwidth but it's not a conceptual improvement.

Also, how would forking be useful in any way? It's not like someone can work on a feature that later gets merged into the mainline, right? Could you explain the advantages ?

[binbasti]

Forking would be the key to eliminate the gatekeeper problem, so that for certain topics people could publish their own articles or make changes to existing ones without needing the approval of some opinionated moderator or admin. On the German Wikipedia this problem is so bad that earlier this year we had a really big discussion that even extended from the blogosphere to the major news outlets.

What I mean is that Wikipedia could learn from GitHub how a lot of forks plus easy pull requests can exponentially increase participation and generation of new content while still being able to retain quality.

It's not like someone can work on a feature that later gets merged into the mainline, right?

Why not? You could extend an article or contribute some new articles for a topic, publish the content yourself, and try to get it into the main project. Then on the main site there could be a list of forks, and even a network graph exactly like on GitHub.

[riffraff]

sorry I do not understand: who is in charge of importing the data anyway, if not the gatekeeper?

Also, i mean that the difference with forking source code is that you can work on something that will not get accepted into the mailine, but is useful to you, or your organization.

It does not seem to me that you can have a private wikipedia to which you refer people, it would be useless. Same with forks, if an officially blessed fork does not exist, you get anarchy and all of them become unreliable, cfr the rails foreign key plugins for reference: when strong active and clear leadership miss, projects fade into failure.

OTOH if you just want "easy merge" that does not seem to replace the gatekeeper, you just made him more visibile.

But if I am missing soemthing, I'd be happy to understand :)