BackupPC-users

Re: [BackupPC-users] who is the wiki guru?

2008-08-21 21:37:02
Subject: Re: [BackupPC-users] who is the wiki guru?
From: Holger Parplies <wbppc AT parplies DOT de>
To: Alan McKay <alan.mckay AT gmail DOT com>
Date: Fri, 22 Aug 2008 03:35:14 +0200
Hi,

Alan McKay wrote on 2008-08-21 18:46:42 -0400 [[BackupPC-users] who is the wiki 
guru?]:
> I know that technically a wiki is for anyone to edit and alter.   But
> realistically in many cases there may be stylistic direction and that
> sort of thing that someone wishes everyone to follow.

the problem is probably not finding someone wishing everyone to follow some
guidelines, it's to get the people doing the wishing to agree on what they
wish. Presuming some people agree on something, I suggest we put it in the
wiki under a title like "Wiki guidelines" or "Wiki editing guidelines" at the
*bottom* of the "Wiki Navigation" [the link, that is, not the full text ;-].

> When I get it wrapped up there I'll pump it into your wiki,

It's your wiki just as much, isn't it? In my opinion, everyone on this mailing
list has a right to have wishes about the wiki: people asking questions would
not need to do so, if the answer was *easily to be found* in the wiki, and
people answering questions would likewise not need to do so (they could
provide a pointer to the wiki when (not if) the question was asked anyway).

To answer your question: I don't think there is an official "wiki guru".

If you want to know what makes sense to me, I can make a few suggestions.

1.) Keep a clear structure (err, we don't have one right now, do we?),
    otherwise nobody will find your answers without reading through the
    entire wiki. "Structure" includes the "headline" you use to link to a
    page. "modification structure" is a bad name for a link to a page which
    is probably meant to answer a part of your question, as is spreading
    some more of the answer over several pages meant to contain information
    on BackupPC, not meta-information on the wiki.

2.) Don't state vague assumptions as clear fact. If something works for you,
    and you don't know why, don't suppose it's the only possible answer for
    someone else. You don't want to be mislead into doing something stupid,
    and we probably all don't enjoy people coming here for solutions to
    problems created by "tips" in the wiki, so if you're unsure, say so. That
    will prompt corrections or affirmation by others, or at least prevent
    someone reading your advice from going against his own good sense.

3.) Try to be clear and understandable. What that means is probably a matter
    of opinion, but at least try. Using full sentences, proper spelling,
    punctuation, and mixed case helps. Up to a certain point, a rough draft
    note on something is better than nothing at all, but you should really come
    back to finish it later (and not forget to do so). It is unlikely that
    others can and will do it for you, because they may not understand your
    notes as well as you do.

4.) Avoid duplication. Finding answers to the same question in different
    places is confusing. Most likely the answers will differ, if only
    slightly. Which information is correct? Errors will be corrected in one
    place but not the other. Additions will be made to one place only. If
    the same information is relevant in two places, make a link.

5.) Avoid contradiction. "X works" and "X does not work" can't both be true.
    Either one of them is wrong and should be deleted or replaced with the
    other, or it should be "X sometimes works and sometimes doesn't",
    preferably with an explanation of the conditions under which it works.

6.) Be concise. I know I have to work on that one :-).

7.) Comment your changes. The "note" below the "editor" is marked "optional",
    but it's really easier for others to read your note on why you changed
    something than the diff, which only says what you changed, not why. If
    you're editing as guest, leave your name, so others can ask you if
    something proves to be unclear, or discuss things they disagree on rather
    than just overwriting them.

8.) Re-read what you write before submitting it.

9.) Make all related changes to one page at once, if at all possible.
    Splitting up edit sessions is unnecessary (use your favorite editor on
    your local machine to write the text first instead) and the changelog
    becomes uncomprehensible. Unrelated changes may or may not be better off
    in one session.

I'd appreciate comments and additions.

> but would
> like to know if anyone is opinionated on where / how to link it in.

It's distribution specific installation information, so under "supporting
distros" (another good example for a bad title) would seem appropriate. If
it's much longer than the descriptions there (likely), you should probably
link to a new page.

Regards,
Holger

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

<Prev in Thread] Current Thread [Next in Thread>