[opensuse-wiki] Bug Reporting FAQ
Hello, I think http://en.opensuse.org/Bug_Reporting_FAQ should be splitted into several documents because - it handles several rarely related topics - other not-less related topics have separate pages already - it is too large Current Content (just main headlines) is: 1. Bugzilla 2. YaST 3. Kernel Bugs 4. SUSE Linux Documentation 5. Beta Testing I would suggest to create separate pages for: 2. YaST -> Bugs/YaST 3. Kernel Bugs -> Bugs/Kernel 4. SUSE Linux Documentation -> Bugs/Documentation (and merge it with the last section of Report_a_Bug) Why I ask here before just doing it? Many bug reporters are pointed to the Bug Reporting FAQ - therefore I'd like to know if everybody (especially the Bugzilla Screening Team) likes my idea... Related question: What is a better page name - Bugs/YaST or Bugs:YaST? - Advantage of Bugs/YaST: This scheme is used by several other pages (Meetings/*, Build_Service/*, Documentation/*, HCL/*, ...) - and you get a back link to "Bugs" for free. - Advantage of Bugs:YaST: Most other pages about bug reporting use this scheme (but could be renamed of course). If nobody objects, I will split the page in some days, using the Bugs/* name scheme which is more common in the openSUSE wiki. Regards, Christian Boltz --
Ach so: es ist natürlich auch möglich, dass ich irgendwo einen Fehler übersehen habe ;-) Falsch konfigurierte Christians sind nicht mein Problem. [> Christian Boltz und Ratti in fontlinge-devel]
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-wiki-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki-help@opensuse.org
Christian Boltz wrote:
Hello,
I think http://en.opensuse.org/Bug_Reporting_FAQ should be splitted into several documents because - it handles several rarely related topics - other not-less related topics have separate pages already - it is too large
Current Content (just main headlines) is: 1. Bugzilla 2. YaST 3. Kernel Bugs 4. SUSE Linux Documentation 5. Beta Testing
I would suggest to create separate pages for: 2. YaST -> Bugs/YaST 3. Kernel Bugs -> Bugs/Kernel 4. SUSE Linux Documentation -> Bugs/Documentation (and merge it with the last section of Report_a_Bug)
Why I ask here before just doing it? Many bug reporters are pointed to the Bug Reporting FAQ - therefore I'd like to know if everybody (especially the Bugzilla Screening Team) likes my idea...
Related question: What is a better page name - Bugs/YaST or Bugs:YaST? - Advantage of Bugs/YaST: This scheme is used by several other pages (Meetings/*, Build_Service/*, Documentation/*, HCL/*, ...) - and you get a back link to "Bugs" for free. - Advantage of Bugs:YaST: Most other pages about bug reporting use this scheme (but could be renamed of course).
If nobody objects, I will split the page in some days, using the Bugs/* name scheme which is more common in the openSUSE wiki.
Regards,
Christian Boltz
Hi Christian, Today I was trying to figure out what would be the best logical structure (wording, naming) of openSUSE wiki so that people find it easy to remember and find articles. Topic Bugs is similar to FAQ, HOWTO (HowTo), Installation, Update, etc. It has it's global meaning for SUSE Linux and local for versions and applications. We can go with SUSE_Linux Bugs 10.0 system kernel driver1 xorg driver1 desktop app1 10.1 system kernel driver1 xorg driver1 desktop app1 or SUSE_Linux 10.0 system kernel driver1 bugs xorg driver1 bugs desktop app1 bugs 10.1 system kernel driver1 bugs xorg driver1 bugs desktop app1 bugs or something in between. The one of ideas is to structure everything similar to directory structure on FTP servers. Once you learn one the other is the same or easy to browse. What to use as glue? Simple / / / might be good, but than automatic categorizing will list all in SUSE_Linux/ / / / and categories will be useless. One of variants is to build groups as Basic_Topic/ / / and locate index that will point to the articles in top node Basic_Topic. The other way around, back to the top node, is already for free :-) Manually created and maintained indexes are a lot of work for editors, but it is easier to educate few editors how to build and maintain indexes than all writers. -- Regards, Rajko. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-wiki-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki-help@opensuse.org
Hello, (changing the subject because this is not really about the Bug Reporting FAQ) Am Sonntag, 18. Juni 2006 23:49 schrieb Rajko M: [...]
Today I was trying to figure out what would be the best logical structure (wording, naming) of openSUSE wiki so that people find it easy to remember and find articles.
Topic Bugs is similar to FAQ, HOWTO (HowTo), Installation, Update, etc. It has it's global meaning for SUSE Linux and local for versions and applications. We can go with
SUSE_Linux Bugs 10.0 system
Well, this is what is listed in the "wiki" named bugzilla.novell.com ;-) [...]
or SUSE_Linux 10.0 system kernel [...] or something in between.
Usually many things are version-independent, so I don't recommend to use the distribution number by default.
The one of ideas is to structure everything similar to directory structure on FTP servers. Once you learn one the other is the same or easy to browse.
There's a difference between Wiki and FTP. Not everything should go into a hierarchical tree in a wiki - and there are some symlinks on FTP when they are useful ;-)
What to use as glue? Simple / / / might be good, but than automatic categorizing will list all in SUSE_Linux/ / / / and categories will be useless.
Using / is a good idea for subpages with really related topics. Examples: Build_Service/*, HCL/* For less related topics, create a "main" page. Example: Pages about several KDE applications - it wouldn't be a good idea to list them as KDE/* Important in both cases: Enter the correct categories - these are good glue ;-)
One of variants is to build groups as Basic_Topic/ / / and locate index that will point to the articles in top node Basic_Topic. The other way around, back to the top node, is already for free :-)
Manually created and maintained indexes are a lot of work for editors, but it is easier to educate few editors how to build and maintain indexes than all writers.
You can simply link to Category:something and get an index for free also ;-) Regards, Christian Boltz --
wie kann ich auf ein Tape Drive drauf schauen? eject button drücken (oder mt -f <device> offl") und vors Auge halten? [> Mrvka Andreas und Andreas Kyek in suse-linux]
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-wiki-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki-help@opensuse.org
Christian Boltz wrote:
Hello,
(changing the subject because this is not really about the Bug Reporting FAQ)
Am Sonntag, 18. Juni 2006 23:49 schrieb Rajko M: [...]
Today I was trying to figure out what would be the best logical structure (wording, naming) of openSUSE wiki so that people find it easy to remember and find articles.
Topic Bugs is similar to FAQ, HOWTO (HowTo), Installation, Update, etc. It has it's global meaning for SUSE Linux and local for versions and applications. We can go with
SUSE_Linux Bugs 10.0 system
Well, this is what is listed in the "wiki" named bugzilla.novell.com ;-)
[...]
or SUSE_Linux 10.0 system kernel [...] or something in between.
Usually many things are version-independent, so I don't recommend to use the distribution number by default.
The one of ideas is to structure everything similar to directory structure on FTP servers. Once you learn one the other is the same or easy to browse.
There's a difference between Wiki and FTP. Not everything should go into a hierarchical tree in a wiki - and there are some symlinks on FTP when they are useful ;-)
What to use as glue? Simple / / / might be good, but than automatic categorizing will list all in SUSE_Linux/ / / / and categories will be useless.
Using / is a good idea for subpages with really related topics. Examples: Build_Service/*, HCL/*
For less related topics, create a "main" page. Example: Pages about several KDE applications - it wouldn't be a good idea to list them as KDE/*
Build_Service, HCL, KDE articles collected in disambiguation page is probably more a wiki way. I'll call it index. To one that types KDE in search, will get index page to select articles about applications, startup concepts, etc. Further indexes can be provided on separate pages or as paragraphs in one page. Both are searchable so the only criteria to select one over another is comfortable size for edit.
Important in both cases: Enter the correct categories - these are good glue ;-)
That is the point "correct categories". We don't have easy to follow naming structure. Everyone is free to name articles and categories at will, and that doesn't bring any good.
One of variants is to build groups as Basic_Topic/ / / and locate index that will point to the articles in top node Basic_Topic. The other way around, back to the top node, is already for free :-)
Manually created and maintained indexes are a lot of work for editors, but it is easier to educate few editors how to build and maintain indexes than all writers.
You can simply link to Category:something and get an index for free also ;-)
Again, that "something" is the main problem. Example: Virtualization, Virtual Machines, Emulators, and probably few more expressions for one thing. If everyone select one of names than we can see few articles about XEN listed in different places.
Regards,
Christian Boltz
I agree that categories are good glue, but their usefulness depends on systematic usage of words. I have multiple tasks here, to fight old habit to see all solutions as directory structure (/ / /), learn wiki philosophy and how they organized document tree, and in the same time look for optimal layout :-) Not easy. And all started with "Frontpage Redesign". After reading previous articles, try to find out where the problem is, it was obvious that main problem will be to make menus easy to use (user friendly) and that all will develop beyond simple menu arrangement. -- Regards, Rajko. Visit http://en.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-wiki-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki-help@opensuse.org
we can also continue with the "portal" way discussed earlier by pflodo, but the portal needs a maintainer. for now, we should maintain this page: http://en.opensuse.org/openSUSE:Browse may be enhanced a la french :-) http://fr.opensuse.org/openSUSE:Browse (needs refreshing also) jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-wiki-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki-help@opensuse.org
Christian Boltz wrote:
Hello,
I think http://en.opensuse.org/Bug_Reporting_FAQ should be splitted
as soon as a page get too large a split is good
Related question: What is a better page name - Bugs/YaST or Bugs:YaST?
/ have a special feature: there are sub-pages and are automatically linked to the main page (on the beginning of the subpage). so / must really be used on such split situation, given one don't use a completely different sheme. Categorisation of pages/sub page is logically different from the usual categorisation. the page in question is not a "bug" page, it's a "reporting bugs" one, very different topic. (not a list of bugs). in that case, categorization of the main "Bug_Reporting_FAQ" page is good (could be also categorized as report and FAQ), but sub pages should _not_ be categorized as "bugs". However they could be on they particular subject (bugzilla for one page, YaST for an other...). it is probably not so advisable to have a page tree too deep. main pages/sub pages should be seen like a book. The main page is the table of contents, the sub pages the chapters. After that the sections works. the XXX: sheme should be reserved to Interwiki or namespace use, if not the risk of collision is high. and the onlu real interest of namespace is the ability of searching diffent namespaces with the wiki search and the special page. jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-wiki-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki-help@opensuse.org
Hello, Am Montag, 19. Juni 2006 08:41 schrieb jdd:
Christian Boltz wrote:
I think http://en.opensuse.org/Bug_Reporting_FAQ should be splitted
as soon as a page get too large a split is good
Yes, in particular if the content isn't that related (yes, it's all about reporting bugs, but in different parts of the system).
Related question: What is a better page name - Bugs/YaST or Bugs:YaST?
/ have a special feature: there are sub-pages and are automatically linked to the main page (on the beginning of the subpage).
That's why I'm going to use it ;-)
the page in question is not a "bug" page, it's a "reporting bugs" one, very different topic. (not a list of bugs).
Come on - we all know that there's no "bugs" page because the bugs go to bugzilla. Reporting_bugs/* would be perfectly correct, but IMHO it's too long to type (remember that these links are often posted in bugzilla, I guess it's not always copy&paste ;-) I still prefer Bugs/* which can be typed really fast if needed (probably faster than copy&paste!) and still has a meaningful name.
in that case, categorization of the main "Bug_Reporting_FAQ" page is good (could be also categorized as report and FAQ), but sub pages should _not_ be categorized as "bugs". However they could be on they particular subject (bugzilla for one page, YaST for an other...).
Maybe there should be a (sub?)category "reporting bugs" for all of them...
the XXX: sheme should be reserved to Interwiki or namespace use, if not the risk of collision is high. and the onlu real interest of namespace is the ability of searching diffent namespaces with the wiki search and the special page.
So Bugs:* isn't a good idea - nice to see that we agree here ;-) Regards, Christian Boltz --
My calendar shows May 12th to be a Friday, not a Thursday? I meant 11th ;-(. With all the delays, perhaps mentioning the year would also be a good idea. ;-) [> Andreas Jaeger and houghi in opensuse]
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-wiki-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki-help@opensuse.org
Christian Boltz wrote:
Maybe there should be a (sub?)category "reporting bugs" for all of them...
sub categories works as well as sub pages, but in a little diffenrent way. to have a category enter an other category as sub, it suffice to add [[category:XXX]] _in the category page_ better with an example: http://fr.opensuse.org/index.php?title=Cat%C3%A9gorie:T%C3%A9l%C3%A9chargement&action=edit jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-wiki-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki-help@opensuse.org
participants (3)
-
Christian Boltz -
jdd -
Rajko M