[opensuse-marketing] The openSUSE Handbook proposal
Hello there, I was thinking that having an openSUSE Handbook (or handbuch ;) in pdf format ready to be downloaded, printed and even ready to be sent to a publishing company is a good idea. So, here's my proposal: First, we would have to make a list of topics to be included and organise them in chapters, like the following draft: ****************************** The openSUSE Handbook ****************************** Introduction - What's the openSUSE project? - What's openSUSE? Installing openSUSE - Different types of install methods - AutoYaST Installing applications - Using 1-click - Using YaST - Using zypper Desktop environments - An introduction to DEs (KDE, GNOME, XFCE, LXDE). - Enabling proprietary drivers (ATI, NVIDIA) - Multimedia - Printing - Games System administration - Introduction to the command line - Networking - Security - Storage - Virtualization - Keeping openSUSE up-to-date - Upgrading openSUSE Servers - Apache and lighttpd - MySQL and PostgreSQL - Postfix - BIND - Samba - CUPS etc Other openSUSE Technologies - Build Service - SUSE Studio - KIWI Second, we would have to write about those topics not included in the wiki and review those already written. That way we would have more relevant bits in both the wiki and handbook. Each topic doesn't have to be 100 page long ;-) And last but not least we would have to put all the pieces together and make it available in pdf. Drawbacks: We would need to update some of its contents for each openSUSE release. It needs more than two people to make it happen ;-) On the other hand, I think that the handbook would make openSUSE more "visible" and a bit more "ready to use." Comments and suggestions are welcome! :-) Cheers, -- Javier Llorente
On Wed, Sep 29, 2010 at 2:27 PM, Javier Llorente
Hello there,
I was thinking that having an openSUSE Handbook (or handbuch ;) in pdf format ready to be downloaded, printed and even ready to be sent to a publishing company is a good idea.
So, here's my proposal:
First, we would have to make a list of topics to be included and organise them in chapters, like the following draft:
****************************** The openSUSE Handbook ****************************** Introduction - What's the openSUSE project? - What's openSUSE?
Installing openSUSE - Different types of install methods - AutoYaST
Installing applications - Using 1-click - Using YaST - Using zypper
Desktop environments - An introduction to DEs (KDE, GNOME, XFCE, LXDE). - Enabling proprietary drivers (ATI, NVIDIA) - Multimedia - Printing - Games
System administration - Introduction to the command line - Networking - Security - Storage - Virtualization - Keeping openSUSE up-to-date - Upgrading openSUSE
Servers - Apache and lighttpd - MySQL and PostgreSQL - Postfix - BIND - Samba - CUPS etc
Other openSUSE Technologies - Build Service - SUSE Studio - KIWI
Second, we would have to write about those topics not included in the wiki and review those already written. That way we would have more relevant bits in both the wiki and handbook. Each topic doesn't have to be 100 page long ;-)
And last but not least we would have to put all the pieces together and make it available in pdf.
Drawbacks: We would need to update some of its contents for each openSUSE release. It needs more than two people to make it happen ;-)
On the other hand, I think that the handbook would make openSUSE more "visible" and a bit more "ready to use."
Comments and suggestions are welcome! :-)
Cheers, -- Javier Llorente
Sounds good, may you could ask people to pick a subject and write about, then set a dead line for the first draft. That's just my thought. -- ----------------------------------------- Discover it! Enjoy it! Share it! openSUSE Linux. ----------------------------------------- openSUSE -- en.opensuse.org/User:Terrorpup openSUSE Ambassador/openSUSE Member skype,twiiter,identica,friendfeed -- terrorpup freenode(irc) --terrorpup/lupinstein Have you tried SUSE Studio? Need to create a Live CD, an app you want to package and distribute , or create your own linux distro. Give SUSE Studio a try. www.susestudio.com. -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
Would be a complement to http://en.opensuse.org/SDB:Official_documentation?
On Wed, Sep 29, 2010 at 15:27, Javier Llorente
Hello there,
I was thinking that having an openSUSE Handbook (or handbuch ;) in pdf format ready to be downloaded, printed and even ready to be sent to a publishing company is a good idea.
So, here's my proposal:
First, we would have to make a list of topics to be included and organise them in chapters, like the following draft:
****************************** The openSUSE Handbook ****************************** Introduction - What's the openSUSE project? - What's openSUSE?
Installing openSUSE - Different types of install methods - AutoYaST
Installing applications - Using 1-click - Using YaST - Using zypper
Desktop environments - An introduction to DEs (KDE, GNOME, XFCE, LXDE). - Enabling proprietary drivers (ATI, NVIDIA) - Multimedia - Printing - Games
System administration - Introduction to the command line - Networking - Security - Storage - Virtualization - Keeping openSUSE up-to-date - Upgrading openSUSE
Servers - Apache and lighttpd - MySQL and PostgreSQL - Postfix - BIND - Samba - CUPS etc
Other openSUSE Technologies - Build Service - SUSE Studio - KIWI
Second, we would have to write about those topics not included in the wiki and review those already written. That way we would have more relevant bits in both the wiki and handbook. Each topic doesn't have to be 100 page long ;-)
And last but not least we would have to put all the pieces together and make it available in pdf.
Drawbacks: We would need to update some of its contents for each openSUSE release. It needs more than two people to make it happen ;-)
On the other hand, I think that the handbook would make openSUSE more "visible" and a bit more "ready to use."
Comments and suggestions are welcome! :-)
Cheers, -- Javier Llorente
-- Raul Libório http://rauhmaru.blogspot.com/ rauhmarutsªhotmailºcom openSUSE Member | Linux User #4444581 "There are only 10 types of people in the world - Those who understand binary, and those who don't." -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
On Miércoles, 29 de Septiembre de 2010 21:00:29 Raul Libório escribió:
Would be a complement to http://en.opensuse.org/SDB:Official_documentation?
Yepp. Some topics aren't covered in the official docs. Nevertheless, it could be reused. Greetings, -- Javier Llorente
On Thu, 30 Sep 2010 00:56:25 +0200 Javier Llorente wrote: Hi,
On Miércoles, 29 de Septiembre de 2010 21:00:29 Raul Libório escribió:
Would be a complement to http://en.opensuse.org/SDB:Official_documentation?
Yepp. Some topics aren't covered in the official docs. Nevertheless, it could be reused.
I would prefer to improve and extend the existing documentation rather than to fork it... -- Regards Frank Frank Sundermeyer, Technical Writer, Documentation SUSE Linux Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Tel: +49-911-74053-0, Fax: +49-911-7417755; http://www.opensuse.org/ SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) "Reality is always controlled by the people who are most insane" Dogbert -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
On Thursday 30 September 2010 13:00:02 Frank Sundermeyer wrote:
On Thu, 30 Sep 2010 00:56:25 +0200 Javier Llorente wrote:
Hi,
On Miércoles, 29 de Septiembre de 2010 21:00:29 Raul Libório escribió:
Would be a complement to http://en.opensuse.org/SDB:Official_documentation?
Yepp. Some topics aren't covered in the official docs. Nevertheless, it could be reused.
I would prefer to improve and extend the existing documentation rather than to fork it...
Frank, I'm glad to see you on this thread. I doubt the current activity on Piratepad comes from a desire to fork, but instead out of ignorance how to contribute. Perhaps you could find the links to how to contribute to the existing documentation and explain how our in-house docu system allows publishing in multiple formats? Elsewhere in the thread people suggested making proper ebook reader formats. Will -- Will Stephenson, KDE Developer, openSUSE Boosters Team SUSE LINUX Products GmbH - Nürnberg - AG Nürnberg - HRB 16746 - GF: Markus Rex -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
On Thu, 30 Sep 2010 13:40:44 +0200 Will Stephenson wrote: Hi,
On Thursday 30 September 2010 13:00:02 Frank Sundermeyer wrote:
On Thu, 30 Sep 2010 00:56:25 +0200 Javier Llorente wrote:
Hi,
On Miércoles, 29 de Septiembre de 2010 21:00:29 Raul Libório escribió:
Would be a complement to http://en.opensuse.org/SDB:Official_documentation?
Yepp. Some topics aren't covered in the official docs. Nevertheless, it could be reused.
I would prefer to improve and extend the existing documentation rather than to fork it...
Frank, I'm glad to see you on this thread. I doubt the current activity on Piratepad comes from a desire to fork, but instead out of ignorance how to contribute.
please everyone interested in contributing to the existing openSUSE documentation or to Lessons for Lizards (cookbook) come to the opensuse-doc mailinglist to discuss details!
Perhaps you could find the links to how to contribute to the existing documentation and explain how our in-house docu system allows publishing in multiple formats? Elsewhere in the thread people suggested making proper ebook reader formats.
Well, up to now there hasn't been a need to open our documents to contribution, because simply no one has asked for it. But as I pointed out in another post, everything has already been set up on Berlios, so we can make our sources available in short time. As for the "how", it is basically (the instructions are 3 years old) the same that applied to the Lessons for Lizards project. http://developer.novell.com/wiki/index.php/Lessons_for_Lizards See the "Getting help" section for details. As a quick start, if ppl are interested, we could revive the LfL project on Berlios. Could be ready some time next week. Lately we have been working on an automatic Book Building software with a virtual web based library called openSUSE Book Builder. That would come in handy when having a community book project ;-). Everyone interested please come to our talk at the conference: http://conference.opensuse.org/indico//contributionDisplay.py?contribId=71&confId=0 -- Regards Frank Frank Sundermeyer, Technical Writer, Documentation SUSE Linux Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Tel: +49-911-74053-0, Fax: +49-911-7417755; http://www.opensuse.org/ SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) "Reality is always controlled by the people who are most insane" Dogbert -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
On Jueves, 30 de Septiembre de 2010 13:00:02 Frank Sundermeyer escribió:
On Thu, 30 Sep 2010 00:56:25 +0200 Javier Llorente wrote:
Hi,
On Miércoles, 29 de Septiembre de 2010 21:00:29 Raul Libório escribió:
Would be a complement to http://en.opensuse.org/SDB:Official_documentation?
Yepp. Some topics aren't covered in the official docs. Nevertheless, it could be reused.
I would prefer to improve and extend the existing documentation rather than to fork it...
I don't want to fork it. I'm just saying that some topics aren't covered and that perhaps building a handbook out of different sources would be good (a centralized reference book). Work is done on wiki, etc. and then afterwards we generate the handbook. Greetings, -- Javier Llorente
Good stuff, specially if it is at the level of the previous which came with SuSE Linux (I have from 6.0 to 7.1). Though I've really never used them, they used to pack powerful information for anyone moving in to SuSE Linux back then. I look forward to see a community driver 'cook book' for openSUSE. nelson. On Wed, 2010-09-29 at 20:27 +0200, Javier Llorente wrote:
Hello there,
I was thinking that having an openSUSE Handbook (or handbuch ;) in pdf format ready to be downloaded, printed and even ready to be sent to a publishing company is a good idea.
So, here's my proposal:
First, we would have to make a list of topics to be included and organise them in chapters, like the following draft:
****************************** The openSUSE Handbook ****************************** Introduction - What's the openSUSE project? - What's openSUSE?
Installing openSUSE - Different types of install methods - AutoYaST
Installing applications - Using 1-click - Using YaST - Using zypper
Desktop environments - An introduction to DEs (KDE, GNOME, XFCE, LXDE). - Enabling proprietary drivers (ATI, NVIDIA) - Multimedia - Printing - Games
System administration - Introduction to the command line - Networking - Security - Storage - Virtualization - Keeping openSUSE up-to-date - Upgrading openSUSE
Servers - Apache and lighttpd - MySQL and PostgreSQL - Postfix - BIND - Samba - CUPS etc
Other openSUSE Technologies - Build Service - SUSE Studio - KIWI
Second, we would have to write about those topics not included in the wiki and review those already written. That way we would have more relevant bits in both the wiki and handbook. Each topic doesn't have to be 100 page long ;-)
And last but not least we would have to put all the pieces together and make it available in pdf.
Drawbacks: We would need to update some of its contents for each openSUSE release. It needs more than two people to make it happen ;-)
On the other hand, I think that the handbook would make openSUSE more "visible" and a bit more "ready to use."
Comments and suggestions are welcome! :-)
Cheers,
-- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
yeah! Nelson, talking about cookbooks, makes me remember what I saw last night. http://en.opensuse.org/SDB:KIWI_Cookbook_Start_Cooking http://en.opensuse.org/SDB:KIWI_Cookbook_Virtual_Image http://en.opensuse.org/SDB:KIWI_Cookbook_Own_Cloud awesome http://en.opensuse.org/SDB:KIWI_Cookbook_LiveSystem http://en.opensuse.org/SDB:KIWI_Cookbook_Splash_Screen http://en.opensuse.org/SDB:KIWI_Cookbook_Live_USB-Stick Em Qua, 2010-09-29 às 20:14 +0100, Nelson Marques escreveu:
Good stuff, specially if it is at the level of the previous which came with SuSE Linux (I have from 6.0 to 7.1). Though I've really never used them, they used to pack powerful information for anyone moving in to SuSE Linux back then.
I look forward to see a community driver 'cook book' for openSUSE.
nelson.
On Wed, 2010-09-29 at 20:27 +0200, Javier Llorente wrote:
Hello there,
I was thinking that having an openSUSE Handbook (or handbuch ;) in pdf format ready to be downloaded, printed and even ready to be sent to a publishing company is a good idea.
So, here's my proposal:
First, we would have to make a list of topics to be included and organise them in chapters, like the following draft:
****************************** The openSUSE Handbook ****************************** Introduction - What's the openSUSE project? - What's openSUSE?
Installing openSUSE - Different types of install methods - AutoYaST
Installing applications - Using 1-click - Using YaST - Using zypper
Desktop environments - An introduction to DEs (KDE, GNOME, XFCE, LXDE). - Enabling proprietary drivers (ATI, NVIDIA) - Multimedia - Printing - Games
System administration - Introduction to the command line - Networking - Security - Storage - Virtualization - Keeping openSUSE up-to-date - Upgrading openSUSE
Servers - Apache and lighttpd - MySQL and PostgreSQL - Postfix - BIND - Samba - CUPS etc
Other openSUSE Technologies - Build Service - SUSE Studio - KIWI
Second, we would have to write about those topics not included in the wiki and review those already written. That way we would have more relevant bits in both the wiki and handbook. Each topic doesn't have to be 100 page long ;-)
And last but not least we would have to put all the pieces together and make it available in pdf.
Drawbacks: We would need to update some of its contents for each openSUSE release. It needs more than two people to make it happen ;-)
On the other hand, I think that the handbook would make openSUSE more "visible" and a bit more "ready to use."
Comments and suggestions are welcome! :-)
Cheers,
-- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
On Miércoles, 29 de Septiembre de 2010 21:14:58 usted escribió:
Good stuff, specially if it is at the level of the previous which came with SuSE Linux (I have from 6.0 to 7.1). Though I've really never used them, they used to pack powerful information for anyone moving in to SuSE Linux back then.
I look forward to see a community driver 'cook book' for openSUSE.
Oh. That's another thing... it could be called "cookbook." But that's for the next step. ;) Cheers, -- Javier Llorente
On Wednesday 29 September 2010 20:27:11 Javier Llorente wrote:
Hello there,
I was thinking that having an openSUSE Handbook (or handbuch ;) in pdf format ready to be downloaded, printed and even ready to be sent to a publishing company is a good idea.
So, here's my proposal:
<snip>
Second, we would have to write about those topics not included in the wiki and review those already written. That way we would have more relevant bits in both the wiki and handbook. Each topic doesn't have to be 100 page long ;-)
And last but not least we would have to put all the pieces together and make it available in pdf.
Drawbacks: We would need to update some of its contents for each openSUSE release. It needs more than two people to make it happen ;-)
On the other hand, I think that the handbook would make openSUSE more "visible" and a bit more "ready to use."
Comments and suggestions are welcome! :-)
Ambitious, but a good idea. We can do the writing either on the wiki or in piratepads (but piratepad has been acting up lately, I really really hope someone feels like setting up an Etherpad for openSUSE). If you want, take this on. As in, be the project manager ;-) So create the wiki's, try and put in some preliminary info and get ppl to write...
Cheers,
On Wednesday 29 September 2010 20:27:11 Javier Llorente wrote:
Hello there,
I was thinking that having an openSUSE Handbook (or handbuch ;) in pdf format ready to be downloaded, printed and even ready to be sent to a publishing company is a good idea.
So, here's my proposal:
<snip> Could not be also available in other open documentation format? To help other ambassadors to download and adapt to their needs or even end-users, developers and companies. Let's suppose that we got such big companies like Petrobras, Banco do Brasil, Pegeot, HSBC, that already are hard openSUSE or SLE based adopters and they wishes to have their own opensuse handbook - with more focus, contents, screenshots to but
Javier, Pretty good idea, also I believe will be good if you talk a little bit about our project and idea with Manu because as I know he is working on a project called suseware, http://suseware.com/home/ and If I'm not mistake the main purpose of suseware is to delivery training materials for openSUSE using moodle as LMS tool. Also I have some links that I like to share with you tha I think could be used as good references for your project. http://www.easywebtech.com/ebooks/Free_Suse_ebooks_Download-0.html http://ocw.novell.com/suse-linux-enterprise-desktop/get-ready-for-open-sourc... http://ocw.novell.com/suse-linux-enterprise-desktop/get-ready-for-open-sourc... http://www.opensuse-guide.org/ http://ocw.novell.com/ - so good http://www.novell.com/documentation/opensuse113/pdfdoc/art_osuse_installquic... http://developer.novell.com/wiki/index.php/Lessons_for_Lizards http://www.novell.com/documentation/opensuse113 http://en.opensuse.org/openSUSE:Cheat_sheets http://en.opensuse.org/SDB:How_to_migrate_to_a_new_openSUSE_version Another topic that I would like to talk with you about your project is "localizations" What do you think to have this material at least localized to all ambassadors native languages? I believe as ambassadors we have a valuable skill to be explored, almost of us have some kind of influence in some universities, then I believe we can try to find volunteers within universities and schools to help us to speed up the localization process. more bellow.. Em Qua, 2010-09-29 às 21:59 +0200, Jos Poortvliet escreveu: based and adapted to their own openSUSE usage and needs.
Second, we would have to write about those topics not included in the wiki and review those already written. That way we would have more relevant bits in both the wiki and handbook. Each topic doesn't have to be 100 page long ;-)
And last but not least we would have to put all the pieces together and make it available in pdf.
My comments here are identical as let above. Also could be available for other open formats, not only pdf.
Drawbacks: We would need to update some of its contents for each openSUSE release. It needs more than two people to make it happen ;-)
Let's try to use some universities cooperation. If we develop a kind of openSUSE universities partnership proposal could be very helpful but also possible without this partnership proposal ;) - Public and Private schools and universities the only difference is how to approach ;)
On the other hand, I think that the handbook would make openSUSE more "visible" and a bit more "ready to use."
Sure
Comments and suggestions are welcome! :-)
Ambitious, but a good idea. We can do the writing either on the wiki or in piratepads (but piratepad has been acting up lately, I really really hope someone feels like setting up an Etherpad for openSUSE).
If you want, take this on. As in, be the project manager ;-)
So create the wiki's, try and put in some preliminary info and get ppl to write...
Cheers,
best luck and wishes CarlosRibeiro PS Do not forget to take a chat with Manu about your thoughts -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
Hi Carlos On Miércoles, 29 de Septiembre de 2010 23:47:52 Carlos Ribeiro escribió:
Javier,
Pretty good idea, also I believe will be good if you talk a little bit about our project and idea with Manu because as I know he is working on a project called suseware, http://suseware.com/home/ and If I'm not mistake the main purpose of suseware is to delivery training materials for openSUSE using moodle as LMS tool.
I didn't know suseware. I have visited its website but I can't see any content (only icons which bring you nowhere). Maybe it's me? My main idea isn't making it as a training material. It's more of a quick reference book or cookbook.
Also I have some links that I like to share with you tha I think could be used as good references for your project.
http://www.easywebtech.com/ebooks/Free_Suse_ebooks_Download-0.html http://ocw.novell.com/suse-linux-enterprise-desktop/get-ready-for-open-sour ce-suse-linux-enterprise-desktop-book-1 http://ocw.novell.com/suse-linux-enterprise-desktop/get-ready-for-open-sou rce-suse-linux-enterprise-desktop-book-2 http://www.opensuse-guide.org/ http://ocw.novell.com/ - so good http://www.novell.com/documentation/opensuse113/pdfdoc/art_osuse_installqui ck_113/art_osuse_installquick_113.pdf http://developer.novell.com/wiki/index.php/Lessons_for_Lizards http://www.novell.com/documentation/opensuse113 http://en.opensuse.org/openSUSE:Cheat_sheets http://en.opensuse.org/SDB:How_to_migrate_to_a_new_openSUSE_version
Thanks for the rain of links!! :-)
Another topic that I would like to talk with you about your project is "localizations" What do you think to have this material at least localized to all ambassadors native languages? I believe as ambassadors we have a valuable skill to be explored, almost of us have some kind of influence in some universities, then I believe we can try to find volunteers within universities and schools to help us to speed up the localization process.
Of course. The more translations, the better. Nevertheless, I think it's better to focus on English to begin with and later on "freeze" it to help translators.
more bellow..
Em Qua, 2010-09-29 às 21:59 +0200, Jos Poortvliet escreveu:
On Wednesday 29 September 2010 20:27:11 Javier Llorente wrote:
Hello there,
I was thinking that having an openSUSE Handbook (or handbuch ;) in pdf format ready to be downloaded, printed and even ready to be sent to a publishing company is a good idea.
So, here's my proposal: <snip>
Could not be also available in other open documentation format? To help other ambassadors to download and adapt to their needs or even end-users, developers and companies. Let's suppose that we got such big companies like Petrobras, Banco do Brasil, Pegeot, HSBC, that already are hard openSUSE or SLE based adopters and they wishes to have their own opensuse handbook - with more focus, contents, screenshots to but based and adapted to their own openSUSE usage and needs.
Sure. It could be in more than one format. That's something to take into account once this takes off.
Second, we would have to write about those topics not included in the wiki and review those already written. That way we would have more relevant bits in both the wiki and handbook. Each topic doesn't have to be 100 page long ;-)
And last but not least we would have to put all the pieces together and make it available in pdf.
My comments here are identical as let above. Also could be available for other open formats, not only pdf.
Drawbacks: We would need to update some of its contents for each openSUSE release. It needs more than two people to make it happen ;-)
Let's try to use some universities cooperation. If we develop a kind of openSUSE universities partnership proposal could be very helpful but also possible without this partnership proposal ;) - Public and Private schools and universities the only difference is how to approach ;)
Cooperating with universities is a good idea. The thing is to contact the right people to present this to I suppose, unless you already know them or know someone who knows them.
On the other hand, I think that the handbook would make openSUSE more "visible" and a bit more "ready to use."
Sure
Comments and suggestions are welcome! :-)
Ambitious, but a good idea. We can do the writing either on the wiki or in piratepads (but piratepad has been acting up lately, I really really hope someone feels like setting up an Etherpad for openSUSE).
If you want, take this on. As in, be the project manager ;-)
So create the wiki's, try and put in some preliminary info and get ppl to write...
Cheers,
best luck and wishes CarlosRibeiro
PS Do not forget to take a chat with Manu about your thoughts
What's his nickname? Thanks a lot for your feedback! Greetings, -- Javier Llorente
On Miércoles, 29 de Septiembre de 2010 21:59:56 Jos Poortvliet escribió:
On Wednesday 29 September 2010 20:27:11 Javier Llorente wrote:
Hello there,
I was thinking that having an openSUSE Handbook (or handbuch ;) in pdf format ready to be downloaded, printed and even ready to be sent to a publishing company is a good idea.
So, here's my proposal: <snip>
Second, we would have to write about those topics not included in the wiki and review those already written. That way we would have more relevant bits in both the wiki and handbook. Each topic doesn't have to be 100 page long ;-)
And last but not least we would have to put all the pieces together and make it available in pdf.
Drawbacks: We would need to update some of its contents for each openSUSE release. It needs more than two people to make it happen ;-)
On the other hand, I think that the handbook would make openSUSE more "visible" and a bit more "ready to use."
Comments and suggestions are welcome! :-)
Ambitious, but a good idea. We can do the writing either on the wiki or in piratepads (but piratepad has been acting up lately, I really really hope someone feels like setting up an Etherpad for openSUSE).
Yes, it's a bit ambitious. But there's also work already done (like some docs on the wiki for instance).
If you want, take this on. As in, be the project manager ;-)
Now I am the cook of the book :D
So create the wiki's, try and put in some preliminary info and get ppl to write...
First I need a fancy cookhat to wear ;-) -- Javier Llorente
On Wed, 29 Sep 2010 21:59:56 +0200 Jos Poortvliet wrote: Hi,
On Wednesday 29 September 2010 20:27:11 Javier Llorente wrote:
Hello there,
I was thinking that having an openSUSE Handbook (or handbuch ;) in pdf format ready to be downloaded, printed and even ready to be sent to a publishing company is a good idea.
Ambitious, but a good idea. We can do the writing either on the wiki or in piratepads (but piratepad has been acting up lately, I really really hope someone feels like setting up an Etherpad for openSUSE).
I am not convinced. * Javier's idea was to produce documentation in different output formats - at least HTML and PDF. I would like to add ePUB and ASCII. * It was pointed out that there different projects producing and/or reusing openSUSE documentation * There is a need to be able to share the documentation All this does not sound like a wiki or *pad is the tool of choice. Once you choose to use these tools it is pretty hard or even impossible to switch to another tool, to add another output format, to reuse existing files in different documents (having a single source to maintain). I would propose XML hosted on SVN. Although the learning curve would be a bit stepper than with e.g. wiki markup it would give us the maximum flexibilty and a guaranteed future. Whatsmore, the existing documentation (speaking of almost 2000 pages!!) already uses XML. Apart from that, even if XML would be no choice at all, why using another tool apart from our wiki? What's wrong with en.opensuse.org (apart from the search ;-)) ? Plans to host the complete openSUSE documentation in a public SVN at berlios exist for quite some time, the structure is already in place, everything is prepared... .
... and get ppl to write...
That will be the hardest part. How many _regular contributors_ (not speaking of ppl doing administrative tasks) do we have in the wiki? -- Regards Frank Frank Sundermeyer, Technical Writer, Documentation SUSE Linux Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Tel: +49-911-74053-0, Fax: +49-911-7417755; http://www.opensuse.org/ SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) "Reality is always controlled by the people who are most insane" Dogbert -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
On Thursday 30 September 2010 06:52:10 Frank Sundermeyer wrote:
On Wed, 29 Sep 2010 21:59:56 +0200 Jos Poortvliet wrote: ...
... and get ppl to write...
That will be the hardest part. How many _regular contributors_ (not speaking of ppl doing administrative tasks) do we have in the wiki?
http://en.opensuse.org/Special:Statistics Registered users 7,840 Active users in the last 91 days 87 http://en.opensuse.org/index.php?title=Special:ActiveUsers&limit=100 A little play with numbers reveals that: First 10 people make for 67% of activity. First 20 people make for 81% of activity. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
Hello, on Donnerstag, 30. September 2010, Frank Sundermeyer wrote:
On Wed, 29 Sep 2010 21:59:56 +0200 Jos Poortvliet wrote:
[file format of the manual and conversation to XML, PDF, ePub etc.]
All this does not sound like a wiki or *pad is the tool of choice. Once you choose to use these tools it is pretty hard or even impossible to switch to another tool, to add another output format,
I'm not sure about that. I don't say that it will be very easy, but it should be possible, and it won't be too hard. 90% of the formatting can be done with plain wikitext, and for the remaining 10% templates can be used (which can, but don't have to have a visible effect in the wiki). A "visible" template might be something like "text printed on screen", an "invisible" template might contain a keyword for the book index. I think we could even develop a "XML skin" for mediawiki so that the wiki can generate valid docbook/novdoc XML out of wiki pages (with <para> instead of <p> etc.). The alternative solution would be to post-process the wikitext or the HTML to convert it to XML. Basically the two methods don't differ too much, the main difference/question is if you want XML output integrated in the wiki or not.
I would propose XML hosted on SVN. Although the learning curve would be a bit stepper than with e.g. wiki markup it would give us the maximum flexibilty and a guaranteed future.
I'm afraid that the learning curve is too high - lessons for lizards unfortunately gave you/us that lesson... I don't know if the learning curve was the only problem there, but at least it's "I have to learn another thing before I can contribute".
Whatsmore, the existing documentation (speaking of almost 2000 pages!!) already uses XML.
OK, _that_ is an argument. But as you already wrote, it shouldn't be hard to convert it to wikitext. And it would be a good testbed for the wikitext to XML converter - ideally there should be no difference after converting it forth and back again ;-) (and that would make us better than google translator *g*)
Apart from that, even if XML would be no choice at all, why using another tool apart from our wiki? What's wrong with en.opensuse.org
nothing ;-)
Plans to host the complete openSUSE documentation in a public SVN at berlios exist for quite some time, the structure is already in place, everything is prepared... .
Does that mean you can just do a SVN commit and everything is public? If yes, please do it! In case you wonder: this doesn't mean I take back what I said above. I see the public SVN as a fast solution so that people have a chance to dig into the manual's source. It might even be read-only in the beginning - having to upload patches to bugzilla or send them to the -doc mailinglist is still easier than reporting "on page 123 in section 'foo', there's a typo in 'baar'". But even if you give out SVN write access, I'm afraid that not many people will contribute to the XML source because of the learning curve. You have to "switch" from the rendered manual (HTML, PDF, ...) to the XML source, and you have to know at least some XML basics. OTOH the wiki is more like a long(er)-term solution, but makes contribution much easier - just click "Edit". Yes, writing a good wiki-to-XML tool will need some work, but it is possible. And it is worth the effort IMHO. If you are interested, we can discuss this at the conference and maybe work a bit on a sandbox article in the wiki to see if it works as I think. Just drop me a note and propose a meeting time. I'll be there on Thursday, Friday and Saturday. (Offer not limited to Frank - everybody who is interested is welcome at such a meeting.)
... and get ppl to write...
That will be the hardest part. How many _regular contributors_ (not speaking of ppl doing administrative tasks) do we have in the wiki?
You've seen the numbers from Rajko - around 90 active users in the last 3 months. That's still 89 more than in the "lessons for lizards" *g,d&r* Regards, Christian Boltz -- Wo steht der Server eigentlich? Kann den die Putzfrau treten? Oder mal mit dem Staubsauger überfahren? Denen fallen ab und an Gemeinheiten ein auf die ein Normalsterblicher nie kommen würde. :\ [Daniel Lord in suse-linux] -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
Hi, (CC'ed opensuse-doc so doc people can read that too.) On Monday 04 October 2010 Christian Boltz wrote:
[...]
I'm not sure about that. I don't say that it will be very easy, but it should be possible, and it won't be too hard.
You are underestimate the efforts.
90% of the formatting can be done with plain wikitext, and for the remaining 10% templates can be used (which can, but don't have to have a visible effect in the wiki). A "visible" template might be something like "text printed on screen", an "invisible" template might contain a keyword for the book index.
We use a feature in DocBook/Novdoc what is called "profiling". We label one paragraph for business related products and another one for openSUSE products. When we process the manual, the paragraphs are being "filtered" so only the requested product is visible in the end format. Maybe this belongs to the remaining 10%...
I think we could even develop a "XML skin" for mediawiki so that the wiki can generate valid docbook/novdoc XML out of wiki pages (with <para> instead of <p> etc.). The alternative solution would be to post-process the wikitext or the HTML to convert it to XML.
Depending on the HTML this sounds scaring.
Basically the two methods don't differ too much, the main difference/question is if you want XML output integrated in the wiki or not.
I would propose XML hosted on SVN. Although the learning curve would be a bit stepper than with e.g. wiki markup it would give us the maximum flexibilty and a guaranteed future.
I'm afraid that the learning curve is too high - lessons for lizards unfortunately gave you/us that lesson...
Sorry, but I never understood the "XML is too difficult" rant. People are *not* afraid to learn LaTeX or Wiki, dig into HTML, or even migrate from Windows to Linux because of "the learning curve is too high". Why they are not afraid? Because they are _interested_ and want to _learn_ something new. Why should it be difficult to learn DocBook/Novdoc? It's just a format as HTML, WikiText, ASCIIDoc, or anything else. Maybe it's a bit more verbose, but if you can write HTML and design your webpage, you can also write documentation in DocBook or Novdoc. It's just a matter of your XML editor. Of course, Lessons for Lizards was not as successful as we wished it would be. However, it's a bit too easy to blame only XML for the demise. Maybe it had an effect, maybe not. The biggest problem IMHO was time and marketing.
I don't know if the learning curve was the only problem there, but at least it's "I have to learn another thing before I can contribute".
I'm afraid, I have to disagree here. "To learn another thing before I can contribute" is the case for _every_ open source project. If you want to contribute, you usually use what's there. If you are interested enough then you are willing to take that "extra step". If not, you simply don't contribute. Just think of this example: People were not afraid to learn CVS. After some time, it was more or less replaced by Subversion. Although it was not that different, people were willing to learn the differences. Now it seems Git will be the sucessor for Subversion. And *that* is really different from CVS/Subversion! And what's the opinion? "Git is soo coool!" is what can I heare a lot. ;)
Whatsmore, the existing documentation (speaking of almost 2000 pages!!) already uses XML.
OK, _that_ is an argument. But as you already wrote, it shouldn't be hard to convert it to wikitext.
Indeed, there are stylesheets (I've wrote it), but I wouldn't want to transform a complete book. The two systems are too different in some aspects.
And it would be a good testbed for the wikitext to XML converter - ideally there should be no difference after converting it forth and back again ;-) (and that would make us better than google translator *g*)
[...]
Let me suggest another idea: In my opinion, most people have problems with XML because it's (a) too verbose, (b) it's too "complicated", and (c) you don't see the result. At least that's what I hear a lot. As most of the functionality thesedays goes through the Web, why not have a XML editor in, let's say, Firefox? Of course, it should offer the usual features but would hide the XML syntax and display just the rendered text. I know, this is day-dreaming and the idea is not new. However, I think, this would lower the entrance. We could use the existing XML source without converting it to Wiki while embracing Web usability. I think, this should solve the above problems. Maybe we could use Bitflux, see http://bitfluxeditor.org/.
[...] I see the public SVN as a fast solution so that people have a chance to dig into the manual's source. It might even be read-only in the beginning - having to upload patches to bugzilla or send them to the -doc mailinglist is still easier than reporting "on page 123 in section 'foo', there's a typo in 'baar'".
A page number is a bad choice as it can change easily. Better use the section title or an anchor from HTML. :)
But even if you give out SVN write access, I'm afraid that not many people will contribute to the XML source because of the learning curve.
What makes you so sure? To cite Tim Berners-Lee: »If you use the original World Wide Web program, you never see a URL or have to deal with HTML. That was a surprise to me - that people were prepared to painstakingly write HTML.«
You have to "switch" from the rendered manual (HTML, PDF, ...) to the XML source, and you have to know at least some XML basics.
In Wikis you have to know some Wiki basics. What's the point here? :)
OTOH the wiki is more like a long(er)-term solution, but makes contribution much easier - just click "Edit".
Sorry, I'm not convienced. DocBook exists for more than 10 years! It's well- matured, very well documented, and it's one defacto standard for technical documentation. Ok, maybe you can count DITA as well. Although I'm not that much into the Wiki topic, I have the impression the Wiki syntax is not very well "established": One Wiki supports a certain syntax, another don't. If this is really the case, I wouldn't call Wikis "a long-term solution". For easier contribution: See my idea above.
Yes, writing a good wiki-to-XML tool will need some work, but it is possible. And it is worth the effort IMHO.
Why should we write some wiki-to-XML converter when we have already everything in place, ready to be used?
[...]
You've seen the numbers from Rajko - around 90 active users in the last 3 months. That's still 89 more than in the "lessons for lizards" *g,d&r*
You compare apples with oranges. :) -- Gruß/Regards, Thomas Schraitle ---------------------------------------------------------------------- SUSE LINUX Products GmbH (o< Documentation Specialist Maxfeldstrasse 5 /\\ 90409 Nuernberg, Germany _\_v http://en.opensuse.org/Documentation_Team SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
to make it short +1000 for docbook -10000 for wiki syntax, as there's no standard about wikis :-) Really it should be not too hard to find an xml docbook editor, syntax helper, for eclipse, or other ide to help people to write docbook ( which is really easy to learn ) -- Bruno Friedmann (irc:tigerfoot) Ioda-Net Sàrl www.ioda-net.ch openSUSE Member User www.ioda.net/r/osu Blog www.ioda.net/r/blog fsfe fellowship www.fsfe.org GPG KEY : D5C9B751C4653227 vcard : http://it.ioda-net.ch/ioda-net.vcf -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
Hello, on Montag, 4. Oktober 2010, Thomas Schraitle wrote:
On Monday 04 October 2010 Christian Boltz wrote:
[...]
I'm not sure about that. I don't say that it will be very easy, but it should be possible, and it won't be too hard.
You are underestimate the efforts.
We can make a shout match out of this ("No, I don't" ;-) - but I'd prefer to use the time more productive. I still think using the wiki wouldn't be too hard (with some creative template usage), but I also like your idea of using a WYSIWYG XML editor. <written after otherwise completing the mail> After googling around a bit (see linklist at the end of this mail) I still tend to using the wiki because there are some (at least at the first look) working converters available, while using bitflux would maybe cause more work - it looks like the editor is only the frontend, and the server-side handling would need to be written. Another advantage of using the wiki as base would be that we can easily create an "offline copy" of the wiki (for regions without useable internet access) or of a set of pages (for example a build service manual).
90% of the formatting can be done with plain wikitext, and for the remaining 10% templates can be used (which can, but don't have to have a visible effect in the wiki). A "visible" template might be something like "text printed on screen", an "invisible" template might contain a keyword for the book index.
We use a feature in DocBook/Novdoc what is called "profiling". We label one paragraph for business related products and another one for openSUSE products. When we process the manual, the paragraphs are being "filtered" so only the requested product is visible in the end format. Maybe this belongs to the remaining 10%...
That could use something like {{only_openSUSE|paragraph text}} or {{only_SLES|paragraph text}} and the template would just be {{{1}}} to show the text and empty to hide it. Or, to make it a bit more flexible and to allow multiple targets without duplicating the content, something like {{onlyIn|SLES,SLED|text}} could be used in combination with ParserFunctions.
I think we could even develop a "XML skin" for mediawiki so that the wiki can generate valid docbook/novdoc XML out of wiki pages (with <para> instead of <p> etc.). The alternative solution would be to post-process the wikitext or the HTML to convert it to XML.
Depending on the HTML this sounds scaring.
The advantage of the wiki is that it is _generated_ HTML (from wikitext), so it won't be too scary ;-) ...
I'm afraid that the learning curve is too high - lessons for lizards unfortunately gave you/us that lesson...
Sorry, but I never understood the "XML is too difficult" rant. People are *not* afraid to learn LaTeX or Wiki, dig into HTML, or even migrate from Windows to Linux because of "the learning curve is too high". Why they are not afraid? Because they are _interested_ and want to _learn_ something new.
Or because they need it (for private usage or for the job) and _have to_ learn it.
Why should it be difficult to learn DocBook/Novdoc? It's just a format as HTML, WikiText, ASCIIDoc, or anything else. Maybe it's a bit more verbose, but if you can write HTML and design your webpage, you can also write documentation in DocBook or Novdoc. It's just a matter of your XML editor.
I think we should "split" the potential editors in two groups: a) people that want to do large contributions, for example a new chapter about <insert topic here> They will probably have no problem with learning the needed XML, and they'll probably also fit your "want to learn something new". Even if they initially didn't want to learn XML, the effort is small compared to writing all the text, and therefore acceptable. b) people that "just" want to fix a small error or a typo I doubt that they will happily learn XML "just" to fix a typo or mark a link as a link - the effort to result quotient is too bad in this case ;-) For those people, having an "Edit" link in the online version of the manual would be a very big advantage. ...
I don't know if the learning curve was the only problem there, but at least it's "I have to learn another thing before I can contribute".
I'm afraid, I have to disagree here. "To learn another thing before I can contribute" is the case for _every_ open source project. If you want to contribute, you usually use what's there. If you are interested enough then you are willing to take that "extra step". If not, you simply don't contribute.
Thanks for confirming my two groups from above ;-) but I'd prefer not to have that "extra step" so that everybody can contribute.
Just think of this example: People were not afraid to learn CVS. After some time, it was more or less replaced by Subversion. Although it was not that different, people were willing to learn the differences.
I think many users could just do alias cvs=svn and continue as usual ;-) because the features most people use (co, up, diff, commit) are basically the same.
Now it seems Git will be the sucessor for Subversion. And *that* is really different from CVS/Subversion! And what's the opinion? "Git is soo coool!" is what can I heare a lot. ;)
Again, this depends on your usage and needs. I know that Git has lots of features, but IMHO that makes it also complicated when compared to SVN. Personally I'd say I know SVN quite well, but don't really know Git because I didn't really need it until now. The good thing is that at least the checkout/clone is quite easy (and copy&paste-ready available on most project homepages) - without knowing all details of Git, I can still send a patch or post it in the bugtracker. Developers who use Git in their daily work will of course know it better and just ask the upstream developers to pick their changes from their private Git repo. Back to the manual: the question is if we need another tool which every contributor has to learn (XML), or if we can use an existing one (wiki).
Let me suggest another idea: In my opinion, most people have problems with XML because it's (a) too verbose, (b) it's too "complicated", and (c) you don't see the result. At least that's what I hear a lot.
Yes, that sums up the problem quite good.
As most of the functionality thesedays goes through the Web, why not have a XML editor in, let's say, Firefox?
Of course, it should offer the usual features but would hide the XML syntax and display just the rendered text. I know, this is day-dreaming and the idea is not new. However, I think, this would lower the entrance. We could use the existing XML source without converting it to Wiki while embracing Web usability. I think, this should solve the above problems.
Indeed, this sounds like a very good idea. Since we are already dreaming: the HTML version of the manual should have an "[Edit]" link attached to every section ;-) We would also need an easy way to create a new chapter, but that has lower priority because it isn't needed too often compared to fixing errors or adding some details in the existing chapters. If it works as expected, it would be a good solution that would make contribution easy (that's the main problem with the current manuals).
Maybe we could use Bitflux, see http://bitfluxeditor.org/.
The description on the homepage looks promising. Unfortunately the demo seems to be broken (lots of "not found" errors for the JS files)...
[...] I see the public SVN as a fast solution so that people have a chance to dig into the manual's source. It might even be read-only in the beginning - having to upload patches to bugzilla or send them to the -doc mailinglist is still easier than reporting "on page 123 in section 'foo', there's a typo in 'baar'".
A page number is a bad choice as it can change easily. Better use the section title or an anchor from HTML. :)
I was more thinking of PDF or printed manuals in this case ;-) BTW: I think Jana Jaeger can tell you a story about printed manuals and paperclips. hint: bug 65000 *g*
You have to "switch" from the rendered manual (HTML, PDF, ...) to the XML source, and you have to know at least some XML basics.
In Wikis you have to know some Wiki basics. What's the point here? :)
I see several points: - the wiki has a "preview" button where you can see your changes. That's not WYSIWYG, but not too far away - lots of people know wiki basics (think of all the people that write in wikipedia) - and even if you don't know wiki syntax, I'd say it is very easy to understand - for example, a paragraph is just, well, a paragraph. More important (and missed in your question) is the "switch" from the rendered manual to XML source. Finding the correct place to edit in the XML can be more difficult than doing the actual text change. That's where the wiki is really good with an "[Edit]" link at every section.
OTOH the wiki is more like a long(er)-term solution, but makes contribution much easier - just click "Edit". ... Although I'm not that much into the Wiki topic, I have the impression the Wiki syntax is not very well "established": One Wiki supports a certain syntax, another don't. If this is really the case, I wouldn't call Wikis "a long-term solution".
Yes, there is indeed some wiki software with slightly different syntax. I don't really see a problem in that because the software we use (Mediawiki) has a well-defined syntax and is broadly used (wikipedia). BTW: HTML and CSS have a similar "problem" - some browsers understand additional tags or even misinterpret some tags. Does this mean nobody uses HTML? ;-)
For easier contribution: See my idea above.
Indeed, an online editor for the manual would be a very good idea. The main reasons why I proposed using the wiki are: - the "[Edit]" link - that makes finding the correct place for an edit easy (no need for grep, searching in the file etc.) - already well-known or at least very easy to learn syntax - result visible instantly When I wrote my proposal, I wasn't aware of Bitflux, and therefore the wiki was the tool that fulfilled the above requirements best. If Bitflux can do all that and additionally keep the XML format, then it might even be better than using the wiki.
Yes, writing a good wiki-to-XML tool will need some work, but it is possible. And it is worth the effort IMHO.
Why should we write some wiki-to-XML converter when we have already everything in place, ready to be used?
To make it easier for contributors. But see above... Let me paste some links that might be useful for the discussion and/or technical implementation. Note that I just had a quick look at the following pages. https://wiki.ubuntu.com/DocBookWeb and http://fedoraproject.org/wiki/Converting_wiki_to_DocBook_XML overview on several tools for wiki -> docbook (seems openSUSE is not the only project that has a need for this) http://code.google.com/p/gwtwiki/wiki/Mediawiki2Docbook looks like working code, page mentions "partial working", so the converter might need finetuning http://www.mediawiki.org/wiki/Extension:XML_Bridge http://www.mediawiki.org/wiki/Extension:Collection Mediawiki extensions for docbook export http://toolserver.org/~magnus/wiki2xml/w2x.php online converter for wikitext -> docbook (and other formats), source available http://doc-book.sourceforge.net/homepage/ a wiki working with docbook format internally http://www.tldp.org/wt2db/ command-line wikitext -> docbook converter And now to the fun part:
You compare apples with oranges. :)
Why not? Both are round, and you can eat both of them ;-)) Regards, Christian Boltz -- Lies halt mal dclp.*, da faellt dir nix mehr ein. Wenn man ein Guerteltier ueber die Tastatur abrollt, kommt besserer PHP Code raus als da gepostet wird. [R. Huebenthal in darw] -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
On Wednesday 06 October 2010 01:26:44 Christian Boltz wrote: Hi, > I still think using the wiki wouldn't be too hard (with some creative > template usage), but I also like your idea of using a WYSIWYG XML > editor. Frank said in another mail in this thread that it does not make sense to maintain documentation in more than one source. I completely agree on this. But IMO that also means that the Wiki is the only source we can use for that. The reasons are - Wiki gets most contributions and as a result has the most documentation - Wiki is most recent - Wiki is state of the (community) art. These are facts we can not ignore, and the Lesson for Lizards proves that. However Franks concerns against Wiki are very valid, especially when it comes to structure. In the new wiki we have structure, which is great, but I agree to Frank that this wont be enough for a book. But why not use both: Wiki as a source for content and the susedoc system to create a book? I see that this sounds like a scary idea, but why not brainstorm about a "book description file" which defines a structure for the book, names the source pages in the wiki, possibly patches to apply to the downloaded wiki page content, and finally generate XML that is the source of the book? So we would get the benefit out of the quickly moving wiki content for the book. I know, that sounds very uncooked, it is of course, but still a neat idea, or not? Generally I am wondering why we discuss so much about technology here. Isn't it great in general if people stand up and want to contribute content, which is the most important for documentation I think? So the format in which the (good) content is delivered does not really matter as long as the quality is high. Converting something to the right format shouldn't be the main effort, right? So shouldn't be the discussion "What is good documentation?" stand in front? > I think we should "split" the potential editors in two groups: > > a) people that want to do large contributions, for example a new > chapter about> > They will probably have no problem with learning the needed XML, and > they'll probably also fit your "want to learn something new". > Even if they initially didn't want to learn XML, the effort is small > compared to writing all the text, and therefore acceptable. > > b) people that "just" want to fix a small error or a typo > > I doubt that they will happily learn XML "just" to fix a typo or mark > a link as a link - the effort to result quotient is too bad in this > case ;-) > For those people, having an "Edit" link in the online version of the > manual would be a very big advantage. Couldn't we find people for these two groups instead: - Editors: People who work on content and deliver in which format they ever want (nearly ;-) to - Book Builders: People who get the content from the Editors and work on building a book with the best suited tool for that? Maybe it makes more sense to devide the "good-writer-skill" from the "I-like- to-fiddle-with-tools-which-produce-great-outcome" role? regards, Klaas > -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
Just as a proof-of-concept for document writing community success, see http://flossmanuals.net - easy to use, produces nice output, has a great community of contributors. In terms of wiki-to-book, Wikipedia has had that for some time, and there are some nice examples out there: http://en.wikipedia.org/wiki/Help:Books I'm sure there is a way to build on that model for openSUSE. I have both the "good-writer-skill" and "I-like-to-fiddle-with-tools-which-produce-great-outcome", as Klaas puts it. But I also have to recognize which one of these others are as well, as a project manager or in a community leader roll. It's the users that should define what is pursued here, I believe. I think the wiki-to-book functionality should definitely be added to the openSUSE wiki as an option, and if it matured to a point where all the other features discussed in this thread could be produced, then all the better. For now, I am still using Emacs to edit my openSUSE documents - but the older I get, the simpler I like things to be :) I wouldn't turn away from a nice wiki that would squirt out a publish-ready document! Cheers, Christian Bryant
Couldn't we find people for these two groups instead: - Editors: People who work on content and deliver in which format they ever want (nearly ;-) to - Book Builders: People who get the content from the Editors and work on building a book with the best suited tool for that? Maybe it makes more sense to devide the "good-writer-skill" from the "I-like- to-fiddle-with-tools-which-produce-great-outcome" role?
regards,
Klaas
IMPORTANT WARNING: This email (and any attachments) is only intended for the use of the person or entity to which it is addressed, and may contain information that is privileged and confidential. You, the recipient, are obligated to maintain it in a safe, secure and confidential manner. Unauthorized redisclosure or failure to maintain confidentiality may subject you to federal and state penalties. If you are not the intended recipient, please immediately notify us by return email, and delete this message from your computer. -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
On Wed, 2010-09-29 at 21:59 +0200, Jos Poortvliet wrote:
Ambitious, but a good idea. We can do the writing either on the wiki or in piratepads (but piratepad has been acting up lately, I really really hope someone feels like setting up an Etherpad for openSUSE)
So, have you made a proposal during the openSUSE Project meeting or submitted it to openFATE? Those are the ways to go for submitting and getting it through. I would recommend it be hosted either on openSUSE's infrastructure or on openSUSE-Community.org's infrastructure. Not by someone volunteering to host it themselves cuz that just adds more complexity and maintenance issues. Bryen M Yunashko -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
This is a sensationally good idea. Piratepad is driving me nuts atm.
Also for international users, downtimes are often exactly when they
are trying to work (early am in host country).
I also have some reservations about not being able to delete the
material on these pads, and having never seen a user agreement etc....
it would be nice to have a more secure space to work.
It's a lovely simple tool to use so having it hosted by Novell or
similar would be wonderful.
cheers
Helen
On Thu, Sep 30, 2010 at 9:57 PM, Bryen Yunashko
So, have you made a proposal during the openSUSE Project meeting or submitted it to openFATE? Those are the ways to go for submitting and getting it through. -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
VGhlIGRvd250aW1lcyBhcmUgcHJlY2lzZWx5IHdoeSBJJ3ZlIGZhbGxlbiBzbyBmYXIgYmVoaW5kIHRoYXQgSSd2ZSBnaXZlbiB1cCAgDQoNCkJyeWVuDQoNClNlbnQgZnJvbSBteSBWZXJpem9uIFdpcmVsZXNzIEJsYWNrQmVycnkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEhlbGVuIDxwb3N0bW9kZXJuaG91c2V3aWZlQGdtYWlsLmNvbT4NCkRhdGU6IFRodSwgMzAgU2VwIDIwMTAgMDg6NDM6NTYgDQpUbzogPG9wZW5zdXNlLW1hcmtldGluZ0BvcGVuc3VzZS5vcmc+DQpTdWJqZWN0OiBSZTogRXRoZXJwYWQ6IFdhcyBbb3BlbnN1c2UtbWFya2V0aW5nXSBUaGUgb3BlblNVU0UgSGFuZGJvb2sgcHJvcG9zYWwNCg0KVGhpcyBpcyBhIHNlbnNhdGlvbmFsbHkgZ29vZCBpZGVhLiBQaXJhdGVwYWQgaXMgZHJpdmluZyBtZSBudXRzIGF0bS4NCkFsc28gZm9yIGludGVybmF0aW9uYWwgdXNlcnMsICBkb3dudGltZXMgYXJlIG9mdGVuIGV4YWN0bHkgd2hlbiB0aGV5DQphcmUgdHJ5aW5nIHRvIHdvcmsgKGVhcmx5IGFtIGluIGhvc3QgY291bnRyeSkuDQoNCkkgYWxzbyBoYXZlIHNvbWUgcmVzZXJ2YXRpb25zIGFib3V0IG5vdCBiZWluZyBhYmxlIHRvIGRlbGV0ZSB0aGUNCm1hdGVyaWFsIG9uIHRoZXNlIHBhZHMsIGFuZCBoYXZpbmcgbmV2ZXIgc2VlbiBhIHVzZXIgYWdyZWVtZW50IGV0Yy4uLi4NCml0IHdvdWxkIGJlIG5pY2UgdG8gaGF2ZSBhIG1vcmUgc2VjdXJlIHNwYWNlIHRvIHdvcmsuDQoNCkl0J3MgYSBsb3ZlbHkgc2ltcGxlIHRvb2wgdG8gdXNlIHNvIGhhdmluZyBpdCBob3N0ZWQgYnkgTm92ZWxsIG9yDQpzaW1pbGFyIHdvdWxkIGJlIHdvbmRlcmZ1bC4NCg0KY2hlZXJzDQpIZWxlbg0KDQpPbiBUaHUsIFNlcCAzMCwgMjAxMCBhdCA5OjU3IFBNLCBCcnllbiBZdW5hc2hrbyA8c3VzZXJvY2tzQGJyeWVuLmNvbT4gd3JvdGU6DQoNCj4gU28sIGhhdmUgeW91IG1hZGUgYSBwcm9wb3NhbCBkdXJpbmcgdGhlIG9wZW5TVVNFIFByb2plY3QgbWVldGluZyBvcg0KPiBzdWJtaXR0ZWQgaXQgdG8gb3BlbkZBVEU/IKBUaG9zZSBhcmUgdGhlIHdheXMgdG8gZ28gZm9yIHN1Ym1pdHRpbmcgYW5kDQo+IGdldHRpbmcgaXQgdGhyb3VnaC4NCi0tDQpUbyB1bnN1YnNjcmliZSwgZS1tYWlsOiBvcGVuc3VzZS1tYXJrZXRpbmcrdW5zdWJzY3JpYmVAb3BlbnN1c2Uub3JnDQpGb3IgYWRkaXRpb25hbCBjb21tYW5kcywgZS1tYWlsOiBvcGVuc3VzZS1tYXJrZXRpbmcraGVscEBvcGVuc3VzZS5vcmcNCg0K-- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.orgFor additional commands, e-mail: opensuse-marketing+help@opensuse.org
On Thursday 30 September 2010 13:57:23 Bryen Yunashko wrote:
On Wed, 2010-09-29 at 21:59 +0200, Jos Poortvliet wrote:
Ambitious, but a good idea. We can do the writing either on the wiki or in piratepads (but piratepad has been acting up lately, I really really hope someone feels like setting up an Etherpad for openSUSE)
So, have you made a proposal during the openSUSE Project meeting or submitted it to openFATE? Those are the ways to go for submitting and getting it through.
I would recommend it be hosted either on openSUSE's infrastructure or on openSUSE-Community.org's infrastructure. Not by someone volunteering to host it themselves cuz that just adds more complexity and maintenance issues.
Bryen M Yunashko
You're right. I'll get it in openFATE and see if I can give it a bit more publicity too. Tnx!
On Jueves, 30 de Septiembre de 2010 13:57:23 Bryen Yunashko escribió:
On Wed, 2010-09-29 at 21:59 +0200, Jos Poortvliet wrote:
Ambitious, but a good idea. We can do the writing either on the wiki or in piratepads (but piratepad has been acting up lately, I really really hope someone feels like setting up an Etherpad for openSUSE)
So, have you made a proposal during the openSUSE Project meeting or submitted it to openFATE? Those are the ways to go for submitting and getting it through.
Not yet.
I would recommend it be hosted either on openSUSE's infrastructure or on openSUSE-Community.org's infrastructure. Not by someone volunteering to host it themselves cuz that just adds more complexity and maintenance issues.
Sure. My idea is to host it on openSUSE's infrastructure. Greetings, -- Javier Llorente
On Thursday 30 September 2010 01:20:30 Javier Llorente wrote:
On Jueves, 30 de Septiembre de 2010 13:57:23 Bryen Yunashko escribió:
On Wed, 2010-09-29 at 21:59 +0200, Jos Poortvliet wrote:
Ambitious, but a good idea. We can do the writing either on the wiki or in piratepads (but piratepad has been acting up lately, I really really hope someone feels like setting up an Etherpad for openSUSE)
So, have you made a proposal during the openSUSE Project meeting or submitted it to openFATE? Those are the ways to go for submitting and getting it through.
Not yet.
I would recommend it be hosted either on openSUSE's infrastructure or on openSUSE-Community.org's infrastructure. Not by someone volunteering to host it themselves cuz that just adds more complexity and maintenance issues.
Sure. My idea is to host it on openSUSE's infrastructure.
Sorry, Javier, this was about Etherpad, not the documentation :D
Greetings,
On Thursday 30 September 2010 13:57:23 Bryen Yunashko wrote:
On Wed, 2010-09-29 at 21:59 +0200, Jos Poortvliet wrote:
Ambitious, but a good idea. We can do the writing either on the wiki or in piratepads (but piratepad has been acting up lately, I really really hope someone feels like setting up an Etherpad for openSUSE)
So, have you made a proposal during the openSUSE Project meeting or submitted it to openFATE? Those are the ways to go for submitting and getting it through.
I would recommend it be hosted either on openSUSE's infrastructure or on openSUSE-Community.org's infrastructure. Not by someone volunteering to host it themselves cuz that just adds more complexity and maintenance issues.
Bryen M Yunashko
On Wed, Sep 29, 2010 at 8:27 PM, Javier Llorente
Hello there,
I was thinking that having an openSUSE Handbook (or handbuch ;) in pdf format ready to be downloaded, printed and even ready to be sent to a publishing company is a good idea.
So, here's my proposal:
First, we would have to make a list of topics to be included and organise them in chapters, like the following draft:
****************************** The openSUSE Handbook ****************************** Introduction - What's the openSUSE project? - What's openSUSE?
Installing openSUSE - Different types of install methods - AutoYaST
Installing applications - Using 1-click - Using YaST - Using zypper
Desktop environments - An introduction to DEs (KDE, GNOME, XFCE, LXDE). - Enabling proprietary drivers (ATI, NVIDIA) - Multimedia - Printing - Games
System administration - Introduction to the command line - Networking - Security - Storage - Virtualization - Keeping openSUSE up-to-date - Upgrading openSUSE
Servers - Apache and lighttpd - MySQL and PostgreSQL - Postfix - BIND - Samba - CUPS etc
Other openSUSE Technologies - Build Service - SUSE Studio - KIWI
Second, we would have to write about those topics not included in the wiki and review those already written. That way we would have more relevant bits in both the wiki and handbook. Each topic doesn't have to be 100 page long ;-)
And last but not least we would have to put all the pieces together and make it available in pdf.
Drawbacks: We would need to update some of its contents for each openSUSE release. It needs more than two people to make it happen ;-)
On the other hand, I think that the handbook would make openSUSE more "visible" and a bit more "ready to use."
Comments and suggestions are welcome! :-)
Hi, What do you intend to do differently from the official PDF doc? Maybe there is an opportunity to build something on the Lesson for Lizards foundation here? See http://en.opensuse.org/Portal:Documentation and http://developer.novell.com/wiki/index.php/Lessons_for_Lizards Regards, R. -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
On Wed, Sep 29, 2010 at 5:29 PM, Rémy Marquis
On Wed, Sep 29, 2010 at 8:27 PM, Javier Llorente
wrote: Hello there,
I was thinking that having an openSUSE Handbook (or handbuch ;) in pdf format ready to be downloaded, printed and even ready to be sent to a publishing company is a good idea.
So, here's my proposal:
First, we would have to make a list of topics to be included and organise them in chapters, like the following draft:
****************************** The openSUSE Handbook ****************************** Introduction - What's the openSUSE project? - What's openSUSE?
Installing openSUSE - Different types of install methods - AutoYaST
Installing applications - Using 1-click - Using YaST - Using zypper
Desktop environments - An introduction to DEs (KDE, GNOME, XFCE, LXDE). - Enabling proprietary drivers (ATI, NVIDIA) - Multimedia - Printing - Games
System administration - Introduction to the command line - Networking - Security - Storage - Virtualization - Keeping openSUSE up-to-date - Upgrading openSUSE
Servers - Apache and lighttpd - MySQL and PostgreSQL - Postfix - BIND - Samba - CUPS etc
Other openSUSE Technologies - Build Service - SUSE Studio - KIWI
Second, we would have to write about those topics not included in the wiki and review those already written. That way we would have more relevant bits in both the wiki and handbook. Each topic doesn't have to be 100 page long ;-)
And last but not least we would have to put all the pieces together and make it available in pdf.
Drawbacks: We would need to update some of its contents for each openSUSE release. It needs more than two people to make it happen ;-)
On the other hand, I think that the handbook would make openSUSE more "visible" and a bit more "ready to use."
Comments and suggestions are welcome! :-)
Hi,
What do you intend to do differently from the official PDF doc? Maybe there is an opportunity to build something on the Lesson for Lizards foundation here?
See http://en.opensuse.org/Portal:Documentation and http://developer.novell.com/wiki/index.php/Lessons_for_Lizards
Regards,
R. -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
I think it would be great to do the how-to's, maybe some tips-n-tricks. This would be helpful for all users. Maybe make it like one of those Bible OS books that get publish. -- ----------------------------------------- Discover it! Enjoy it! Share it! openSUSE Linux. ----------------------------------------- openSUSE -- en.opensuse.org/User:Terrorpup openSUSE Ambassador/openSUSE Member skype,twiiter,identica,friendfeed -- terrorpup freenode(irc) --terrorpup/lupinstein Have you tried SUSE Studio? Need to create a Live CD, an app you want to package and distribute , or create your own linux distro. Give SUSE Studio a try. www.susestudio.com. -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
I like the idea of a 'go to' book but understood that this was the function of the wiki. Do I have the wrong impression? Duplicaton of effort is a bad idea, but I do like having the 'best and most current' readily available. A related issue is navigation and SEO of existing material. For instance, a search for 'install nvidia drivers opensuse' and this page is first http://www.suse.de/~sndirsch/nvidia-installer-HOWTO.html#1 or by clicking through the portal I find this http://en.opensuse.org/SDB:NVIDIA_drivers (nice 'one click' for newbies) which page do we want new users to land on? Having another book is no good if a user doesn't think to read it, or doesn't find it when they google a question. cheers Helen
What do you intend to do differently from the official PDF doc? Maybe there is an opportunity to build something on the Lesson for Lizards foundation here?
See http://en.opensuse.org/Portal:Documentation and http://developer.novell.com/wiki/index.php/Lessons_for_Lizards
-- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
On Miércoles, 29 de Septiembre de 2010 23:57:52 Helen escribió:
I like the idea of a 'go to' book but understood that this was the function of the wiki. Do I have the wrong impression?
Duplicaton of effort is a bad idea, but I do like having the 'best and most current' readily available.
Right. My idea is to use the wiki to put everything and from time to time release a new handbook in different formats and even publish it as a printed book so that it reaches more people. Cheers, -- Javier Llorente
On Thu, 30 Sep 2010 07:57:52 +1000 Helen wrote: Hi,
I like the idea of a 'go to' book but understood that this was the function of the wiki. Do I have the wrong impression?
Duplicaton of effort is a bad idea, but I do like having the 'best and most current' readily available.
A related issue is navigation and SEO of existing material. For instance, a search for 'install nvidia drivers opensuse' and this page is first
http://www.suse.de/~sndirsch/nvidia-installer-HOWTO.html#1
or by clicking through the portal I find this
http://en.opensuse.org/SDB:NVIDIA_drivers (nice 'one click' for newbies)
which page do we want new users to land on?
Having another book is no good if a user doesn't think to read it, or doesn't find it when they google a question.
good points. It's not only about not finding it, it's also about finding several different writings on one topic from one source (openSUSE). The same topic (NVIDIA) is also extensively covered on the forums with a HowTo. Whatsmore at least three different openSUSE people are maintaining documents about the same topic. What a waste of resources. So IMHO centralising is the way to go instead of forking. If every writing has a single source, it doesn't matter if there are several hits in Google, since they all will say the same. If every document has a single source, ppl can work _together_ on this document to make it the one HowTo for openSUSE that answers all questions. -- Regards Frank Frank Sundermeyer, Technical Writer, Documentation SUSE Linux Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Tel: +49-911-74053-0, Fax: +49-911-7417755; http://www.opensuse.org/ SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) "Reality is always controlled by the people who are most insane" Dogbert -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
On Wed, 2010-09-29 at 17:34 -0400, Chuck Payne wrote:
On Wed, Sep 29, 2010 at 5:29 PM, Rémy Marquis
wrote: On Wed, Sep 29, 2010 at 8:27 PM, Javier Llorente
wrote: Hello there,
I was thinking that having an openSUSE Handbook (or handbuch ;) in pdf format ready to be downloaded, printed and even ready to be sent to a publishing company is a good idea.
So, here's my proposal:
First, we would have to make a list of topics to be included and organise them in chapters, like the following draft:
****************************** The openSUSE Handbook ****************************** Introduction - What's the openSUSE project? - What's openSUSE?
Installing openSUSE - Different types of install methods - AutoYaST
Installing applications - Using 1-click - Using YaST - Using zypper
Desktop environments - An introduction to DEs (KDE, GNOME, XFCE, LXDE). - Enabling proprietary drivers (ATI, NVIDIA) - Multimedia - Printing - Games
System administration - Introduction to the command line - Networking - Security - Storage - Virtualization - Keeping openSUSE up-to-date - Upgrading openSUSE
Servers - Apache and lighttpd - MySQL and PostgreSQL - Postfix - BIND - Samba - CUPS etc
Other openSUSE Technologies - Build Service - SUSE Studio - KIWI
Second, we would have to write about those topics not included in the wiki and review those already written. That way we would have more relevant bits in both the wiki and handbook. Each topic doesn't have to be 100 page long ;-)
And last but not least we would have to put all the pieces together and make it available in pdf.
Drawbacks: We would need to update some of its contents for each openSUSE release. It needs more than two people to make it happen ;-)
On the other hand, I think that the handbook would make openSUSE more "visible" and a bit more "ready to use."
Comments and suggestions are welcome! :-)
Hi,
What do you intend to do differently from the official PDF doc? Maybe there is an opportunity to build something on the Lesson for Lizards foundation here?
See http://en.opensuse.org/Portal:Documentation and http://developer.novell.com/wiki/index.php/Lessons_for_Lizards
Regards,
R. -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
I think it would be great to do the how-to's, maybe some tips-n-tricks. This would be helpful for all users. Maybe make it like one of those Bible OS books that get publish.
-- ----------------------------------------- Discover it! Enjoy it! Share it! openSUSE Linux. ----------------------------------------- openSUSE -- en.opensuse.org/User:Terrorpup openSUSE Ambassador/openSUSE Member skype,twiiter,identica,friendfeed -- terrorpup freenode(irc) --terrorpup/lupinstein
Have you tried SUSE Studio? Need to create a Live CD, an app you want to package and distribute , or create your own linux distro. Give SUSE Studio a try. www.susestudio.com.
I'd like to recommend that we also consider making this available on ebooks such as Kindle or Nook. I recently got my Kindle and I'm really enjoying the ability to quickly get my books and have it ready at all times. It will also make for turning the Kindle into a nice reference tool for users that can easily carry around the Kindle than a book and even make their own notations into the book when they're going around giving support, etc. We can offer it as a free book or charge a small publishing fee through Amazon and funnel a few bucks into the future openSUSE Foundation. The potential opportunities abound here! Bryen -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
On Jueves, 30 de Septiembre de 2010 14:01:14 Bryen Yunashko escribió:
On Wed, 2010-09-29 at 17:34 -0400, Chuck Payne wrote:
On Wed, Sep 29, 2010 at 5:29 PM, Rémy Marquis
wrote: On Wed, Sep 29, 2010 at 8:27 PM, Javier Llorente
wrote: Hello there,
I was thinking that having an openSUSE Handbook (or handbuch ;) in pdf format ready to be downloaded, printed and even ready to be sent to a publishing company is a good idea.
So, here's my proposal:
First, we would have to make a list of topics to be included and organise them in chapters, like the following draft:
****************************** The openSUSE Handbook ****************************** Introduction - What's the openSUSE project? - What's openSUSE?
Installing openSUSE - Different types of install methods - AutoYaST
Installing applications - Using 1-click - Using YaST - Using zypper
Desktop environments - An introduction to DEs (KDE, GNOME, XFCE, LXDE). - Enabling proprietary drivers (ATI, NVIDIA) - Multimedia - Printing - Games
System administration - Introduction to the command line - Networking - Security - Storage - Virtualization - Keeping openSUSE up-to-date - Upgrading openSUSE
Servers - Apache and lighttpd - MySQL and PostgreSQL - Postfix - BIND - Samba - CUPS etc
Other openSUSE Technologies - Build Service - SUSE Studio - KIWI
Second, we would have to write about those topics not included in the wiki and review those already written. That way we would have more relevant bits in both the wiki and handbook. Each topic doesn't have to be 100 page long ;-)
And last but not least we would have to put all the pieces together and make it available in pdf.
Drawbacks: We would need to update some of its contents for each openSUSE release. It needs more than two people to make it happen ;-)
On the other hand, I think that the handbook would make openSUSE more "visible" and a bit more "ready to use."
Comments and suggestions are welcome! :-)
Hi,
What do you intend to do differently from the official PDF doc? Maybe there is an opportunity to build something on the Lesson for Lizards foundation here?
See http://en.opensuse.org/Portal:Documentation and http://developer.novell.com/wiki/index.php/Lessons_for_Lizards
Regards,
R. -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
I think it would be great to do the how-to's, maybe some tips-n-tricks. This would be helpful for all users. Maybe make it like one of those Bible OS books that get publish.
I'd like to recommend that we also consider making this available on ebooks such as Kindle or Nook. I recently got my Kindle and I'm really enjoying the ability to quickly get my books and have it ready at all times.
It will also make for turning the Kindle into a nice reference tool for users that can easily carry around the Kindle than a book and even make their own notations into the book when they're going around giving support, etc.
We can offer it as a free book or charge a small publishing fee through Amazon and funnel a few bucks into the future openSUSE Foundation.
+1
The potential opportunities abound here!
Reaching more people through other formats like ebooks. Exactly what I want to do. Cheers, -- Javier Llorente
On Thu, 2010-09-30 at 14:01 +0200, Bryen Yunashko wrote:
On Wed, 2010-09-29 at 17:34 -0400, Chuck Payne wrote:
On Wed, Sep 29, 2010 at 5:29 PM, Rémy Marquis
wrote: On Wed, Sep 29, 2010 at 8:27 PM, Javier Llorente
wrote: Hello there,
I was thinking that having an openSUSE Handbook (or handbuch ;) in pdf format ready to be downloaded, printed and even ready to be sent to a publishing company is a good idea.
So, here's my proposal:
First, we would have to make a list of topics to be included and organise them in chapters, like the following draft:
****************************** The openSUSE Handbook ****************************** Introduction - What's the openSUSE project? - What's openSUSE?
Installing openSUSE - Different types of install methods - AutoYaST
Installing applications - Using 1-click - Using YaST - Using zypper
Desktop environments - An introduction to DEs (KDE, GNOME, XFCE, LXDE). - Enabling proprietary drivers (ATI, NVIDIA) - Multimedia - Printing - Games
System administration - Introduction to the command line - Networking - Security - Storage - Virtualization - Keeping openSUSE up-to-date - Upgrading openSUSE
Servers - Apache and lighttpd - MySQL and PostgreSQL - Postfix - BIND - Samba - CUPS etc
Other openSUSE Technologies - Build Service - SUSE Studio - KIWI
Second, we would have to write about those topics not included in the wiki and review those already written. That way we would have more relevant bits in both the wiki and handbook. Each topic doesn't have to be 100 page long ;-)
And last but not least we would have to put all the pieces together and make it available in pdf.
Drawbacks: We would need to update some of its contents for each openSUSE release. It needs more than two people to make it happen ;-)
On the other hand, I think that the handbook would make openSUSE more "visible" and a bit more "ready to use."
Comments and suggestions are welcome! :-)
Hi,
What do you intend to do differently from the official PDF doc? Maybe there is an opportunity to build something on the Lesson for Lizards foundation here?
See http://en.opensuse.org/Portal:Documentation and http://developer.novell.com/wiki/index.php/Lessons_for_Lizards
Regards,
R. -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
I think it would be great to do the how-to's, maybe some tips-n-tricks. This would be helpful for all users. Maybe make it like one of those Bible OS books that get publish.
-- ----------------------------------------- Discover it! Enjoy it! Share it! openSUSE Linux. ----------------------------------------- openSUSE -- en.opensuse.org/User:Terrorpup openSUSE Ambassador/openSUSE Member skype,twiiter,identica,friendfeed -- terrorpup freenode(irc) --terrorpup/lupinstein
Have you tried SUSE Studio? Need to create a Live CD, an app you want to package and distribute , or create your own linux distro. Give SUSE Studio a try. www.susestudio.com.
I'd like to recommend that we also consider making this available on ebooks such as Kindle or Nook. I recently got my Kindle and I'm really enjoying the ability to quickly get my books and have it ready at all times.
It will also make for turning the Kindle into a nice reference tool for users that can easily carry around the Kindle than a book and even make their own notations into the book when they're going around giving support, etc.
We can offer it as a free book or charge a small publishing fee through Amazon and funnel a few bucks into the future openSUSE Foundation.
The potential opportunities abound here!
Bryen
P.S. When I say Kindle or Nook, I mean in their book formats, not sending to it as a PDF. For two reasons 1) PDF documents incur a charge to the user and 2) PDF formatting on Kindle REAAAAAALLLY sucks and is not very accessible for low-vison users. So we would do a disservice not publishing in native format that allows all users to be able to read it. -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
How hard is it to convert to multiple e-reader formats including PDF? E-readers have not yet taken off in Australia and I wouldn't buy a Kindle anyway. (It's only a matter of time before Amazon starts sticking advertising at random through your books.) Other handheld devices - 7 inch tablet/pads, Nintendo DSI XL..... Helen
We can offer it as a free book or charge a small publishing fee through Amazon and funnel a few bucks into the future openSUSE Foundation.
The potential opportunities abound here!
Bryen
P.S. When I say Kindle or Nook, I mean in their book formats, not sending to it as a PDF. For two reasons 1) PDF documents incur a charge to the user and 2) PDF formatting on Kindle REAAAAAALLLY sucks and is not very accessible for low-vison users. So we would do a disservice not publishing in native format that allows all users to be able to read it.
-- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
On Thursday 30 September 2010 00:26:09 Helen wrote:
How hard is it to convert to multiple e-reader formats including PDF?
That is actually a pretty good point. If our Wiki is good enough in terms of content, we can try and figure out how to automate creating a book. Well, fully automatic would probably be hard - a book would need a bit of layouting. But having all the content on the wiki, then using it for a complementary book - I think that's the way to go.
E-readers have not yet taken off in Australia and I wouldn't buy a Kindle anyway. (It's only a matter of time before Amazon starts sticking advertising at random through your books.)
Other handheld devices - 7 inch tablet/pads, Nintendo DSI XL.....
Helen
We can offer it as a free book or charge a small publishing fee through Amazon and funnel a few bucks into the future openSUSE Foundation.
The potential opportunities abound here!
Bryen
P.S. When I say Kindle or Nook, I mean in their book formats, not sending to it as a PDF. For two reasons 1) PDF documents incur a charge to the user and 2) PDF formatting on Kindle REAAAAAALLLY sucks and is not very accessible for low-vison users. So we would do a disservice not publishing in native format that allows all users to be able to read it.
On Jueves, 30 de Septiembre de 2010 00:54:30 Jos Poortvliet escribió:
On Thursday 30 September 2010 00:26:09 Helen wrote:
How hard is it to convert to multiple e-reader formats including PDF?
That is actually a pretty good point. If our Wiki is good enough in terms of content, we can try and figure out how to automate creating a book. Well, fully automatic would probably be hard - a book would need a bit of layouting. But having all the content on the wiki, then using it for a complementary book - I think that's the way to go.
Yepp. We have to think about the technical details. I know that there are some wiki to pdf converters like: http://www.mediawiki.org/wiki/Extension:Pdf_Export http://www.mediawiki.org/wiki/Extension:Pdf_Book http://www.mediawiki.org/wiki/Extension:Collection The last one can export to other formats as well. Cheers, -- Javier Llorente
On Thu, 30 Sep 2010 00:54:30 +0200 Jos Poortvliet wrote: Hi,
On Thursday 30 September 2010 00:26:09 Helen wrote:
How hard is it to convert to multiple e-reader formats including PDF?
That is actually a pretty good point. If our Wiki is good enough in terms of content, we can try and figure out how to automate creating a book. Well, fully automatic would probably be hard - a book would need a bit of layouting. But having all the content on the wiki, then using it for a complementary book - I think that's the way to go.
I completely disagree. You are proposing to create documentation in a completely unstructured format and then writing parsers attempting to create an exchangeable format. It is re-inventing the wheel by starting with a rectangle. We already have all the style-sheets for XML to provide the formats we need (including wiki text). -- Regards Frank Frank Sundermeyer, Technical Writer, Documentation SUSE Linux Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Tel: +49-911-74053-0, Fax: +49-911-7417755; http://www.opensuse.org/ SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) "Reality is always controlled by the people who are most insane" Dogbert -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
On Thu, 2010-09-30 at 14:34 +0200, Frank Sundermeyer wrote:
On Thu, 30 Sep 2010 00:54:30 +0200 Jos Poortvliet wrote:
Hi,
On Thursday 30 September 2010 00:26:09 Helen wrote:
How hard is it to convert to multiple e-reader formats including PDF?
That is actually a pretty good point. If our Wiki is good enough in terms of content, we can try and figure out how to automate creating a book. Well, fully automatic would probably be hard - a book would need a bit of layouting. But having all the content on the wiki, then using it for a complementary book - I think that's the way to go.
I completely disagree. You are proposing to create documentation in a completely unstructured format and then writing parsers attempting to create an exchangeable format.
It is re-inventing the wheel by starting with a rectangle.
We already have all the style-sheets for XML to provide the formats we need (including wiki text).
-- Regards Frank
Frank Sundermeyer, Technical Writer, Documentation SUSE Linux Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Tel: +49-911-74053-0, Fax: +49-911-7417755; http://www.opensuse.org/ SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) "Reality is always controlled by the people who are most insane" Dogbert
Summarizing as I've been reading the posts on this thread throughout the day on my Blackberry. Frank, welcome to the Marketing list and I'm glad you were able to speak up about your role with documentation. I absolutely agree that content discussion should be taken to the documentation mailing list and am glad to see we're bringing together different people under one umbrella. this should help to further enhance openSUSE documentation efforts. The fact that many didn't realize the depth of your work emphasizes that we need to do more "inner-marketing" to our own community about what currently exists and how to engage with teams such as yours. we spend much time thinking about reaching out and too little time about reaching in. Your presence is definitely a wake-up call for us. :-) There are still some aspects of the discussion that still falls under marketing. Mainly in the area of visibility and getting proper documentation/books/material/etc. into as many hands as possible. In this way, we should definitely work together and leverage each other's strengths. This is why I created the liaison function to keep better aware of many things going on within the community itself. I supported the discussion in its beginning mainly because lately, I've been getting tired of seeing too many books for other distros and none from ours. O'Reilly stores at conferences and events carry Fedora and Ubuntu books, but no openSUSE books. visiting a major book store usually finds us only able to locate just one copy of a book, if we're even that lucky. And truly annoying lately is when I visit Amazon.com and the Recommended books section prominently displays other distro books, and not our own. Such documentation and books are not only a valuable necessity for getting knowledge into the right hands but also for increasing the visibility of openSUSE to the public and reminding them that we're still here, we're still strong and we're still awesome. :-) I will continue to support any endeavors by anyone to increase the availability and accessibility of such materials. At some point when I'm back home, I'll test the ebook link you gave us and see how it works on my Kindle. What is the best way to provide feedback without having to join the documentation mailing list? Bryen M Yunashko openSUSE Marketing Team lead -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
Hello, on Donnerstag, 30. September 2010, Frank Sundermeyer wrote:
On Thu, 30 Sep 2010 00:54:30 +0200 Jos Poortvliet wrote:
That is actually a pretty good point. If our Wiki is good enough in terms of content, we can try and figure out how to automate creating a book.
I completely disagree. You are proposing to create documentation in a completely unstructured format and then writing parsers attempting to create an exchangeable format.
See my mail some minutes ago - I think it is possible and not too hard.
It is re-inventing the wheel by starting with a rectangle.
Well, a pair of angle brackets in XML already looks like a rectangle - and not really like a circle *SCNR* [1]
We already have all the style-sheets for XML to provide the formats we need (including wiki text).
The problem is not "wiki text output" - that's easy. The problem is "merge changes in the wiki back". Regards, Christian Boltz [1] this side blow already was worth the mail *eg* -- [Evolution - Message-ID] Oh ja... Apropos: die libcamel (die fuer diesen Muell verantwortlich ist) ist, aehm. "interessant" zu lesen... Und NEIN! Ich habe keine Lust, den Muell zu fixen. Es sei denn, man zahlt mir Schmerzensgeld. [David Haller in suse-linux] -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
I would seriosly doubt the ad thing. Publishers would quit in a minute. And amazon requires that ads be stripped from subscription material.
Over in gnome I proposed connecting planet gnome to lindle and we are looking into that now. There's lots og gnome kindle users.
I also sent info to )aloki to look into doing the same for Planet openSUSE. And hopefully we will get that going as well.
Bryen
Sent from my Verizon Wireless BlackBerry
-----Original Message-----
From: Helen
We can offer it as a free book or charge a small publishing fee through Amazon and funnel a few bucks into the future openSUSE Foundation.
The potential opportunities abound here!
Bryen
P.S. When I say Kindle or Nook, I mean in their book formats, not sending to it as a PDF. For two reasons 1) PDF documents incur a charge to the user and 2) PDF formatting on Kindle REAAAAAALLLY sucks and is not very accessible for low-vison users. So we would do a disservice not publishing in native format that allows all users to be able to read it.
-- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
On Thu, 30 Sep 2010 14:01:14 +0200 Bryen Yunashko wrote: Hi,
I'd like to recommend that we also consider making this available on ebooks such as Kindle or Nook. I recently got my Kindle and I'm really enjoying the ability to quickly get my books and have it ready at all times.
in case you haven't done so, you might want to try the 11.3 eBooks http://community.opensuse.org/ebooks/ebooks113/ Feedback welcome. -- Regards Frank Frank Sundermeyer, Technical Writer, Documentation SUSE Linux Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Tel: +49-911-74053-0, Fax: +49-911-7417755; http://www.opensuse.org/ SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) "Reality is always controlled by the people who are most insane" Dogbert -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
On Thursday 30 Sep 2010 14:26:34 Frank Sundermeyer wrote:
in case you haven't done so, you might want to try the 11.3 eBooks
http://community.opensuse.org/ebooks/ebooks113/
Feedback welcome.
That's awesome! I had no idea we were already making .epubs out of our docu. I see some rendering errors where images are rendered underneath text in Okular, will investigate if this is your problem or mine. Will -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
Hi Will, Friday 01 October 2010
On Thursday 30 Sep 2010 14:26:34 Frank Sundermeyer wrote:
in case you haven't done so, you might want to try the 11.3 eBooks
http://community.opensuse.org/ebooks/ebooks113/
Feedback welcome.
That's awesome! I had no idea we were already making .epubs out of our docu.
If even internal people didn't know that, we really have to improve our marketing. ;)
I see some rendering errors where images are rendered underneath text in Okular, will investigate if this is your problem or mine.
By the way: Another option could be Calibre. Its' a Python/KDE4 tool and pretty impressive. It supports a wide range of ebook formats. The packaging is a bit tricky as it is picky about some dependencies and the right versions. You can find Calibre in my OBS repository under home:thomas- schraitle:calibre. Find more information on Calibre's homepage at http://calibre-ebook.com/. Gruß/Regards, Tom -- Thomas Schraitle ---------------------------------------------------------------------- SUSE LINUX GmbH >o) Documentation Specialist Maxfeldstrasse 5 /\\ 90409 Nuernberg _\_v http://en.opensuse.org/Documentation_Team http://developer.novell.com/wiki/index.php/Lessons_for_Lizards http://lizards.opensuse.org/author/thomas-schraitle/ --------------------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
On Miércoles, 29 de Septiembre de 2010 23:29:42 Rémy Marquis escribió:
On Wed, Sep 29, 2010 at 8:27 PM, Javier Llorente
wrote: Hello there,
I was thinking that having an openSUSE Handbook (or handbuch ;) in pdf format ready to be downloaded, printed and even ready to be sent to a publishing company is a good idea.
So, here's my proposal:
First, we would have to make a list of topics to be included and organise them in chapters, like the following draft:
****************************** The openSUSE Handbook ****************************** Introduction - What's the openSUSE project? - What's openSUSE?
Installing openSUSE - Different types of install methods - AutoYaST
Installing applications - Using 1-click - Using YaST - Using zypper
Desktop environments - An introduction to DEs (KDE, GNOME, XFCE, LXDE). - Enabling proprietary drivers (ATI, NVIDIA) - Multimedia - Printing - Games
System administration - Introduction to the command line - Networking - Security - Storage - Virtualization - Keeping openSUSE up-to-date - Upgrading openSUSE
Servers - Apache and lighttpd - MySQL and PostgreSQL - Postfix - BIND - Samba - CUPS etc
Other openSUSE Technologies - Build Service - SUSE Studio - KIWI
Second, we would have to write about those topics not included in the wiki and review those already written. That way we would have more relevant bits in both the wiki and handbook. Each topic doesn't have to be 100 page long ;-)
And last but not least we would have to put all the pieces together and make it available in pdf.
Drawbacks: We would need to update some of its contents for each openSUSE release. It needs more than two people to make it happen ;-)
On the other hand, I think that the handbook would make openSUSE more "visible" and a bit more "ready to use."
Comments and suggestions are welcome! :-)
Hi,
What do you intend to do differently from the official PDF doc? Maybe there is an opportunity to build something on the Lesson for Lizards foundation here?
See http://en.opensuse.org/Portal:Documentation and http://developer.novell.com/wiki/index.php/Lessons_for_Lizards
Well, I want to have more topics covered and in other format. What we already have could be used as a base. Cheers, -- Javier Llorente
On Wed, 29 Sep 2010 20:27:11 +0200 Javier Llorente wrote: Hi, (Disclaimer: I am working in the SUSE documentation department and am the person leading the openSUSE documentation project in our department) I am not reading opensuse-marketing (doing that now ;-)), but henne pointed me to this thread, therefore I did not answer earlier... Please move this discussion to opensuse-doc, where you can reach all people currently writing the openSUSE manuals as well as other people interested in documentation
I was thinking that having an openSUSE Handbook (or handbuch ;)
well, this may come as a surprise to most of you, but we already have that - and it's even shipped with each openSUSE version. The problem is that it is kind of a stealth documentation because it is almost impossible to find it when you do not know where to find it. The fact that most of you having participated in this thread are not aware of the existing documentation is proof for that. The documentation team has fought for a better visibility of the documentation for years with to avail - it would be good if you would join us and help us in this matter. Installing them by default (HTML and PDF) would be a good start. Having a documentation pattern would be a nice addition. Having a desktop icon providing access to the manuals as well as a menu entry in the main menu would make people aware of the documentation. Putting some work into the KDE and GNOME help centres to make them do what they are supposed to do would be another milestone ;-). Here is where you can find the official openSUSE documentation: Web: http://en.opensuse.org/SDB:Official_documentation System: Packages: HTML: * opensuse-manuals_en PDF: * opensuse-apparmor-quick_en-pdf (openSUSE AppArmor Quick Start) * opensuse-apps_en-pdf (openSUSE Application Guide) * opensuse-gnomequick_en-pdf (openSUSE GNOME Quickstart * opensuse-gnomeuser_en-pdf (openSUSE GNOME User Guide * opensuse-installquick_en-pdf (openSUSE Installation Quick Start) * opensuse-kdequick_en-pdf (openSUSE KDE Quickstart) * opensuse-kdeuser_en-pdf (openSUSE KDE User Guide) * opensuse-reference_en-pdf (openSUSE Reference) * opensuse-security_en-pdf (openSUSE Security Guide) OK, having had my rant here is my answer to Javier's initial mail and to other comments/proposals: See
in pdf format ready to be downloaded, printed and even ready to be sent to a publishing company is a good idea.
We currently provide color PDFs, HTML, and ePUB. We can also provide a ready-to-print PDF, neatly formatted ASCII, and MediaWiki text (basic functionality, stylesheets could need some work). The openSUSE documentation is created in XML (a subset of DocBook), because this is the only format that gives us the flexibility to produce almost every output format we currently need or will need in the future (we only recently dded ePUB). All openSUSE manuals are licensed under the GFDL.
****************************** The openSUSE Handbook ****************************** Introduction - What's the openSUSE project? - What's openSUSE?
Currently not covered in our manuals, but since the text is already available in the wiki, adding it should be fairly easy.
Installing openSUSE - Different types of install methods
Covered to some extend in the reference guide, if there is need this could be extended. The default installation path is also described as a step-by-step guide with screenshots in the Installation Quick Start.
- AutoYaST
Currently not part of the openSUSE manuals, but documentation exists for SLE and could be added. So far this hasn't been asked for.
Installing applications - Using 1-click - Using YaST - Using zypper
All covered in the reference and Start-Up Guides
Desktop environments - An introduction to DEs (KDE, GNOME, XFCE, LXDE).
* Gnome Quick Start * Gnome Manual * KDE Quick Start * KDE Manual * Application Guide XFCE and LXDE currently not available, this would need help from the community. In case of XFCE I would vote against writing our own manuals because the documentation provided by XFCE itself is very good. Maybe a quickstart (I probably could do it myself since I am an XFCE user). I do not know what's the status of the LXDE documentation, though.
- Enabling proprietary drivers (ATI, NVIDIA)
this seems to change with every release and always implies last minute changes - this is definitely a topic for the wiki, since a manual would probably already be outdated on release date
- Multimedia
Covered in the KDE, Gnome and Application Guides
- Printing
Covered in the Start-Up and (all the gory details) the Reference Guide
- Games
Currently not covered. To be honest, I do not see the need to document them (it would probably just be copying the existing documentation)
System administration - Introduction to the command line - Networking - Security - Storage - Virtualization - Keeping openSUSE up-to-date - Upgrading openSUSE
Everything is covered except Virtualization and Storage. Both topics are covered in SLES, so documentation is available in principle. So far, Product Management hasn't seen a need to include them with openSUSE.
Servers - Apache and lighttpd
Apache is covered in detail, lightttpd not. IMHO it is sufficient to document one of the two.
- MySQL and PostgreSQL - Postfix - BIND - Samba
All not covered. The reason for this is: Very good books each with several hundred pages exist on the market. We will not be able to cover those topics to the same extend as the books do. What we could do is to provide a basic introduction and that would not fit these complex topics.
- CUPS
Covered in the Reference Guide
etc
We also have a security Guide.
Other openSUSE Technologies - Build Service - KIWI
Both projects are under heavy development and are constantly changing. Documentation has to be written and maintained by the projects themselves, otherwise you will just produce outdated manuals that will help nobody. ;-)
- SUSE Studio
We have just finished writing a Studio guide (released under GFDL). It will be published under www.novell.com/documentation any day soon.
Drawbacks: We would need to update some of its contents for each openSUSE release. It needs more than two people to make it happen ;-)
It's more than that. the complete manual needs to be _reviewed_ and some of it's content has to be updated. The updated parts need to be proofread (content-wise and language-wise). The biggest challenge is, that all this has to be finished two weeks before release date. otherwise the manuals will not make it into the distribution. If the manuals are going to be translated (currently some guides are translated into German), they have to be ready 5 weeks before release date... .
On the other hand, I think that the handbook would make openSUSE more "visible" and a bit more "ready to use."
Comments and suggestions are welcome! :-)
Use what is already there and help to improve it ;-). Three years ago we (the Nuremberg documentation team) launched a project called Lessons for Lizards. The idea was to have a cookbook style manual covering all sorts of topics that don't make the official manuals. We provided the complete infrastructure (SVN, mailinglist, build environment, support, etc.) and a skeleton book that already included a few articles and a structure. The project was announced on different channels including a speech of mine at FOSDEM. We had a _single_ contributor (thanks a lot Alexey!) from the community and so the project slowly died... . (although it could be revived very quickly). -- Regards Frank Frank Sundermeyer, Technical Writer, Documentation SUSE Linux Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Tel: +49-911-74053-0, Fax: +49-911-7417755; http://www.opensuse.org/ SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) "Reality is always controlled by the people who are most insane" Dogbert -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
On Wed, 29 Sep 2010 20:27:11 +0200 Javier Llorente wrote:
Hi,
(Disclaimer: I am working in the SUSE documentation department and am the person leading the openSUSE documentation project in our department)
I am not reading opensuse-marketing (doing that now ;-)), but henne pointed me to this thread, therefore I did not answer earlier...
Moin, On Thursday 30 September 2010 12:48:32 Frank Sundermeyer wrote: thanks for jumping in here.
Please move this discussion to opensuse-doc, where you can reach all people currently writing the openSUSE manuals as well as other people interested in documentation
I was thinking that having an openSUSE Handbook (or handbuch ;)
well, this may come as a surprise to most of you, but we already have that - and it's even shipped with each openSUSE version. The problem is that it is kind of a stealth documentation because it is almost impossible to find it when you do not know where to find it.
The fact that most of you having participated in this thread are not aware of the existing documentation is proof for that.
The documentation team has fought for a better visibility of the documentation for years with to avail - it would be good if you would join us and help us in this matter.
Maybe you should share "your" feature request with the folks here: https://features.opensuse.org/306404 And from now on on opensuse-doc ;-) Best M
Installing them by default (HTML and PDF) would be a good start. Having a documentation pattern would be a nice addition. Having a desktop icon providing access to the manuals as well as a menu entry in the main menu would make people aware of the documentation. Putting some work into the KDE and GNOME help centres to make them do what they are supposed to do would be another milestone ;-).
Here is where you can find the official openSUSE documentation:
Web: http://en.opensuse.org/SDB:Official_documentation
System: Packages: HTML: * opensuse-manuals_en PDF: * opensuse-apparmor-quick_en-pdf (openSUSE AppArmor Quick Start) * opensuse-apps_en-pdf (openSUSE Application Guide) * opensuse-gnomequick_en-pdf (openSUSE GNOME Quickstart * opensuse-gnomeuser_en-pdf (openSUSE GNOME User Guide * opensuse-installquick_en-pdf (openSUSE Installation Quick Start) * opensuse-kdequick_en-pdf (openSUSE KDE Quickstart) * opensuse-kdeuser_en-pdf (openSUSE KDE User Guide) * opensuse-reference_en-pdf (openSUSE Reference) * opensuse-security_en-pdf (openSUSE Security Guide)
OK, having had my rant here is my answer to Javier's initial mail and to other comments/proposals:
See
in pdf format ready to be downloaded, printed and even ready to be sent to a publishing company is a good idea.
We currently provide color PDFs, HTML, and ePUB. We can also provide a ready-to-print PDF, neatly formatted ASCII, and MediaWiki text (basic functionality, stylesheets could need some work).
The openSUSE documentation is created in XML (a subset of DocBook), because this is the only format that gives us the flexibility to produce almost every output format we currently need or will need in the future (we only recently dded ePUB).
All openSUSE manuals are licensed under the GFDL.
****************************** The openSUSE Handbook ****************************** Introduction - What's the openSUSE project? - What's openSUSE?
Currently not covered in our manuals, but since the text is already available in the wiki, adding it should be fairly easy.
Installing openSUSE - Different types of install methods
Covered to some extend in the reference guide, if there is need this could be extended. The default installation path is also described as a step-by-step guide with screenshots in the Installation Quick Start.
- AutoYaST
Currently not part of the openSUSE manuals, but documentation exists for SLE and could be added. So far this hasn't been asked for.
Installing applications - Using 1-click - Using YaST - Using zypper
All covered in the reference and Start-Up Guides
Desktop environments - An introduction to DEs (KDE, GNOME, XFCE, LXDE).
* Gnome Quick Start * Gnome Manual * KDE Quick Start * KDE Manual * Application Guide
XFCE and LXDE currently not available, this would need help from the community. In case of XFCE I would vote against writing our own manuals because the documentation provided by XFCE itself is very good. Maybe a quickstart (I probably could do it myself since I am an XFCE user).
I do not know what's the status of the LXDE documentation, though.
- Enabling proprietary drivers (ATI, NVIDIA)
this seems to change with every release and always implies last minute changes - this is definitely a topic for the wiki, since a manual would probably already be outdated on release date
- Multimedia
Covered in the KDE, Gnome and Application Guides
- Printing
Covered in the Start-Up and (all the gory details) the Reference Guide
- Games
Currently not covered. To be honest, I do not see the need to document them (it would probably just be copying the existing documentation)
System administration - Introduction to the command line - Networking - Security - Storage - Virtualization - Keeping openSUSE up-to-date - Upgrading openSUSE
Everything is covered except Virtualization and Storage. Both topics are covered in SLES, so documentation is available in principle. So far, Product Management hasn't seen a need to include them with openSUSE.
Servers - Apache and lighttpd
Apache is covered in detail, lightttpd not. IMHO it is sufficient to document one of the two.
- MySQL and PostgreSQL - Postfix - BIND - Samba
All not covered. The reason for this is: Very good books each with several hundred pages exist on the market. We will not be able to cover those topics to the same extend as the books do. What we could do is to provide a basic introduction and that would not fit these complex topics.
- CUPS
Covered in the Reference Guide
etc
We also have a security Guide.
Other openSUSE Technologies - Build Service - KIWI
Both projects are under heavy development and are constantly changing. Documentation has to be written and maintained by the projects themselves, otherwise you will just produce outdated manuals that will help nobody. ;-)
- SUSE Studio
We have just finished writing a Studio guide (released under GFDL). It will be published under www.novell.com/documentation any day soon.
Drawbacks: We would need to update some of its contents for each openSUSE release. It needs more than two people to make it happen ;-)
It's more than that. the complete manual needs to be _reviewed_ and some of it's content has to be updated. The updated parts need to be proofread (content-wise and language-wise). The biggest challenge is, that all this has to be finished two weeks before release date. otherwise the manuals will not make it into the distribution. If the manuals are going to be translated (currently some guides are translated into German), they have to be ready 5 weeks before release date... .
On the other hand, I think that the handbook would make openSUSE more "visible" and a bit more "ready to use."
Comments and suggestions are welcome! :-)
Use what is already there and help to improve it ;-).
Three years ago we (the Nuremberg documentation team) launched a project called Lessons for Lizards. The idea was to have a cookbook style manual covering all sorts of topics that don't make the official manuals. We provided the complete infrastructure (SVN, mailinglist, build environment, support, etc.) and a skeleton book that already included a few articles and a structure. The project was announced on different channels including a speech of mine at FOSDEM.
We had a _single_ contributor (thanks a lot Alexey!) from the community and so the project slowly died... . (although it could be revived very quickly).
-- Michael Löffler, Product Management SUSE LINUX Products GmbH - Nürnberg - AG Nürnberg - HRB 16746 - GF: Markus Rex -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
Hi, On Thursday 30 September 2010 Frank Sundermeyer wrote:
[...]
Other openSUSE Technologies - Build Service - KIWI
Both projects are under heavy development and are constantly changing. Documentation has to be written and maintained by the projects themselves, otherwise you will just produce outdated manuals that will help nobody. ;-)
Right. If someone is interested: The DocBook sources are available in the KIWI Git repository, see git://git.berlios.de/kiwi directory doc/docbook.
- SUSE Studio
We have just finished writing a Studio guide (released under GFDL). It will be published under www.novell.com/documentation any day soon.
Should appear next week. -- Gruß/Regards, Thomas Schraitle ---------------------------------------------------------------------- SUSE LINUX Products GmbH (o< Documentation Specialist Maxfeldstrasse 5 /\\ 90409 Nuernberg, Germany _\_v http://en.opensuse.org/Documentation_Team SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
On Thursday 30 September 2010 12:48:32 Frank Sundermeyer wrote:
Use what is already there and help to improve it ;-).
I agree with that - could you give a pointer on how to improve the existing documentation? Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
Hello, on Donnerstag, 30. September 2010, Frank Sundermeyer wrote:
On Wed, 29 Sep 2010 20:27:11 +0200 Javier Llorente wrote:
- AutoYaST
Currently not part of the openSUSE manuals, but documentation exists for SLE and could be added. So far this hasn't been asked for. ...
System administration ... Everything is covered except Virtualization and Storage. Both topics are covered in SLES, so documentation is available in principle. So far, Product Management hasn't seen a need to include them with openSUSE.
General rule of thumb: If documentation exists, push it out for all products including openSUSE. Advantages: - there will _always_ be some people that find exactly this part of the manual useful. Why make it harder for them by not publishing it? - more people will use the affected tools (AutoYaST, virtualization ...) (From what I've heard from AutoYaST, it's a good tool, but probably not really understandable without documentation.) - errors in the manual are discovered earlier because of the broader audience Disadvantages: - the PDF will be 100k bigger ;-)) Regards, Christian Boltz -- Ich sags ja immer: RfCs in Stein meisseln (5cm starke Granitplatten, grosser Font) und diese Idioten solange damit schlagen, bis sie es entweder kapiert haben, oder der Genpool bereinigt wurde. [J. P. Meier in dasr] -- To unsubscribe, e-mail: opensuse-marketing+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-marketing+help@opensuse.org
participants (20)
-
Andreas Jaeger
-
Bruno Friedmann
-
Bryant, Christian
-
Bryen Yunashko
-
Carlos Ribeiro
-
Christian Boltz
-
Chuck Payne
-
Frank Sundermeyer
-
Helen
-
Javier Llorente
-
Jos Poortvliet
-
Klaas Freitag
-
Michael Loeffler
-
Nelson Marques
-
Rajko M.
-
Raul Libório
-
Rémy Marquis
-
suserocks@bryen.com
-
Thomas Schraitle
-
Will Stephenson