Criterion for forking build instructions for new source versions(was: [sldev] Better build instructions)

Rob Lanphier robla at lindenlab.com
Fri Jul 25 17:38:23 PDT 2008


On 07/25/2008 02:58 PM, Boroondas Gupte wrote:
> Ricky schrieb:
>> the neext question is how do we know when to just tweak the existing 
>> article, and when to split a new article? Do we only ever split?
> Coming up with a criterion is easy. The difficult part will be to 
> apply it:
>
> My suggestion: Whenever it is possible to change the description so 
> it'll *keep working for the versions it used to apply to*, as well as 
> to one (or more) additional version(s), just modify the article (as 
> long as things stay practical and readable, that is). If that can't be 
> done in a reasonable way, fork the article.
>
> To determine when that's the case -- well, the wiki articles do have 
> discussion pages.

Another important consideration: consider inbound links, and keep the 
*links* up-to-date.  We need to consider that people will be deep 
linking to this wiki from unexpected places, and search engine results 
may not always be optimal.  For example, the page "Compiling the viewer 
(MSVS2003)" currently has no disclaimer in the title that it only 
applies to 1.20 and older.  When 1.21 is released (and maybe earlier), 
the ideal solution would be to fix that, and for the following:
1.  Rename "Compiling the viewer (MSVS2003)" to "Compiling the viewer 
(MSVS2003 - 1.20 and earlier)" with a new disclaimer added to the top
2.  A redirect from "Compiling the viewer (MSVS2003)" be placed to 
whatever article tells you how to compile the viewer using CMake, since 
someone who tries to visit that page title probably wants to build the 
latest viewer using MSVS2003.  Links to that URL should go to whatever 
the right instructions are for the latest viewer.
3.  Fix up any places where there's a link to "Compiling the viewer 
(MSVS2003)" and it really does mean "give me the old page".

If this sounds like a lot of work; well, it is, which is why fewer pages 
(in the future) is probably better.  It's handy to keep the old content 
around, but it should be increasingly difficult to find, because 
otherwise novices are going to stumble into it and get frustrated.

Rob



More information about the SLDev mailing list