User talk:SignpostMarv Martin/Archive 1

Wiimote

I dig your ideas about the wiimote!

This might help out a lot -- and it should work with more than just the wiimote!

GlovePIE Input Emulator The previous unsigned comment was made by Kamilion Schnook

Thanks :-) Another notable reference for the Wiimote itself is Wii Brew

SignpostMarv Martin 07:22, 9 January 2007 (PST)

Thanks!/re: redirects

Hi! First let me say "thanks!" for the great work you're doing so far. Re: redirects/deletion policy (on User Talk:Rob Linden), I'm going to have to give a short answer for now. Using redirects is the right way to "delete" an article. I don't have time to get into detailed answers on this right now, but check out the many debates that have happened on Wikipedia on this same subject. I think I can re-engage in this conversation in a couple of weeks if you need further clarification. Thanks, Rob Linden 10:56, 11 January 2007 (PST)

Thankie, and you're welcome ^_^

I look forward to discussing it with you :-)

SignpostMarv Martin 11:18, 11 January 2007 (PST)

New home page deployed

I've deployed your suggested homepage. I'm also going to leave the template blocks unprotected for now, and unprotect the home page..let's see how that works. Please watch these like a hawk, they're some of the biggest vandalism targets. Thanks -- Rob Linden 14:05, 11 January 2007 (PST)

SLURL

I've created a template at template:simpleslurl. Wondering if we should use it for the basic slurl and move your complete slurl template to Template:fullslurl or something similar? I'm happy with leaving things how they are now as well. -- Baba Yamamoto 18:10, 12 January 2007 (PST)

I've almost finished fixing Template:SLurl so it'll be an all-purpose template with full support for the options.

SignpostMarv Martin 18:14, 12 January 2007 (PST)

Yeah i've seen it :) It's pretty nice. I was trying to avoid having to name variables with mine though. I think you could do it both ways, so that might be the better course. without named variables your template could handle {{{1}}} {{{2}}} {{{3}}} etc..

--Baba Yamamoto 18:17, 12 January 2007 (PST)

The problem with not using named variables is that you have to keep to a strict order for variable placement, which is why I made the template use named variables.

SignpostMarv Martin 18:20, 12 January 2007 (PST)

Could use both ;).. I leave it up to you. I'm happy with my simpleslurl for quick links.

--Baba Yamamoto 18:23, 12 January 2007 (PST)

I'm about to take a lazy option, hope you don't mind :-D

SignpostMarv Martin 18:36, 12 January 2007 (PST)

You're welcome

Glad to see someone noticed my small contribution. I did seem to make a mistake somewhere though, Linden QA employees is somehow filed under Q. I should have made it titled QA Lindens. MichaelFrancis Linden

I would suggest changing the sort order to [[Category:Linden QA Team|QA Team, Linden Lab]]

Also, consider using the new monolithic Linden Lab Employee template, llEmployee.

SignpostMarv Martin 11:35, 15 January 2007 (PST)

Done.

MichaelFrancis Linden

Project:Internationalistion

I'll stick it here rather than a talkpage on the subpage as the latter will probably move at some point! Basically, you're heading into a minefield (I know - I entered it myself some years ago for an another organisation!) and not only in placing the country of Ireland as part of the United Kingdom (a big kettle of fish if ever there was) but also with some of the others too. Languages may be commonly used in a country but at the same time be officially banned which can mean that stating they exist can cause problems. I'd also noticed that for the countries you'd used anglicised versions for all but Mexico, which seems unfair on the rest (though I accept that accents and diacritical marks might become an issue) but that most of the languages had been titled in that language even if the link had still been anglicised. In the interests of the global aspirations of LL/SL I'd suggest that a ful localisation is carried out on all the names (and some countries, eg Norway, have two "Nowegian" languages, so something else to be aware of.) --Alison Wheels 04:24, 17 January 2007 (PST)

1. Don't worry about doing it on the sub-page, if it relates directly to the draft, please do it there :-)
2. I only did the non-Anglicised version for Mexico because I happened to be looking at the wiki page for Mexico at the time. The idea would be to have the native, non-romanized spelling wherever possible.
   • Redirect pages will be setup from the Anglicised spellings to the native spellings for ease of use
3. full localisation is the idea, yes :-)

SignpostMarv Martin 06:23, 17 January 2007 (PST)

P.S. It's not spelled with a z because as far as I am aware, it's only spelt with a z in en-US, and I'm en-GB.

LL:Second Life Terms of Service

Hi...I didn't realize you were going to post LL:Second Life Terms of Service on the wiki. Having two copies of our legal agreements posted on *.secondlife.com websites creates a huge problem for us. If we forget to update the wiki version, someone could claim that they thought these were the official terms. I can ask our legal department, but I'm 99.99% certain he's going to ask me to delete it. Sorry for not paying closer attention to what you were planning. -- Rob Linden 22:44, 17 January 2007 (PST)

Ah, no prob- didn't think of that :-D

Same goes for the Community Standards right ?

Sorry for running with it without checking in first- there is the distinct advantage of being able to track changes in the TOS with the wiki though.

SignpostMarv Martin 06:20, 18 January 2007 (PST)

No worries. I understand the desire to track diffs. I don't want to bother Ginsu with it right now, because he's swamped, but after we find an hire a new general counsel, we can revisit. -- Rob Linden 13:55, 18 January 2007 (PST)

I've added a notice to the top of the LL:Second Life Community Standards article, could you sysop that and add the following to the TOS? :

:''<span style="color:red">This is a duplicate of the Terms of Service held on the main website and as such, it might not hold the same information as the original. Please refer to https://secondlife.com/corporate/tos.php if you need to refer to the Terms of Service document for anything important.</span> <hr style="background:transparent;border-bottom:1px dashed red;height:1px" />

I would imagine the shiny red letters at the top of the page would be a suitable method for keeping the document on the wiki right ?

SignpostMarv Martin 14:39, 18 January 2007 (PST)

P.S.: using the wikified version of the TOS, external sites can link directly to a specific section so peeps don't have to go search through small print.

I'm interested in understanding how to sync and/or link this better too — I ran into a similar problem when including some policy documents in the Knowledge Base, because linking to them doesn't provide all the keywords in the body text which people end up searching for. And yet, the website-wide secondlife.com search is inadequate for such purposes.

--Torley Linden 14:30, 30 January 2007 (PST)

1. Harry Linden setup a google co-op search which I've been using for Help Request searches (the one I setup is better for offsite resources)- I'm not sure whether LL would be better off using Google Co-op or just buying a Google Appliance box.
2. It's on my To-Do list to document the LL policies in the wiki, and to see if it's possible to migrate the knowledge base to the wiki.

Advantages of documenting/transferring LL Official Policies to the wiki instead of elsewhere:

1. Residents can keep track of changes to the TOS easier (It'd be more interesting to start off by putting the first edition in, then each progressive version so the changes could be viewed retrospectively as well). The articles could be sysop blocked to prevent fraudulent changes.
2. Residents can ask questions pertaining to each policy on the article's talk page.
3. A FAQ could be compiled from these questions periodically, as a means of keeping the talk page from growing too large.
4. Creative Commons-style "simplified" versions of the policies could be created based on the legal document and the FAQ (who actually reads through legal documents such as these any more ?)

SignpostMarv Martin 08:41, 31 January 2007 (PST)

Community Team Wiki'ing

Marv, we've talked before about filling in more Community Team specific and general community-related information. As you know, I mentioned I'd like to devote more of my time contributing to this wiki. What other areas could we help fill in? Can you please identify some more and let me know? I know terms like "CommMonkey" are more under-the-radar than they should be, so with your keen attention to detail, I'd like to help draw awareness and add to the available information.

In short: what are you 'specially curious about that Residents should broadly know?

--Torley Linden 14:35, 30 January 2007 (PST)

1. Complete staff and departmental listing.
2. Article with hCalendar-encoded listing of Liaison's on-duty times over the current month/ week.- The weekly table would probably be more easily compiled, and could be used as a resource for Residents wishing to privately IM whichever Liaison is on duty, rather than searching the people list for online Lindens.
3. Publicise the activities of the Tao of Linden- that is to say, make it easier (blurb+categorisation) to see who is working on Mono, Havok, graphics pipeline, interesting little features etc. Since MediaWiki has syndication feed support (which seems to have gone walkies- has this been disabled in the back end?), "developer diaries" of sorts could be housed on the wiki, rather than on personal Linden blogs or the main LL blog.

I could probably think of a few more things, but this seems like a good place to start :-P

SignpostMarv Martin 08:50, 31 January 2007 (PST)

1. Thanx Marv, those are great suggestions — I definitely see some opportunities where we could fill in gaps. I think a "complete staff and departmental listing" isn't very likely to be maintained, but what is probable are wiki-active Lindens (like I am becoming...) responsible for including and updating their own listings for the convenience of Residents. I also wish we had an easier way to simply grab info from the About section of our inworld profiles and sync it on here. :)
2. Re: Public Liaison calendar — have you asked Char and Mick (Liaison Supervisors) about this?
3. Yes, this would connect excellently and go very much hand-in-hand. I'm actually surprised when I hear of applicants missing the Tao of Linden — even tho it's linked to from the Employment page. Core principles like these could be, and should be more visible. I'm also aware that the blog has become very busy and is primarily used for news announcements; we don't have an "Asides" format (as is seen on some blogs), so it'd be nice to house dev context for those who are interested in and have the time to participate. For me personally, I prefer an actual blog publishing platform like WordPress, with WYSIWYG editing — I prefer Windows Live Writer.

--Torley Linden 10:38, 31 January 2007 (PST)

1. OSSL/libSL + wiki template + wiki category = a bot that periodically looks up the listings in a wiki category (which peeps add with the wiki template) that searches for their profile and appends the info. Template:SL-hCard would be a useful for this.
2. Email sent
3. Configure/use plugin for WordPress to stop posts from specific categories being displayed on the front page or make use of the domain mapping feature, and create a dev blog at dev.blog.secondlife.com (community.blog.secondlife.com, grid.blog.secondlife.com and tao.blog.secondlife.com might be other suitable extra blogs), including them in the main blog & each other via the RSS widget or similar plugin.

SignpostMarv Martin 11:35, 31 January 2007 (PST)

Re: #3, right now, we don't have this configurability. We cannot install new plugins ourselves through WordPress VIP. :\ Also, those domain names look no less simpler than, say, blog.secondlife.com/community — which could be done from WordPress itself I think... mod_rewrite?

--Torley Linden 09:58, 1 February 2007 (PST)

The issue of using sub-directories for sub-blogs within the WordPress.com VIP Hosting environment is that you'd have to make sure you didn't put up pages with matching URLs.

From a psychological perspective, if everything is within the same sub-domain, you expect it to have the same design, but if each department has it's own subdomain under blog.secondlife.com, then the dev blog could be cleaner & crisper, the community blog could be more watermelony, the grid blog could be structured like and replace the http://secondlife.com/status/ page (since WordPress can be configured to display only the latest post on the front page), so rather than doing grid-related posts on the main blog, and updating them, you'd have the appearence of there only ever being one post- unless you went into the archives.

SignpostMarv Martin 10:41, 1 February 2007 (PST)

Summary of response regarding Liaison duty times calendar article

We don't have any current plans to publish anything like that.

Liaisons can be reached via Help Request for now- or for Live Help group/Mentors in either of those group channels.

It's very important right now that emphasis is there instead of being pinged individually. Also during crisis times it especially becomes crucial as dozens of messages come in to HR channel and if dozens come in directly it becomes paralyzing.

Char Linden

Thanks to Char for providing this! I gotta say, we can't emphasize info like this enough. Good to know.

--Torley Linden 09:58, 1 February 2007 (PST)

Resident's own pages in Resident's own user-spaces

If an article is a work in progress, or is intended to be solely for displaying your own research (as opposed to being an authoritative article), it would be a good idea to keep the articles within your own user-space- as was done with Gwyn's permission for Gwyn's Beginners Guide To Second Life being moved to User:Gwyneth Llewelyn/Beginners Guide To Second Life.

Anyone who currently has a self-written article should consider moving it to their own user-space, especially if it's a work in progress/sandbox article (you'll notice I have lots of those).

If you're not sure how to move them over, leave a message here and I'll take care of it :-)

SignpostMarv Martin 19:58, 9 February 2007 (PST)

Re: Re: Talk:LSL Function Style

I'm not offended, nor angry at you, you have passion and there is validity in your points. Your comments have brought up issues I had not considered; as a programmer I pride my self on seeing all sides of an issue and it is a good thing when people point out my blind spots. I gather you are not found of the rigidity of the templates but I think it can be made to work. I spent a bit of time thinking about the problems you brought up with internationalization, I was thinking we could write some template-templates; they would change the words in the templates (maybe even the names of the parameters). We both have strong wills and ideas on how things should be. When I was working on the old wiki I came to a few conclusions and across a joke. The joke first, "Documentation is like sex: When it's good, it's great. When it's bad, it's better then nothing". The LSL wiki was rank with bad documentation. Writing good documentation is really difficult, technical writing is a profession after all. One of my conclusions, was that "If I see something that needs to be done, when I come back in a month, it still won't be done. So if it needs to be done, I'll have to do it myself." My work is partially driven by that principal. My goal is to have a skeleton for the content finished as soon as possible. When the skeleton is finished it will be easier to flesh things out. I'm not worried about how things look or where they are so much as getting things usable. Sure I fix bugs as I come across them in the templates but if we decided to rewrite the layout, I'd rework the templates. The templates have the potential to save us huge amounts of work. But now I'm rambling. There is a lot more I would say but for the sake of brevity. I hope you will continue to contribute, you have good ideas and don't let me being stubborn discourage you. Strife Onizuka 16:35, 11 February 2007 (PST)

1. I spent a bit of time thinking about the problems you brought up with internationalization, I was thinking we could write some template-templates;
   • This isn't really needed. Multi-lingual documentation on how to use a template is better than translated template parameters transcluding the English-language template.
2. Writing good documentation is really difficult, technical writing is a profession after all.
   • We should be writing user-guides, not documentation. User-friendly that is understandable by everyone, with no cut off point for skill level or language.
3. My goal is to have a skeleton for the content finished as soon as possible. When the skeleton is finished it will be easier to flesh things out.
   • This is a bad way to go about things. If the structure of an article is under dispute, creating articles based upon the disputed article makes it more time consuming to alter afterwards.
4. I'm not worried about how things look or where they are so much as getting things usable.
   • Then work on the articles in your user-space, and move them to the proper article space once they're done.
   • I've been doing this with several articles, both on the SL Wiki and on the Wikipedia. It helps to avoid confusion with regards to missing content and disputes over design, as once you have finished a single complete article, the article can be put up for discussion, and modifications can be made in the interested parties own user spaces (as Baba and I have done with a few different things).

SignpostMarv Martin 10:47, 12 February 2007 (PST)

Match the numbers.

1. The templates have a few messages built into them. Default messages triggered by different keywords and parameters.
2. I'm glad we see eye to eye on this one, we don't want people saying "this article is too technical" or "this article is lacking in technical details"; a cutoff point can go both ways after all. Lets not argue over this any more it makes me weary and I could have spent this time writing articles or clever templates. Let us spend this time making the articles better.
3. I didn't think they was a dispute over the style; after all no-one has posted a new proposal or modified the current one on LSL Function Style.
   • To put it bluntly, having a proposal in your little fiefdom is all fine, but if you want people to see it and consider it you have to put it out for the public to consider it and let them play with it some. It's how the LSL wiki worked in the past. Some things change slowly.
4. • It means templates are easily changed. If you change the template you can change the world. If there are flaws in the template but the content is good, the template can be fixed and it will fix every page.
   • The first link doesn't work. Well I did put an article up for discussion, didn't get any dissents but got a lot of positive feedback. SL-Forums

Strife Onizuka 22:15, 13 February 2007 (PST)

1. Template:LSL Function has 68 parameters.
2. o_O ? Your prior stance indicates you wish to impose a cut-off point for everyone under a certain level of techical ability.
3. It's been under dispute since the 28th of January.
   • There is nothing encouraging Residents to copy the template code to their own user space to work on it, working on it directly is bad wikiquete.
4. • Your Template:LSL Function has 68 parameters and has a page weight of 10.5625kb. The phrase "easily changed" doesn't touch Template:LSL Function with a 20 foot barge pole.
   • https://wiki.secondlife.com/w/index.php?title=Special%3APrefixindex&from=SignpostMarv+Martin%2FSandbox&namespace=2

SignpostMarv Martin 03:02, 14 February 2007 (PST)

P.S. WEB-23. You wanted to make a template to switch between "a" and "n". Further indications that you go tend to create unneeded template code.

SignpostMarv Martin 04:10, 14 February 2007 (PST)

1. Are you sure it's only 68? There are a few undocumented ones that are there for compatibility. Anyway half of those go to function parameters; which is reasonable when you consider it (there are a few functions with alot of parameters).
2. I am willing to concede the low end for the high end. Having articles in language that anyone can understand and rich in technical content is a victory for everyone.
3. The namespace has been under dispute since the 28th. Last time i checked that is a global issue not unique to LSL functions. A page's name has as much to do with content as the cover of a book.
   • (assumes you meant discouraging) No one has written the SL wikiquete yet. What is good and bad has yet to be defined. Though I have come to agree with you on this one for a different reason: Modifying the templates in place causes the engine to re-render all the pages that use the template. I try to roll multiple changes into a single update where possible. Still working on the technique though.
4. A lot of Template:LSL Function is the documentation. The live code on the template is less then 6KB. With associated templates it comes to around 20KB. I will be simplifying the logic on the templates because last night I learned something interesting about MediaWiki: It executes both sides of an #if but only returns the proper side of the conditional. Quite maddening when using #vardefine. Template:LSL Function is just a front for Template:LSL Generic, which does the actual work. Flow control, events and functions share Template:LSL Generic. Unified style. Course they use the boxes slightly differently.

Better to create small useful templates that can be reused then inlining. How could the template be useful? If you cannot imagine I won't spoil the mystery. Strife Onizuka 08:49, 14 February 2007 (PST)

1. Whereas I'm using only one template parameter to declare the parameters for the LSL function.
2. 1. The content is technical, the phrase "rich in technical content" is redundant.
   2. 1. Everyone who would make use of a technical manual for LSL already knows how to use LSL, rendering such a manual pointless.
      2. Everyone can make sense of a simple guide
         • Including people who would make use of a technical guide that don't know LSL
      3. Any further clarification of content should be done by aggregating feedback (torleyism) via the Wiki talk pages. (as opposed to inline as was done on the LSL Wiki).
3. Your methodology has been under dispute since the 29th.
   • No, I meant encouraging. "There is nothing encouraging".
   1. Have you considered that the template source code is just so hideous nobody wants to touch it with a 20 foot barge pole ?
   2. Have you considered that by using a monolithic template you're making it incredibly difficult for people to contribute to it ?
4. 1. Reinforcing the concept that your templates are a bad idea. Too much cruft.
   2. Which is why the Wiki manual advises {{#vardefine:foo|{{#ifeq:{{{bar}}}|bah|black|sheep|}}}}
5. The word "small" and your templates are complete strangers.

SignpostMarv Martin 09:59, 14 February 2007 (PST)

1. And it provides no features.
2. 1. You want it with as little technical content as possible, so using the word 'rich' would be valid. 'with' would have been a better word then 'in'.
      1. Just because you know LSL does not mean you have the syntax & function names memorized. I know I don't.
      2. Everyone can make sense of a simple guide given enough time yes.
         • By having an article arranged into sections it allows for people to find and better understand the information. It is a common practice. It is one of the big features of MediaWiki.
      3. If you want to dictate rules, write them as rules.
3. 1. Truth of the matter I know it's pretty hideous but so is the source for LSL Function Style (not quite as much but close).
   2. Yep, hence the instructions on LSL Editing Primer; by splitting the templates, it's actually gotten alot easier to work on it.
4. Does it get the job done?
5. Not true at all, Template:AAn, Template:HoverText, Template:LSLC, Template:!

1. All it's meant to do is output an LSL function with the return type and parameters.
2. You're being more anal retentive than I am.
3. It doesn't need to be.
4. Yes, but so does a tank when all you need is a pair of rollerskates.
   • You're pretty much the only person using them- they're too complex.
5. Most of those templates are completely and utterly useless (referring back to the whole "your templates are overkill" thing).
   1. Template:AAn is overkill, and won't work in all occasions. I personally use "An HTML document" instead of "a HTML document" because phonetically "HTML" starts with an "A".
   2. Template:! Why the hell did you make that one ? You're entering 5 characters for one character !? {{!}} returns | !! I mean, come on- seriously, this template is useless.
   3. Template:LSLC is a fix for something you've been told not to do (prefix everything with LSL
   4. Template:HoverText only exists because MediaWiki is a pain in the ass with the <abbr> element. Can't this be fixed in the back end ?

SignpostMarv Martin 12:08, 14 February 2007 (PST)

Don't like monolithic templates? Then give me a break for a while and beat on Rob Linden for creating: Template:LSL_conformance_test and Template:LSL_conformance_script

I started a poll about the namespace/prefix issue. Figured it would be best to let the community decide after all the wiki is a community resource. I'm sure you will agree that this is the best way to end the debate. Linky

• Template:! is a workaround for embedding tables in template parameters and is in the Media Wiki documentation.
• Template:AAn So you would prefer the procrustean solution? (irony ^_^)

Strife Onizuka 18:05, 14 February 2007 (PST)

marked by arbitrary often ruthless disregard of individual differences or special circumstances

Doesn't that describe your attitude to excluding everyone below a certain technical level, everyone not familiar with MediaWiki syntax, and everyone not familiar with LSL because you feel like it ?

How on earth is my preference not to use an insufficient template to automate correct grammar procrustean ?

SignpostMarv Martin 18:48, 14 February 2007 (PST)

Not using a template for a situation where you would need a template to fix the grammar would be procrustean as it would force one grammar on all situations.

I think i may have answered your first question eariler. C'est la vie.

Strife Onizuka 22:13, 14 February 2007 (PST)

In what circumstances would it be appropriate to use the template over manual editing ?

SignpostMarv Martin 05:04, 15 February 2007 (PST)

Everything

I am sorry for driving you nuts. It wasn't till you posted to the forum that I realized I had caused it. I apologize. Strife Onizuka 09:13, 17 February 2007 (PST)

np Strife, as demonstrated by the Pro vs Con table, logic smacked me up-side the head :-P

SignpostMarv Martin 09:27, 17 February 2007 (PST)

A good table early on would have saved us both a lot of grief. *thinks about this as if it were a problem to be solved* How about in the future we make a table each, side by side, and then try and merge them. Below the table as subsections we can briefly state which ones we feel are important and unimportant, and our reasons; but trying not to respond to the other persons reasons. More as a method of hearing opinions then debate. Strife Onizuka 10:11, 17 February 2007 (PST)

Since the forums are limited to those with payment info, I'm thinking it's better that polls related to the Wiki be held on the Wiki. If you agree, I'll knock up my ideas in my sandbox later.

SignpostMarv Martin 04:34, 18 February 2007 (PST)

If you meant to continue the current debates, I'd like not to for a bit of time. If you meant to write up dispute resolution guidelines and structure, please be my guest. Strife Onizuka 16:52, 18 February 2007 (PST)

I meant the latter :-)

It would be a general purpose voting scheme btw.

SignpostMarv Martin 17:39, 18 February 2007 (PST)

See User:SignpostMarv Martin/Sandbox/Voting proposal

SignpostMarv Martin 12:57, 19 February 2007 (PST)

What? Why?

Why are you moving articles into subpages? What point does that serve? Categories exist for a reason! Gigs Taggart 11:05, 19 February 2007 (PST)

1. See the uncontested suggestion made almost a week ago in Category talk:LSL Library
2. This doesn't affect categorisation one bit.

SignpostMarv Martin 11:10, 19 February 2007 (PST)

I don't watch every page on the wiki. Just because no one corrected you doesn't mean it's a good idea. You still haven't said why this is a good idea. Gigs Taggart 11:16, 19 February 2007 (PST)

1. The suggestion was made in response to a comment you made, and just a little over an hour after you'd made it.
2. The concept of categories is being mis-used in Category:LSL Library- the table provides much more useful information than a simple category could.
3. Which format gives a better indication of what an article refers to, what language it's written in/for ?
   1. Chat Logger (GPL), Chat Logger (GPL) (C++) & Chat Logger (GPL) (C#) or LSL Library/Chat Logger (GPL), C++ Library/Chat Logger (GPL) & C# Library/Chat Logger (GPL)

There's also the matter of User:SignpostMarv_Martin/LSL2/llXorBase64StringsCorrect- my implementation of llXorBase64StringsCorrect, which I shall be moving to PHP Library/llXorBase64StringsCorrect shortly.

SignpostMarv Martin 11:43, 19 February 2007 (PST)

At the top of the real llXorBase64StringsCorrect article, just put a simple disambiguation link to llXorBase64StringsCorrect_(LSL_Version). Rob said we should use disambiguation, not fake namespaces. Gigs Taggart 11:58, 19 February 2007 (PST)

You'll notice I'm using subdirectories, not fake namespaces. You know, like books in a library being under one roof ?

SignpostMarv Martin 12:03, 19 February 2007 (PST)

Your subpages are just as bad, if not worse, than fake namespaces. Gigs Taggart 12:04, 19 February 2007 (PST)

Fake namespaces require string parsing voodoo. subpages can make use of {{SUBPAGENAME}} and {{BASEPAGENAME}} wiki-fu.

The MediaWiki platform supports and advocates sub pages for closely related articled under a root topic, whereas categories are meant for a slightly more loose relationship between articles

SignpostMarv Martin 12:09, 19 February 2007 (PST)

No, it's completely different. An article can belong to multiple categories, but it can only be a subpage of one other page. Your method is inflexible in addition to making the category pages look like shit. Subpages weren't meant to be used this way. Gigs Taggart 12:16, 19 February 2007 (PST)

So aside from having butt ugly links, the problem is......

SignpostMarv Martin 12:17, 19 February 2007 (PST)

The problem is you can't jam everything into just one category, and you constrain people's thinking when you do that. Butt ugly links are a good enough problem to not do this anyway. Gigs Taggart 12:35, 19 February 2007 (PST)

Neither categories nor butt ugly links apply to the LSL Library.

SignpostMarv Martin 12:48, 19 February 2007 (PST)

Feature Requests

While we're at it, I'm glad to see you breaking up the old monolithic feature request page, but why are you moving them into userspaces? The entire point of a wiki is collaboration. These feature requests should be made into their own freestanding pages. Gigs Taggart 11:19, 19 February 2007 (PST)

Seconded. This is a bad idea. Moving to userspaces encourages people to claim ownership and that's a detrimental concept to a wiki. --Jesse Malthus 11:34, 19 February 2007 (PST)

1. Why ?
2. There's no disadvantage to creating them in user-spaces (see the Creative Commons licensing scheme and the contribution agreement for concerns of "claiming" a concept), but there are some advantages:
   • Residents can make ridiculous feature requests such as Nude Patches, along with all of my silly ideas without "spamming up" the Wiki.
   • Residents can expand other's ideas to a ridiculous level, and ask for feedback before (Celestial Effects) these ideas are picked up by the community (User Interface Improvements, Plugin architecture)

SignpostMarv Martin 11:43, 19 February 2007 (PST)

It makes the category page unreadable, and it sorts them all under "U". Move them into their own articles. If people want to use their userspace as a sandbox they should, but userspace links should not be in the category. Gigs Taggart 11:57, 19 February 2007 (PST)

I'll be fixing the U thing shortly.

I suppose next you'll be wanting to create a bunch of redirect pages for everyone listed in the sub categories of Category:Second Life Volunteers and Category:Linden Lab Employees then ?

SignpostMarv Martin 11:59, 19 February 2007 (PST)

What? That pages looks fine to me. I don't see your point. The feature request category page looks like total shit now that you've fucked it up. I'm getting damn sick of this compulsive need to "partition" things that some people seem to have. Gigs Taggart 12:02, 19 February 2007 (PST)

I said the sub-categories. Category:Second Life Mentors for example.

Categories don't need to have pretty names, they just need to be sorted correctly- something I didn't have the time to do when I was moving things about.

SignpostMarv Martin 12:12, 19 February 2007 (PST)