-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Lasarsch wrote:

Hi - is this point of view valid for most of you? - do we need the separation?

I looked at the separation from the perspective of someone who has something to write up on the wiki and is trying to figure out where it goes. Following your separation definition, I would suggest this as a more concise way to tell if it is SDB or HOWTO: - - If it is reactive (i.e. there was a problem de facto, this is how I solved it) then that's an SDB - - If it is proactive (my box is fine, but I'd like to figure out how to do this or that) then this would be HOWTO Of course the problem with that is we might end up with a lot of HOWTOs or varying intensity (en.opensuse.org/HOWTO_chage_user_picture_in_KDE ; eek!), but that's a different issue. Could call 'em mini-howtos or just let them accumulate and then corral them off into a section which can be inaugurated down the line called "Tips and Tricks" or whatever we please then. This method of separating has the advantage that it is less confusing, which would hopefully translate to more entry-level user contributions (gotta start somewhere!).

- what is missing?

* SDB

<snip> What I like about SDB is that there is a set format. No telling what kind of funny things we could do with a broad selection of articles all coherently formatted. Of course, new contributors might just want to rush to dump a snippet of wisdom on the wiki; having to follow a very specific set of formatting rules might be off-putting. I'm not immediately sure how to address that; maybe encouraging documentation free-for-alls in user pages and then polishing these into SDBs? Worth thinking about; I genuinely think there's value in standardized documentation.

* Howto

<snip>

* FAQ

<snip> I'll add one more thing just to stir up the pot; screencasts. Should that be a fourth category? JA - -- http://www.DonAssad.com jabber ID: josef.assad@gmail.com Please consider the environment; do you really need to print out this e-mail? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHFjshFcf72sjD2+QRAt9YAJ9e3r/8dCV68jhJ52oSRIqWxCq9DwCcDXAD qZ0vguUq2us/R0j3CwkWxDc= =JlW+ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Wednesday 17 October 2007 11:41:05 am Josef Assad wrote:

I looked at the separation from the perspective of someone who has something to write up on the wiki and is trying to figure out where it goes. Following your separation definition, I would suggest this as a more concise way to tell if it is SDB or HOWTO:

- If it is reactive (i.e. there was a problem de facto, this is how I solved it) then that's an SDB - If it is proactive (my box is fine, but I'd like to figure out how to do this or that) then this would be HOWTO

Hi Asad, I vote for your definition. That is what SDB was for me, a solution for existing problem: - summary of bug fix in bugzilla, and link where to pick up patch, or - workaround until bug is fixed - small fixes of default configuration which is not a bug, but needed to run some application Though, IMHO SDB should not be edited at will. It has to be dependable source of information, it should be protected. Everyone has enough space on wiki to write articles, and when they are good quality and fit in the SDB concept, than it is easy to include them in SDB. -- Regards, Rajko. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Wednesday 17 October 2007 12:54:54 pm Martin Lasarsch wrote:

On Wednesday 17 October 2007 19:44:07 Rajko M. wrote: <snip>

...

Though, IMHO SDB should not be edited at will. It has to be dependable source of information, it should be protected.

Everyone has enough space on wiki to write articles, and when they are good quality and fit in the SDB concept, than it is easy to include them in SDB.

i'm not agreeing with that, i don't want to protect stuff. But yes, this could be an option (actually i'm not sure if you can protect the whole namespace ... dunno).

Yet another Server (YaS) if no other options are left :-) Proposal to protect articles is based on importance to have one dependable source of information how to solve existing problem, that is reviewed by guys that know how certain subsystem is working. We can have article with the same name in a Main namespace, open for editing, and whoever would be SDB maintainer can incorporate changes in SDB. -- Regards, Rajko. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On 10/18/07, Josef Assad wrote:

The first point up there goes to the heart of what Martin is working on: the separation. The second point up there goes to the issue of, how do we make contributions more accessible. I think the real challenge is, how can we have structured and consistent documentation like SDB and not scare potential contributors off with an elaborate style and formatting guide.

Well the answer is simple, and it is the same principle that Wikipedia uses. Someone else will fix your formatting :-) Ie the emphasis should be that we are looking for good content. Wiki editors should help with the formatting, catagorizing and naming of pages, ideally by educating the contributor. Of course Wiki editors can only do this properly if they all do it in a consistent manner following clear guidelines that come out of discussions like this one. By Wiki Editor, I mean openSUSE community members who like to contribute to the project by organising the wiki, not any sort of appointed position. Pflodo Peter Flodin --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Hello, on Mittwoch, 17. Oktober 2007, Martin Lasarsch wrote:

ok, i have still the bug open for a long time, here is my point of view for discussion. The wiki makes it possible to clutter a lot of pages over the whole wiki, or try to make some kind of order.

- is this point of view valid for most of you? - do we need the separation? - what is missing?

The important things about SDB/Howto separation were already said, and I don't have to add much on it. Perhaps one thing: I don't think that the SDB should be protected - this will only add workload to the admins without a real need. I remember only a single SDB page that doesn't qualify as "good" SDB page [1], which means there are nearly no quality problems in the SDB. Though, I haven't read all the SDB pages ;-)

* FAQ - should have a separate namespace: FAQ: - short and to the point - the general FAQ layout should be known, so no more explanation here - we should have a FAQ launchpage with all FAQs on it

I assume we are mostly talking about "technical" FAQs here. I wonder if we can really separate them from SDB articles and (mini) Howtos... IMHO there are two reasons why someone reads FAQs: - there's a problem and he/she wants a solution -> SDB - someone wants to enhance his system setup [insert any example between user icon in KDM and mailserver setup here] -> Howto I don't believe that users read FAQs to see what problems they could theoretically hit. Many users don't even read the release notes... For "non-technical" FAQs there's already /FAQ covering many issues, and I don't see enough questions for a separate namespace. I'm also not sure if too many namespaces are useful. If you create too many of them, people will start to request even more. For example, I could bring up the idea to have a "Meetings:" namespace for all meetings and transcripts ;-) (which would be more useful than a FAQ namespace, because meeting transcripts can really clutter up search results.) Regards, Christian Boltz [1] http://en.opensuse.org/SDB:USB_Wireless_Adpater_Using_Ralink_RT73_Chipset_(D...) -- Die kundenfreundlichste Firma der Welt ist Microsoft. Da ist jeder Tag ein neuer "Tag der offenen Tür". [Ratti in suse-linux] --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Tuesday 23 October 2007 07:14:41 am Martin Lasarsch wrote:

On Wednesday 17 October 2007 16:54:53 Martin Lasarsch wrote:

...

Hi

ok, i have still the bug open for a long time, here is my point of view for discussion. The wiki makes it possible to clutter a lot of pages over the whole wiki, or try to make some kind of order.

- is this point of view valid for most of you? - do we need the separation? - what is missing?

I tried to write all your comments down: http://en.opensuse.org/SDB/Howto/FAQ

Did i missed something?

I guess not. There is MHO (from IMHO): I would avoid construct 'SDB/Howto/FAQ' SDB main page SDB/Howto subpage Howto of SDB SDB/Howto/FAQ subpage of SDB/Howto Now friendly editor can jump in and help by writing article about Howto and wiki will create back link < SDB|Howto hiding your original SDB. [1] =FAQ= 'initialism' maybe to use 'acronym' or 'stands for' 'FAQ' name space does exist [I searched for 'grumpy' and looked at the bottom of the page for all namespaces.] =Misc= <add> Keep in mind - at openSUSE we are friendly people - if article was moved or changed it is done with good intention - if you disagree tell other editor your point of view on Discussion page [1] I think that subpages are not properly used creating article title that is unnecessary long and sometimes wrapped. Yours is, not so often seen, example of readable title. -- Regards, Rajko. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Thursday 18 October 2007 00:22:45 Josef Assad wrote:

Peter Flodin wrote:

...

On 10/18/07, Josef Assad wrote:

...

The first point up there goes to the heart of what Martin is working on: the separation. The second point up there goes to the issue of, how do we make contributions more accessible. I think the real challenge is, how can we have structured and consistent documentation like SDB and not scare potential contributors off with an elaborate style and formatting guide.

Well the answer is simple, and it is the same principle that Wikipedia uses. Someone else will fix your formatting :-)

I was hoping the Wiki Team would claim this one (didn't want to volunteer anyone) and the Wiki Team doesn't disappoint. :) I agree entirely.

regarding your flowchart: i think this is a good idea, but i'm not sure if the FAQ branch is ok. A FAQ is for me: Q: Virtualbox is not starting and complains about a module A: you have to load vboxdrv, bla bla Q: I loaded the modul but it's still complaining A: you have to set the right permisions, bla bla These are 2 examples of _common_ problems a newbie with Virtualbox will have when he don't bother to read the documentation (what usually nobody does :-)). My rephrasing would be: Look if there is an existing FAQ and add the solution if needed. If there is no existing FAQ, think about starting a new FAQ about the component/program. maybe i just don't understand your sentence right away ... -- with kind regards, Martin Lasarsch, Core Services SUSE LINUX Products GmbH, Maxfeldstr. 5 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) martin.lasarsch@suse.de - http://www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Wednesday 24 October 2007 09:46:20 am Martin Lasarsch wrote:

On Tuesday 23 October 2007 21:23:49 Rajko M. wrote:

[...]

...

I guess not. There is MHO (from IMHO):

I would avoid construct 'SDB/Howto/FAQ' SDB main page SDB/Howto subpage Howto of SDB SDB/Howto/FAQ subpage of SDB/Howto

Now friendly editor can jump in and help by writing article about Howto and wiki will create back link < SDB|Howto hiding your original SDB. [1]

Is SDB-Howto-FAQ better?

Yes.

...

=FAQ= 'initialism' maybe to use 'acronym' or 'stands for'

It's a quote, change it upstream on wikipedia :-)

:-D You can use any quote there is also 'acronym' on wikipedia. It is obvious from my posts that I'm not native English speaker. I would not notice if there was no need to reread the sentence and get meaning.

...

'FAQ' name space does exist [I searched for 'grumpy' and looked at the bottom of the page for all namespaces.]

Yes, but i thought that we should not use it?

I never got any announcement in that direction. Namespace FAQ exists in Mediawiki just for that purpose. This is currently on our wiki: http://en.opensuse.org/FAQ:FAQ http://en.opensuse.org/FAQ:HOWTO http://en.opensuse.org/FAQ:Novell-MS and there will be more if we would advertise it. If one is searching for "faq" and is using 'Go' it gives 1 answer, the official 'Frequently Asked Questions', where is no word about any other. So user has to know in advance to use 'Search' instead to get other results. Just found out, that redirect 'faq' -> 'Frequently Asked Questions' was set by another openSUSE wiki user. I can take care of this tomorrow, if you want. The page http://en.opensuse.org/faq will display links to official and few other existing Frequently Asked Questions. It will be some kind of disambiguation page.

...

=Misc= <add> Keep in mind - at openSUSE we are friendly people - if article was moved or changed it is done with good intention - if you disagree tell other editor your point of view on Discussion page

good points, i added them.

-- Regards, Rajko. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org