relative ease, whats on topic, Re: lists of what Aaron thinks is important for the wiki Re: [Lqwiki-list] Idea for navigation

David,

> > 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.

technically all of the changes are saved, (maybe moderators can delete stuff 
permenantly (sp), but my point is, that it should be saved on an active wiki 
page.

It is much harder to restore content that is stored in the history engine. 

 It is very easy to delete content

It is difficult to write content

it does not take much effort to copy somebodies content to a live page.

>
> > 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.

I have no doubt that  wiki related stuff, linux questions stuff, and linux 
stuff are valid topics. for this wiki.

I have some suggestions for shorter wiki name spaces.... however they are 
redundant ...

[[wiki:this wikipedia instance]]
[[lq:linux questions]]
and blank = linux

However, [[Wiki Keyword]] 
forms a category, or name space automatically. 

I'm really enjoying the  name space convetions like talk:  


> 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.
yes, I'm sorry, I just think it's tacky, but I'm willing to live with it/leave 
them there if they are already there.

I much prefer having instructions on how to edit the wiki on the main page.
and using  [[please fix]]

>
> > 4. the case sensitivity of wikipedia is unfortunate.  is there a work
> > around?
>
> Yes - use the search feature before creating a new page.
Doh, I forgot about that!
but actually, that is kinda invasive, it slows down the development of the 
wiki in a tedious fassion...   it's OK to have many similar pages, if they 
link unambiguously to one another, (like have a common parrent document that 
can lead people ouf of the black hole wiki

>
> > 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.
well, if I were to make a page, such as Wiki War I or Black Hole Wiki, and 
somebody wanted to be constructive, they would have kept wiki war I and moved 
black hole wiki to [[wiki black hole]], so that it is clear that it iis not a 
wiki product, but a document relaited to how this wiki runs


>
> > 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

I very much disagree with you here, there is a time and a place for an 
external links section, but that removes the link from it's context.

single brackets are probably the best solution for off site links.

[http://blahbalbh||wiki looking name] should be avoided, because it makes it 
look like an internal link.  I would actually consider disabling this feature 
from the wiki

>
> > -----
> > 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.

There has to be an admin page that shows what pages I've worked on...  nearly 
every one has examples

>
> > 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.
but I haven't touched that many of them yet.
[[bug reporting]]  was intended to be an example


> > 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.

Looks vs functionality. and placement.

fast food resturants look for location location location.  They do not get 
built in the boonies where nobody will get to them, they are built where they 
get used.  

One line See Also's are supposed to contain the choicest of the see also's, 
have an over flow area of bulleted lists.. yes, that is good.. duplicating it 
is fine  (as I will be doing some work that   you don't want to do, and you 
would be doing work that I don't want to do!)   It's all good!    

I was going to add a section to the manual of style concerning these two line 
Member Of:s/ See Also's   to give suggestions on how to avoid getting them 
into a bloated mess. (which I have never seen them get into btw, except for 
some experimental links that has great great grandparents... but I still 
don't think those were bloated messes)



>
> > 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 think you avoided my point...
Experiment with actuall live content.  
the sandbox is for formatting.. I am talking about archtecture...


>
> 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.

Agreed,  I try to remember to hit preview, but I'm often wishing to go to bed 
asap.

This is another thing that can be handled automatically.  If one person edits 
the page consecutively, the database should be able to merge the entries, or 
at least hide the redundant ones....   (I thought that this is what minor 
edit was for for a while.. but it's not...)

>
> > 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.

Thanks!  the more tools we have the better!


> > 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

That talk page is not obvious to a new user... and I've never stumbled across 
it.  There is however a suggestions page that is linked to on the bottom of 
the [[main page]]  that I thought this was for.

>
> > 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.

Great point!  
I was confused the first time I saw this implemented on a wiki, however, a 
proper disclaimer / description of what's happening should suffice...  The 
wiki that I saw this on for the first time did not have a satisfactory 
explanation.

Which makes me think, you can experiment in these ways:
With content
with framework (navigation)
and with tools (the wiki engine)
... and with people .. like with probes and scalpels and stuff..

>
> >   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?

on pages that it would be usefull on? 
e.g. pages that have lots of one way links to it

******************
Time to go to bed, I will respond to the rest later...

>
> >   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
> _______________________________________________
> Lqwiki-list mailing list
> Lqwiki-list-cunTk1MwBs/4hYYZOrhEC/[email protected]
> http://lists.linuxquestions.org/mailman/listinfo/lqwiki-list

-- 
509 332 7697
ICQ 2302806