5 ms·

Every time this comes up I'm reminded of a very simple idea: fork Wikipedia, in a way that articles still get synced from the original but at the same time dele

by Udo 14y ago

Every time this comes up I'm reminded of a very simple idea: fork Wikipedia, in a way that articles still get synced from the original but at the same time deleted articles just stay in the database. If you want to make it really fancy, put in some code that tries to detect whether parts of an article have been deleted and, when in doubt, keep the old version it live. Maybe there could even be some neat UI that makes it easy to navigate different versions of articles (no, the Wikipedia UI isn't it). I think in time a project like that could become very successful. Keep using Wikipedia as a source, but give new life to the underlying idea that is no longer being taken seriously over there.

maxerickson 14y ago
It would be very interesting to see forking become a core feature of Wikipedia. That way groups with different ideas about how to make the better encyclopedia could directly share the least controversial parts of the thing. (I do think there is quite some chance that nothing much would come of it)
aw3c2 14y ago
a killer feature for me would be coloring text in articles by its age. under the assumption that old = unchanged = good. might be interesting.
- eli 14y ago
  Seems like that would be doable in a browser extension.
- maxerickson 14y ago
  Here are some people fooling with history visualization: http://waxy.org/2005/06/wikipedia_histo/ http://waxy.org/2005/06/wikipedia_histo/ (I have no idea if anything still works, just had some vague memory of it floating around)
Jtsummers 14y ago
I started to type something similar then did some research into the costs. The DB download is 8.8GB, they say it expands to terrabytes when uncompressed. That's no longer an impossibly difficult amount of storage to acquire though. The Wikimedia Foundation budget for this next year is $42.1 million, I only skimmed so I didn't find a breakdown on costs of things like electricity and bandwidth out of that. I like the idea, though wonder how you could gain traction from potential contributors. Would those alienated by the current Wikipedia processes along with some other people interested in the novelty be enough to start a community?
- Udo 14y ago
  The actual infrastructure would probably be relatively cheap (my el-cheapo Hetzner hosting plan has 3TB of space for instance), bandwidth is another matter entirely - such a project would have to be ad supported I think, it's the only thing that scales with the visitor count. Community is a big issue, but it wouldn't necessarily need to be large, especially at first a small band of moderators would be enough. Initially, such a project would base its data off Wikipedia entirely, but over time more things need to be curated. While we're on it, voting on articles and moving discussion threads about them to the forefront might also be worth looking into. Social proof could be one of the mechanisms used to determine the "best" version of an article. I think there are hundreds of parameters worth experimenting with. I guess there are a lot of people alienated by Wikipedia, but the beauty of the idea is that we wouldn't have to rely on that. Incoming links would in time drive most of the traffic to the site, as it would be - by definition - a better place to link to for durable and extensive information. Sounds like a nice idea for a quirky, bootstrapped startup. :)
  - Jtsummers 14y ago
    I like the idea, I wonder if it has to be ad revenue though. I find that idea (personally) distasteful, but don't have any better ideas besides getting donations. Maybe this exists, MediaWiki may even support it. What I'd like to see is a wiki that allowed you to populate articles by crossreferencing other pages. An example: Page: Lisp <tagged as FP> A functional programming language invented in... <Portion marked as summary> Page: Functional Programming <Summary of FP> List of languages in the FP category: <Populated from tagged articles> <Populated from summary in tagged articles> You'd only edit that Lisp summary in one location, then other articles could pull from it as needed. Not sure how well it'd work in practice, and as I said maybe MediaWiki and others support this now. I haven't looked at their features in years. If you initially constructed your wiki from Wikipedia (and maybe other sources), the initial effort would be on removing this redundancy, but you'd still provide as many articles they'd just be better synchronized with each other. Adding breadth (Scheme, Common Lisp, etc) would be straightforward by sharing whole blocks of text. Shorter articles wouldn't be penalized because they'd just be pulled into others via this same cross referencing mechanism. They could be hidden in some fashion to avoid namespace clutter, but outright deletion would be unnecessary. Well that was a braindump, and maybe not as coherent as I thought it would be. This is why I should sleep more, and practice describing my ideas to other people for feedback. EDIT: To continue, a thought I should've included originally, use some form of markup for those pages to autofill parts and maybe autogenerate the summary. A language has a place, person and time of invention. A set of paradigms it may be described as fitting into, a set of parent, children and cousin languages. Marked up, this allows for portions to be very consistent in presentation across pages in a category. I suppose I should look at semantic wikis again. As I said, this was an idea I had years ago and pondered but never really researched. EDIT: Missing newlines.
danielweber 14y ago
I could swear there was a "saved from deletion on Wikipedia" project somewhere. Called something like Deletedopedia.
- Nursie 14y ago
  http://deletionpedia.dbatley.com http://deletionpedia.dbatley.com That seems to archive deleted pages, and does come fairly high up search rankings for some deleted topics.
Nelson69 14y ago
This is exactly the problem... Forking is one solution but wikimedia could spin up forks of its own with different standards and pull from the different sources. Ideally, you could make a wikipedia account and maybe configure which subwikis you wanted to pull from.
a3_nm 14y ago
> put in some code that tries to detect whether parts of an article have been deleted and, when in doubt, keep the old version it live Unlike deleted pages which are hidden from non-admins, deleted parts of articles are almost always reachable if you dig them out in the revision history of the page. The rare exceptions are for text which violates someone's copyright, or which is defamatory, all of which require manual intervention by an admin to be deleted for real. So this content is still archived by Wikipedia, and publicly available, just not very easy to browse.
gojomo 14y ago
Inclusionist 'forks', 'annexes', or 'salvage yards' have been attempted a few times. They usually adopt the same MediaWiki software and general article-format, for familiarity and ease of starting-up. But, since that stack has coevolved with community practices, it is essentially dependent on the same mentalities, content-standards, and critical mass of contributors in order to function at all. A site that's "exactly Wikipedia, but inclusionist" imports many of the stresses and doctrinal limitations that have fed deletionist urges, but without a vibrant-enough seed community to build the full set of alternate practices that inclusionism would allow. Between other projects, I've been working on an alternate kind of reference wiki that I believe can capture more info without as much conflict. Variances from standard Wikipedia/MediaWiki I'm trying are: • all information must be contributed in small capped-size chunks – think about 2-3 times as large as a tweet, or like a Google search result snippet but in complete sentences • community scoring of chunk quality, so that rough/undersourced/needs-improvement material can live on, somewhat out of view, rather than being lost completely to deletion • extensive use of atomic, single-click feedback (upvotes, flags, likes, thanks, etc.) for quick reinforcement/correction loops (learning from Facebook, Quora, Twitter, etc.) Though recent updates are few, you can read more about the plans and progress at my project blog – http://blog.thunkpedia.org http://blog.thunkpedia.org. Following the @thunkpedia twitter handle or otherwise contacting me will get you invited to the beta as soon as it opens.

by Udo 14y ago

maxerickson 14y ago

It would be very interesting to see forking become a core feature of Wikipedia. That way groups with different ideas about how to make the better encyclopedia could directly share the least controversial parts of the thing. (I do think there is quite some chance that nothing much would come of it)

aw3c2 14y ago

a killer feature for me would be coloring text in articles by its age. under the assumption that old = unchanged = good. might be interesting.

eli 14y ago
Seems like that would be doable in a browser extension.
maxerickson 14y ago
Here are some people fooling with history visualization: http://waxy.org/2005/06/wikipedia_histo/ http://waxy.org/2005/06/wikipedia_histo/ (I have no idea if anything still works, just had some vague memory of it floating around)

Jtsummers 14y ago

I started to type something similar then did some research into the costs. The DB download is 8.8GB, they say it expands to terrabytes when uncompressed. That's no longer an impossibly difficult amount of storage to acquire though. The Wikimedia Foundation budget for this next year is $42.1 million, I only skimmed so I didn't find a breakdown on costs of things like electricity and bandwidth out of that. I like the idea, though wonder how you could gain traction from potential contributors. Would those alienated by the current Wikipedia processes along with some other people interested in the novelty be enough to start a community?

Udo 14y ago
The actual infrastructure would probably be relatively cheap (my el-cheapo Hetzner hosting plan has 3TB of space for instance), bandwidth is another matter entirely - such a project would have to be ad supported I think, it's the only thing that scales with the visitor count. Community is a big issue, but it wouldn't necessarily need to be large, especially at first a small band of moderators would be enough. Initially, such a project would base its data off Wikipedia entirely, but over time more things need to be curated. While we're on it, voting on articles and moving discussion threads about them to the forefront might also be worth looking into. Social proof could be one of the mechanisms used to determine the "best" version of an article. I think there are hundreds of parameters worth experimenting with. I guess there are a lot of people alienated by Wikipedia, but the beauty of the idea is that we wouldn't have to rely on that. Incoming links would in time drive most of the traffic to the site, as it would be - by definition - a better place to link to for durable and extensive information. Sounds like a nice idea for a quirky, bootstrapped startup. :)
- Jtsummers 14y ago
  I like the idea, I wonder if it has to be ad revenue though. I find that idea (personally) distasteful, but don't have any better ideas besides getting donations. Maybe this exists, MediaWiki may even support it. What I'd like to see is a wiki that allowed you to populate articles by crossreferencing other pages. An example: Page: Lisp <tagged as FP> A functional programming language invented in... <Portion marked as summary> Page: Functional Programming <Summary of FP> List of languages in the FP category: <Populated from tagged articles> <Populated from summary in tagged articles> You'd only edit that Lisp summary in one location, then other articles could pull from it as needed. Not sure how well it'd work in practice, and as I said maybe MediaWiki and others support this now. I haven't looked at their features in years. If you initially constructed your wiki from Wikipedia (and maybe other sources), the initial effort would be on removing this redundancy, but you'd still provide as many articles they'd just be better synchronized with each other. Adding breadth (Scheme, Common Lisp, etc) would be straightforward by sharing whole blocks of text. Shorter articles wouldn't be penalized because they'd just be pulled into others via this same cross referencing mechanism. They could be hidden in some fashion to avoid namespace clutter, but outright deletion would be unnecessary. Well that was a braindump, and maybe not as coherent as I thought it would be. This is why I should sleep more, and practice describing my ideas to other people for feedback. EDIT: To continue, a thought I should've included originally, use some form of markup for those pages to autofill parts and maybe autogenerate the summary. A language has a place, person and time of invention. A set of paradigms it may be described as fitting into, a set of parent, children and cousin languages. Marked up, this allows for portions to be very consistent in presentation across pages in a category. I suppose I should look at semantic wikis again. As I said, this was an idea I had years ago and pondered but never really researched. EDIT: Missing newlines.

danielweber 14y ago

I could swear there was a "saved from deletion on Wikipedia" project somewhere. Called something like Deletedopedia.

Nursie 14y ago
http://deletionpedia.dbatley.com http://deletionpedia.dbatley.com That seems to archive deleted pages, and does come fairly high up search rankings for some deleted topics.

Nelson69 14y ago

This is exactly the problem... Forking is one solution but wikimedia could spin up forks of its own with different standards and pull from the different sources. Ideally, you could make a wikipedia account and maybe configure which subwikis you wanted to pull from.

a3_nm 14y ago

> put in some code that tries to detect whether parts of an article have been deleted and, when in doubt, keep the old version it live Unlike deleted pages which are hidden from non-admins, deleted parts of articles are almost always reachable if you dig them out in the revision history of the page. The rare exceptions are for text which violates someone's copyright, or which is defamatory, all of which require manual intervention by an admin to be deleted for real. So this content is still archived by Wikipedia, and publicly available, just not very easy to browse.

gojomo 14y ago

Inclusionist 'forks', 'annexes', or 'salvage yards' have been attempted a few times. They usually adopt the same MediaWiki software and general article-format, for familiarity and ease of starting-up. But, since that stack has coevolved with community practices, it is essentially dependent on the same mentalities, content-standards, and critical mass of contributors in order to function at all. A site that's "exactly Wikipedia, but inclusionist" imports many of the stresses and doctrinal limitations that have fed deletionist urges, but without a vibrant-enough seed community to build the full set of alternate practices that inclusionism would allow. Between other projects, I've been working on an alternate kind of reference wiki that I believe can capture more info without as much conflict. Variances from standard Wikipedia/MediaWiki I'm trying are: • all information must be contributed in small capped-size chunks – think about 2-3 times as large as a tweet, or like a Google search result snippet but in complete sentences • community scoring of chunk quality, so that rough/undersourced/needs-improvement material can live on, somewhat out of view, rather than being lost completely to deletion • extensive use of atomic, single-click feedback (upvotes, flags, likes, thanks, etc.) for quick reinforcement/correction loops (learning from Facebook, Quora, Twitter, etc.) Though recent updates are few, you can read more about the plans and progress at my project blog – http://blog.thunkpedia.org http://blog.thunkpedia.org. Following the @thunkpedia twitter handle or otherwise contacting me will get you invited to the beta as soon as it opens.