User talk:PeerInfinity

Hi, welcome to the LessWrong Wiki, and thanks for your edit to the User:PeerInfinity page. Please leave a message on my talk page if I can help with anything, and feel free to email if that doesn't work. You might like to read discussion of this wiki on LessWrong itself. -- BJR (Talk) 21:30, 9 April 2009

You are an admin

I hope none of you mind, I have made all of you admins. The current list of user accounts and now of admins is A soulless automaton, AnnaSalamon, BJR, Ciphergoth, Gjm11, PeerInfinity, Yvain. This means you can delete pages and block users among other things; see Help:Administrators' how-to guide for more information. I've done a lot of editing on Wikipedia so I know a little, but I've never been an admin before; still, let me know if I can help with anything. Also let me know if you prefer not to be an admin, and I can turn it off again. Thanks for all your productive edits, I think it's going well. Paul Crowley (ciphergoth) 22:30, 13 April 2009 (UTC)

Peer, it was decided that you shouldn't create wiki pages for the articles/blog posts/etc., only for the concepts. Vladimir Nesov 17:24, 6 May 2009 (UTC)

Sorry, I'll stop creating pages for articles/blog posts/etc. ...though I still don't actually understand why we decided not to create wiki pages for articles. --PeerInfinity 17:40, 6 May 2009 (UTC)

What are your reasons for creating these pages? What I saw so far is boilerplate that doesn't make life easier in any way. If there is something to say about an article, it can as well be said in a related concept page. Although I still disagree that the concept pages should be necessarily kept short, I understand that realistically, doing otherwise would not be feasible in the near future. Vladimir Nesov 17:47, 6 May 2009 (UTC)

I agree that The boilerplates that were created so far are entirely useless. The wiki pages for the articles won't actually be useful until we start adding more information to them.

For example:

• • • • category tags for the article's topics (these could be automatically generated from the Less Wrong's article's tags, and manually updated later if necessary)
      • a list of articles that the article refers to, used for automatically generating the dependency graph. A list of the articles and concepts that an article refers to could be automatically generated, but someone would still need to manually specify what each of the links is, for example: "Required Reading", "Side-Topic", or "Supplementary Reading".
      • short, probably one-line summaries of the articles. These of course would need to be written manually, not automatically generated.

Once this information is filled in for the articles, I can then make a script to read the tags from the wiki pages, and automatically generate the dependency graphs.

The purpose of the dependency graphs is to graphically show which articles you have to read first, in order to understand a specific article.

Though it doesn't necessarily need to be graphical. Even a text-only dependency tree could be just as useful.

Also, not that it really matters, but must of the article boilerplates were originally created by User:MrHen, not me.

Actually, after further consideration, I agree that it would make more sense to put all of this information on the concept pages, not the article pages. It's the concepts that really matter, not the individual articles about the concepts.

Still, the method to implement this that would make the most sense to me is to go ahead and create separate wiki pages for each article, and transclude the appropriate information from the article pages to the concept pages. That way, you can avoid duplicating content if, for example, an article introduces more than one concept. It would also make sense to show dependency graphs for the articles themselves. The dependency graph for a concept would then be the shortest dependency graph among the articles that attempt to define the concept.

If you don't want to clutter up the main namespace with pages about articles, we could set up a separate namespace for the article pages.

Perhaps the appropriate thing to do would be for me to set up an experimental version of this system on a sandbox wiki at acceleratingfuture.com, and then let everyone else decide if we want to implement this system on the main Less Wrong wiki, once we can see what the results would actually look like.

For more information about what I was planning for the dependency graphs, see the "Dependency Graphs" section on the How We Can Use This Wiki page.

--PeerInfinity 18:28, 6 May 2009 (UTC)

"The purpose of the dependency graphs is to graphically show which articles you have to read first, in order to understand a specific article. " -- a major point of the wiki format is to get away from these rigid models and to allow reading the material on-demand, checking out only the concepts you don't understand enough, depending on your own unique background. How do you know that having the dependency graphs is actually useful to enough people? Vladimir Nesov 20:19, 6 May 2009 (UTC)

I don't actually know if these graphs will be useful to enough people to make it worth the effort to generate them. It was just an idea I had, which I may have gotten irrationally attached to. (digression: does this particular bias have an official name yet? Coming up with an idea that sounds brilliant at first, but turns out to not be what everyone else actually wants, and then being reluctant to abandon the idea?) Do you think it would be worthwhile to set up a poll to find out how many other people think the dependency graphs are a worthwhile idea? Or would everyone prefer if I just drop this whole idea? --PeerInfinity 20:33, 6 May 2009 (UTC)

There is also a cost to the users, not just to the contributors. The pages become more cluttered, there is an additional level of indirection is some places, and there is an additional administrative overhead on the contributors who don't care about this feature. As for the poll, I'm pretty sure you'll lose, though I'm not certain. --Vladimir Nesov 20:40, 6 May 2009 (UTC)

Point taken. If I was really serious about implementing these dependency graphs, the next idea that comes to mind is to create a separate wiki for this purpose, but that doesn't seem worthwhile either. For now I'll just drop the whole idea of the dependency graphs. Sorry again for all the trouble I caused. --PeerInfinity 21:39, 6 May 2009 (UTC)

I don't think autogenerated or large scale dependency graphs are worth the effort either. Navigation aids/study guides for OB/LW would be useful, but I think they should take the form of handmade reading lists or series guides. BJR 21:50, 6 May 2009 (UTC)

Wiki dumps

Hi, On Matt's request I've setup a daily cron task to run the backupDump script on this wiki. You can download the gzipped xml file at: http://wiki.lesswrong.com/wiki.lesswrong.xml.gz --Wmoore 05:21, 11 August 2009 (UTC)

Thanks :) --PeerInfinity 13:12, 11 August 2009 (UTC)

User pages in bulk

Peer, as a rule of thumb, please don't add any content that could be auto-generated. LW Username wiki articles are for an occasion when you have something to add, for example linking to the person's blog, if it's of interest on LW. One can get to a person's LW page through an equal number of clicks without a wiki article, by going to the blog post and clicking on author's name. --Vladimir Nesov 17:45, 8 September 2009 (UTC)

But someone already created links to these pages. Are you saying that you would prefer to leave these as red links to pages that don't exist? For example, http://wiki.lesswrong.com/wiki/Special:WhatLinksHere/Jimrandomh --PeerInfinity 17:53, 8 September 2009 (UTC)

Exactly. The links are there so that if someone has something to say about the person, all the mentions of blog posts by them will automatically link to that content. If a link is red, people won't follow it. If a link is green, and people find that the target page is empty, it is a negative experience that reduces the expectation of interesting info (quality of the wiki). Admittedly, in this case the damage is minimal, but take enough steps and it starts to look bad. We don't want to move in the direction of a maze of empty auto-generated or almost-empty stub pages among which it's hard to find anything meaningful. --Vladimir Nesov 18:11, 8 September 2009 (UTC)

Ok. I would prefer a solution that doesn't involve red links, but I agree that making a stub page could be worse than leaving red links. --PeerInfinity 18:20, 8 September 2009 (UTC)

Script Friendliness

We should set up a process for your automatic (systematic) changes to the wiki, especially to its content: if you want to enforce a new rule, first discuss it, and only then start enforcing. For example, you can start this process by adding a note to the Projects and Requests page and leaving, say, a week's notice. --Vladimir Nesov 21:14, 24 October 2009 (UTC)

Good idea. I should have thought of that. I'll do that from now on. --PeerInfinity 21:56, 24 October 2009 (UTC)

Seriously, where are these summaries coming from? I don't like most of them, do I have to manually review them all now? And symmetric "see also" is just a bad, bad idea in almost all cases. --Vladimir Nesov 21:23, 24 October 2009 (UTC)

I really should have kept track of where each of these summaries all came from. Almost all of them came from either the wiki, or from Eliezer's own summaries in the Less Wrong blog posts where he summarized all of the posts in a sequence. The summaries are colledted in Less Wrong/Article summaries. You can review them if you want, but if we're not going to do any automating, then you probably don't need to review them. And I see now that the symmetric "see also" links is a bad idea. Sorry again for all the trouble I caused. --PeerInfinity 21:56, 24 October 2009 (UTC)

After a second look, I think it will be simpler to just revert this batch of summary/see also edits and maybe try again later after the process is sorted out. --Vladimir Nesov 21:40, 24 October 2009 (UTC)

Ok, go ahead and revert the whole batch of summary and see also changes. Or I can revert them if you want.--PeerInfinity 21:56, 24 October 2009 (UTC)

For more constructive feedback: summaries may be useful, but any propagation of info should be reviewable. When edits are manual, it's normally possible to keep up. If you suddenly copy a lot of info, it becomes impossible. Thus, for example, we can set up a workflow for writing up and reviewing the summaries: a status tags for quality control "done" that is set manually be a person who thinks the summary is good and that needs to stay undisputed for a while, after which the summary can be tentatively propagated, but again in small enough batches for manual review to remain feasible. I stopped following "summaries" and "all articles" precisely because there is too much chatter on the channel, and it's not clear what these are for in the first place. If motivation and workflow are more visible, the same work can be done, and better. --Vladimir Nesov 23:12, 24 October 2009 (UTC)

Btw, we have the same problem here as with preserving article quality and collapse of Transhumanist wiki: you are accumulating a lot of raw material, which sets a low mean and thus lowers motivation to ever improve it. It's a psychological effect not necessarily reflecting usefulness of this "raw material", but it's not clear what to do about that, up to a point of maybe setting up another ghost copy of all the summary pages, based on current "raw material", with "done" summaries segregated into the "official" copy, requiring review only on that. --Vladimir Nesov 23:21, 24 October 2009 (UTC)

Which brings us whole circle back to having the blog post pages: right now, there are two huge lists of posts, and above I practically suggested a third that is to have content disjoint with the second: when a "done" summary appears, the draft summary should be removed anyway. On the wiki, it all is more naturally achieved using wiki pages. These pages, to distinguish them from normal pages, could be segregated under a scope of their own, like "Post:Name-of-the-post". Their content can be strictly regulated by a template, and scripts can autogenerate a summary table linking to them (I find it useful for looking things up; such a summary page, if completely autogenerated, will be easy to support). Maybe it should be brought up on e-mail discussion among the usual suspects. It seems to be a step in the right direction from what we have, another question is whether it's fine that we do have what we have. --Vladimir Nesov 23:36, 24 October 2009 (UTC)

Hmm... Or it could be just one page with template-ed content, and multiple views generated by showing the templates from the editable page under the right flags. That may be more elegant, in that it won't create a whole lot of new pages and won't require scripts. It may even be possible to include the summary snippets in the blog posts automatically using templates, but that needs a bit of research. --Vladimir Nesov 23:38, 24 October 2009 (UTC)

Yes, if we had separate wikipages for every blog post, then it would be a whole lot simpler to use templates to transclude the content from one page to another, and to generate tables, etc. This was the first idea I had for how to set up the wiki, but Eliezer vetoed it. I should review his explanation of why this would be a really bad idea, in case the current setup has the same issues.

As for the summary pages, another option is to just keep it all on one page, but have a tag to mark the summaries as not approved yet, and set up the script to not use any summaries that have this tag.

If you have a clear idea of a different way to set things up, I'll let you email Eliezer and the others to discuss the idea, otherwise it would probably be simplest to just leave things as they are now.

Another random question: Is the Less Wrong Wiki Concept Graph of any use at all? Can you think of any changes you would like made to it? - an applet that shows a graph of all the concepts on the Less Wrong Wiki, constructed from the "See also" links. WARNING: This will take a long time to load, and may crash your browser

--PeerInfinity 00:17, 25 October 2009 (UTC)