Re: lists of what Aaron thinks is important for the wiki Re: Idea for navigation

Aaron Peterson wrote:
> **********
> My points (see that my arguments need refinement, I stupidly thought they were 
> self evident)
> 
> 1. Respect others work by saving it. Saving it means linking to it from the 
> page that it was on.  The history, or deletion bucket doesn't count. We don't 
... We seem to be mising a bit here.  I really have no idea what the 
second sentence is about but I (and I'm sure everyone else) agrees with 
the first sentence.

> 2.  Don't delete stuff that you don't understand.  If you don't know why 
> somebody put a link between two pages, ask, or leave it. (unless it's on 
> another topic completely)  (see topic 5)
I agree - I'm not sure why anyone would unless the content is not fit 
for the wiki.  If there is any doubt then that's when the talk pages 
should be used.

> 3.  General names are natural seeds, they don't need any plunge ahead note, 
> Once  a page like.. Media has become non-dense, then break it up into audio, 
> video, and what not, to keep it navigateable. 
I assume you are meaning the stub notice?  I think that it is quite 
useful especially for new members who may feel reluctant to edit long 
standing pages.

> 4. the case sensitivity of wikipedia is unfortunate.  is there a work around?
Yes - use the search feature before creating a new page.

> 5.What is on topic?
>   talks about the current wiki, linux questions, and linux, and software that 
> runs on linux are all ON TOPIC, and deserve to be MOVED if they are in a very 
> inconvenient spot
Where are they just now and where should they be moved to?  All linux 
content is valid for posting on the wiki as long as it is not offensive 
and does not enfringe on any copyright licencing.

> 6. Links are content.
Agreed.  Links to external sites should also be placed in an External 
Links section at the bottom of the article as well as being placed in 
the relevant context within the content:
http://wiki.linuxquestions.org/wiki/LinuxQuestions.org_Wiki:Manual_of_Style#External_and_'See_also'_links

> -----
> getting personal here,
> 1.  I have been hit by all of the above topics.
I'm sorry to keep hearing this.  Perhaps you can give us examples next 
time.  If Myself or someone else is inadvertantly doing something wrong 
it would be much easier to see in context.  If a change has been made 
please provide the 2 relevant revision links.

> 2.  I am especially annoyed about bug reporting -- feature request links being 
> removed.  Try going to kde.org and asking for a tiny feature that you'd like 
> to see... and don't do it over their bugzilla software...
Again - examples please.  We do have 2500 pages on the wiki.

> 3. A one line See Also: line that is designed to be unobtrusive, and 
> immediately accessable to a user
We did have a discussion on a one line "See also" section against a 
bulleted list like the "External links" but in the end it looked better 
with both as bulleted lists.

> Tasks
> -----
> 1. Experiment!!!  i have done so, and i am relaying the results of those 
> experiments  to you all.  You don't take my word for it, so open up a little 
> and play with the wiki.   this is not plunging ahead, this is trying other 
> wikis, playing with format, playing with style.. untill you find one that 
> works. best.
Sounds like a great idea.  That's one reason we have the sandbox.  Any 
style changes that people think should be added to the Manual of Style 
should then bring them to the list along with a link to their sandbox 
revision (remember to use the revision link and not the current page as 
that may change).

I also have one minor gripe to add to this and I'm guilty of it myself 
so I will say this while looking in a mirror can people try to use the 
preview button before saving pages.  I quite often see one page being 
edited by the same person several times in just a few minutes.  Over 
time this will fill the database quite a lot as all revisions are saved 
and it makes it a lot easier to use the diff function when there are 
less revisions.

> 2. Make protected pages be source readable!  I can't clone/ fork a page to 
> show you guys what i mean, because I not only can't submit changes to it, I 
> can't see the source to the page.
I'm not sure if this functionality is already in MediaWiki but I'll look 
into it.

> 2.
> un-protect the main page, or do some work on it.  Specifically, it needs 
> expanded info on how to use the wiki.  etiquite (sp), conflict resolution, 
> etc.  I've looked over your pages, and I'm still stumbling across new 
> formatting thingies.
There is a talk page for "Main Page" - what do you think should be 
added, the etiquet type documents are being worked on but these things 
take time and this is a fairly new project and things are being dealt 
with as they come up:
http://wiki.linuxquestions.org/wiki/Talk:Main_Page

> 3.  backlinks are most usefull when they can be seen WITH the content, page 
> flipping is nasty on web pages.
>   Things I think we will find addequate:
>   1.   Blank pages show what links to them, rather than the edit page.
Personally I think this would be confusing to see content on a page that 
doesn't yet exist.  Why not just create the page as a stub and make a 
"See also" section containing a link back to the page you created it from.

>   2.  a reminder to click what links here occasionally (the link to the 
> baclk_links pages were not intended to be complaints, but be markers and 
> serve as a reminder, and be a question on how to implement them)
What sort of a reminder?  A popup window every 5 pages you visit?

>   3. implement a wiki action that offeres this functionality.
I'm not 100% sure what you mean.  Do you mean code something to 
automatically include "what links here" in a document?

>   4. an expanded what links here in the side bar.
The same as above?

> 4 is something i'd like to see experimented with, would satisfy me, and is 
> proably the easiest to implement, I don't know how hard it would be on your 
> server though.
> 1 and 2 is the minimum I'd be happy with
> 1 and 3 would become redundant if 4 is implemented.
> 1 is extremely cool, and is highly recommended and, would shut me up for a 
> while.
> 1 and 3 are what I expect from a wiki.
> 
> ***********
> 
> 
>>	What do you think about moving the "What links here" to the Browse
>>nav box?
> 
> A good start, but doesn't allow for seeing the content at the same time as the 
> links.  Having an expanded "what links here" in the side bar would be very 
> nice.
> 
> Thanks for asking this,
> 
>>	I am still not clear why you are unwilling to put what you have
>>been putting on the top of the page in "Backlinks" and "Member of" links
>>into the standard ==See also== section.  I have also not see anyone remove
>>content you have put into a ==See also== section.
> 
> 
> 1. I believe that hyperlinks belong right next to where they were referenced. 
I don't think anyone disagrees.  Acording to the Manual of Style the 
links should be in context within the text as well as in an External 
links section at the bottom of the page:
http://wiki.linuxquestions.org/wiki/LinuxQuestions.org_Wiki:Manual_of_Style#External_and_'See_also'_links 


> 2. I believe that the peers of the page define a page as much as the page 
> content does  (taken from my dad observing politicians to see who their fund 
> raisers are rather than their outward appearance)
> 
> 3. Long pages need an instant way out of.
Exactly - that's one reason for including "See also" and "External 
links"  Just press your "End" key and you should see them

> 4. It's really short being only one or two lines, and it solves multiple 
> parents
> 
> 5. once it's in the standard See Also section, people will want to put it back 
> there if I move it out again.
> 
> 6. There is a difference between member of, and see also, the distinction has 
> use.   (member of is typically very short, I experimented with paths, but I 
> can drop that, or condense them)
Paths?  again - examples may be useful.  I think you are talking about 
namespaces and these will only be created if and when it is thought 
there is a need.

> 7.  Multiple navigation systems do not harm a wiki, the multiple navigation 
> systems are the web,  I don't think of a cross referenced books as being much 
> of a web.  (I'll expand later
> 
> 8.  People VERY often enter the wiki  at where the search engine drops them, 
> all pages need to serve as a minimal "table of contents" to the rest of the 
> wiki.
You can't really link to 2500 pages from each individual page.  Would it 
not be more likely that people would use the "See also" section to see 
related material or go to the main page to see the main categories?

David