what next?

[Karsten Wade]

We now have a small handful of regular documents to keep updated for
each release: release notes; Installation Guide; Desktop User Guide.  We
also have other documents that get occasional updates, when needed or
prodded.

Looking here:

http://fedoraproject.org/wiki/Docs/Drafts
http://fedora.redhat.com/docs
http://fedoraproject.org/wiki/Docs

What is missing?

* Do we need to divide into more help for new-to-Fedora users?
* Should we put more energy into focusing on systems administrators who
are new to Fedora and/or Linux?
* How about updating our own Documentation Guide?
* There are other guides such as the Packaging Guide and the Developers
Guide that could use updating or editing; do we want to adopt these and
begin a highly technical interaction with Fedora developers?

We have a nice influx of new writers, and I'm curious where we all think
we should go next.  Let's discuss. :)

- Karsten
-- 
Karsten Wade, RHCE, 108 Editor    ^     Fedora Documentation Project 
 Sr. Developer Relations Mgr.     |  fedoraproject.org/wiki/DocsProject
   quaid.108.redhat.com           |          gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

[Dimitris Glezos]

Karsten Wade wrote:
>  We now have a small handful of regular documents to keep updated for
>  each release: release notes; Installation Guide; Desktop User Guide.  We
>  also have other documents that get occasional updates, when needed or
>  prodded.
>  
>  Looking here:
>  
>  http://fedoraproject.org/wiki/Docs/Drafts
>  http://fedora.redhat.com/docs
>  http://fedoraproject.org/wiki/Docs
>  
>  What is missing?
>  
>  * Do we need to divide into more help for new-to-Fedora users?
>  * Should we put more energy into focusing on systems administrators who
>  are new to Fedora and/or Linux?
>  * How about updating our own Documentation Guide?
>  * There are other guides such as the Packaging Guide and the Developers
>  Guide that could use updating or editing; do we want to adopt these and
>  begin a highly technical interaction with Fedora developers?
>  
>  We have a nice influx of new writers, and I'm curious where we all think
>  we should go next.  Let's discuss. :) 
I believe we should try to organize our docs in a way that they could be 
combined into one document (Fedora Handbook?). We have talked about this 
in the past: this should be developed in a modular way so that each 
document (chapter) has an editor and some writers. See a recent 
discussion at [1], [2]:

   [1]: http://www.fedoraforum.org/forum/showthread.php?t=125807
   [2]: 
https://www.redhat.com/archives/fedora-docs-list/2006-October/msg00081.html

The goal should be to ship a new guide with each release that will be 
available in PDF [3]. If we succeed in this, then we will have a 
printable manual for Fedora -- something very important IMHO for any 
person's bookshelf.

   [3]: http://fedoraproject.org/wiki/DocsProject/Tools/PDFconversion

Having such a goal will give us a vision much greater than "just a doc 
on a subpage of our website". I believe that it's importance will be 
greater than the sum of the current's docs importance; for example, it 
could become something that the FreeMedia program could ship for free 
too, or ambassadors hand it (or parts of it) at events and we will have 
to have it ready by the release date.

One easy way to handle this would be the wiki, like the Beats with a 
clear hierarchy that has cross-references between chapters. This way, we 
could monitor the changes and docs members could "maintain" chapters. If 
we go with the wiki-way, we can have people chip in here and there more 
easily.

Some sample contents:

   * Introduction
     - The Fedora Project
       + What is Fedora, FOSS, History
       + Getting help, Communicating, Participating
     - Packages
     - Glossary (jargon-buster)
   * Fedora Core 7: Tour, Release notes
   * Installing Fedora Core
   * Using Fedora's desktop
   * System administration
   * Tips and tricks
   * FAQ

And here are some more references:

   * TLDP guides [4]
   * Old "Linux Manuals and Documentation" page [5]
   * Gentoo Linux x86 Handbook [6]
   * Debian GNU/Linux Desktop Survival Guide [7]

   [4]: http://tldp.org/guides.html
   [5]: http://www.estart.co.za/linux_doc.html
   [6]: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1
   [7]: http://www.togaware.com/linux/survivor/


My 2 cents.

-d


-- 
Dimitris Glezos
Jabber ID: glezos(a)jabber.org, PGP: 0xA5A04C3B
http://dimitris.glezos.com/

"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--

[Bela Pesics]

On 11/6/06, Dimitris Glezos <dimitris(a)glezos.com&gt; wrote:

>  Some sample contents:
>
>     * Introduction
>       - The Fedora Project
>         + What is Fedora, FOSS, History
>         + Getting help, Communicating, Participating
>       - Packages
>       - Glossary (jargon-buster)
>     * Fedora Core 7: Tour, Release notes
>     * Installing Fedora Core
>     * Using Fedora's desktop
>     * System administration
>     * Tips and tricks
>     * FAQ
>
>  And here are some more references:
>
>     * TLDP guides [4]
>     * Old "Linux Manuals and Documentation" page [5]
>     * Gentoo Linux x86 Handbook [6] 
Pretty nice examples, consider the structure of these as well:

http://www.freebsd.org/docs.html
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/

I can also imagine using http://kbase.redhat.com/faq/ for something. I
am curious if the referenced materials could be used to put together a
handbook without double efforts in a efficient way.

And finally don't forget

http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/ref-guide/
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/security-guide/
(e.g. the vpn question)
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/step-guide/

Obviously these are not fedora docs and most people using fedora know
about them, however not everybody, and these are not compatible
everywhere, but I am sure there are some useful peaces. So they should
be referenced somehow. (sometimes better than empty wiki pages)

In addition I could see a current sysconfig documentation with
comments and examples very useful, that would solve many problems.

Bela

>     * Debian GNU/Linux Desktop Survival Guide [7]
>
>     [4]: http://tldp.org/guides.html
>     [5]: http://www.estart.co.za/linux_doc.html
>     [6]: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1
>     [7]: http://www.togaware.com/linux/survivor/
>
>
>  My 2 cents.
>
>  -d
>
>
>  --
>  Dimitris Glezos
>  Jabber ID: glezos(a)jabber.org, PGP: 0xA5A04C3B
>  http://dimitris.glezos.com/
>
>  "He who gives up functionality for ease of use
>  loses both and deserves neither." (Anonymous)
>  --
>
>  --
>  fedora-docs-list mailing list
>  fedora-docs-list(a)redhat.com
>  To unsubscribe:
>  https://www.redhat.com/mailman/listinfo/fedora-docs-list
>

[Karsten Wade]

On Mon, 2006-11-06 at 20:28 +0100, Bela Pesics wrote:

>  Pretty nice examples, consider the structure of these as well:
>  
>  http://www.freebsd.org/docs.html
>  http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ 
Ah, good ol' DocBook XML, how nice it is for making books. :)

>  I can also imagine using http://kbase.redhat.com/faq/ for something.
> I
>  am curious if the referenced materials could be used to put together a
>  handbook without double efforts in a efficient way. 
None of that content is directly relevant to Fedora; to make it relevant
either requires a user who can make the mental switches, or a writer who
edits the content to make it fit.  Also, I don't think that content is
licensed for us to use in any way other than to read it.

But ... hmm ... there has been discussion in the past of having a
kbase.fedoraproject.org that is a stand-alone knowledgebase.  If we
opened it to all Fedora account holders and had kbase articles queued
for this team to edit (part of a workflow), maybe we could build up
something very useful.  I could see many discussions on e.g. fedora-list
or fedoraforum.org being worth migrating into a kbase article.

So, this is an idea to follow, but not sure if we can directly connect
such live content into a handbook.  Certainly as a source for
inspiration, such as finding out the most commonly asked questions to
give an idea of what people need us to write about.

>  And finally don't forget
>  
>  http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/ref-guide/
>  http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/security-guide/
>  (e.g. the vpn question)
>  http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/
>  http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/step-guide/ 
Heh, I could never forget those. :)

>  Obviously these are not fedora docs and most people using fedora
> know
>  about them, however not everybody, and these are not compatible
>  everywhere, but I am sure there are some useful peaces. So they should
>  be referenced somehow. (sometimes better than empty wiki pages) 
We may be able to fold some of that content directly in, rewritten to
match Fedora.  Let's not make any plans that require that content, which
is too bad since it would provide such a huge base to work from :(, but
let's be prepared to be surprised.

- Karsten
-- 
Karsten Wade, RHCE, 108 Editor    ^     Fedora Documentation Project 
 Sr. Developer Relations Mgr.     |  fedoraproject.org/wiki/DocsProject
   quaid.108.redhat.com           |          gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

[Sam Folk-Williams]

On Tue, 2006-11-07 at 05:58 -0800, Karsten Wade wrote:
>  On Mon, 2006-11-06 at 20:28 +0100, Bela Pesics wrote:
>  
>  > Pretty nice examples, consider the structure of these as well:
>  > 
>  > http://www.freebsd.org/docs.html
>  > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/
>  
>  Ah, good ol' DocBook XML, how nice it is for making books. :)
>  
>  > I can also imagine using http://kbase.redhat.com/faq/ for something. I
>  > am curious if the referenced materials could be used to put together a
>  > handbook without double efforts in a efficient way.
>  
>  None of that content is directly relevant to Fedora; to make it relevant
>  either requires a user who can make the mental switches, or a writer who
>  edits the content to make it fit.  Also, I don't think that content is
>  licensed for us to use in any way other than to read it.
>  
>  But ... hmm ... there has been discussion in the past of having a
>  kbase.fedoraproject.org that is a stand-alone knowledgebase.  If we
>  opened it to all Fedora account holders and had kbase articles queued
>  for this team to edit (part of a workflow), maybe we could build up
>  something very useful.  I could see many discussions on e.g. fedora-list
>  or fedoraforum.org being worth migrating into a kbase article.
>   
+1 on this. I would really like to see a kbase for Fedora. I think it's
an excellent way to organize a large number of targeted how-to articles.
It can also be a lot easier for a contributor to write a brief kbase
than to get involved with a larger "guide" type of document. Then, guide
writers can pull from the kbase for ideas as well.
>  So, this is an idea to follow, but not sure if we can directly
> connect
>  such live content into a handbook.  Certainly as a source for
>  inspiration, such as finding out the most commonly asked questions to
>  give an idea of what people need us to write about.
>  
>  > And finally don't forget
>  > 
>  > http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/ref-guide/
>  > http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/security-guide/
>  > (e.g. the vpn question)
>  > http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/
>  > http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/step-guide/
>  
>  Heh, I could never forget those. :)
>  
>  > Obviously these are not fedora docs and most people using fedora know
>  > about them, however not everybody, and these are not compatible
>  > everywhere, but I am sure there are some useful peaces. So they should
>  > be referenced somehow. (sometimes better than empty wiki pages)
>  
>  We may be able to fold some of that content directly in, rewritten to
>  match Fedora.  Let's not make any plans that require that content, which
>  is too bad since it would provide such a huge base to work from :(, but
>  let's be prepared to be surprised.
>  
>  - Karsten
>  -- 
>  fedora-docs-list mailing list
>  fedora-docs-list(a)redhat.com
>  To unsubscribe: 
>  https://www.redhat.com/mailman/listinfo/fedora-docs-list 
-- 
Sam Folk-Williams, RHCE
Global Support Services

[Dimitris Glezos]

Sam Folk-Williams wrote:
>  On Tue, 2006-11-07 at 05:58 -0800, Karsten Wade wrote:
> > But ... hmm ... there has been discussion in the past of having a
> > kbase.fedoraproject.org that is a stand-alone knowledgebase.  If we
> > opened it to all Fedora account holders and had kbase articles queued
> > for this team to edit (part of a workflow), maybe we could build up
> > something very useful.  I could see many discussions on e.g. fedora-list
> > or fedoraforum.org being worth migrating into a kbase article.
> >
>  +1 on this. I would really like to see a kbase for Fedora. I think it's
>  an excellent way to organize a large number of targeted how-to articles.
>  It can also be a lot easier for a contributor to write a brief kbase
>  than to get involved with a larger "guide" type of document. Then, guide
>  writers can pull from the kbase for ideas as well. 
I think it would be better to avoid having too much information in 
FAQ-style, since although referencable, they are not very readable or 
usable as a manual.

On the other hand, it would be great if we had that information in the 
guides/chapters and compile a set of FAQ that the answer is like "More 
information for this can be found <there>. For customizing it, see 
Chapter <Foo>, paragraph <Bar>".

I believe the most difficult part of doing the Handbook would be to 
decide on a good hierarchy that strikes a good balance between 
usability/quality and reference-able.

> >>
> http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/ref-guide/
> >> http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/security-guide/
> >> (e.g. the vpn question)
> >> http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/
> >> http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/step-guide/
> > Heh, I could never forget those. :)
> >
> >> Obviously these are not fedora docs and most people using fedora know
> >> about them, however not everybody, and these are not compatible
> >> everywhere, but I am sure there are some useful peaces. So they should
> >> be referenced somehow. (sometimes better than empty wiki pages)
> > We may be able to fold some of that content directly in, rewritten to
> > match Fedora.  Let's not make any plans that require that content, which
> > is too bad since it would provide such a huge base to work from :(, but
> > let's be prepared to be surprised. 
Who should we contact to move some strings to free those docs? It would 
be *great* if we could use them.

-d


-- 
Dimitris Glezos
Jabber ID: glezos(a)jabber.org, PGP: 0xA5A04C3B
http://dimitris.glezos.com/

"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--

[Karsten Wade]

On Tue, 2006-11-07 at 14:46 +0000, Dimitris Glezos wrote:

>  I think it would be better to avoid having too much information in 
>  FAQ-style, since although referencable, they are not very readable or 
>  usable as a manual.
>  
>  On the other hand, it would be great if we had that information in the 
>  guides/chapters and compile a set of FAQ that the answer is like "More 
>  information for this can be found <there>. For customizing it, see 
>  Chapter <Foo>, paragraph <Bar>". 
Right, we have to have a process that integrates the two properly.
Regardless of our individual preferences, knowledgebase-style content is
very popular and useful.

We might be able to think of this as part of the modularizing of
content.  That is, can we write content in such a way that it is both
useful in a kbase and fits into an overall document?  Perhaps, perhaps
not.

>  I believe the most difficult part of doing the Handbook would be to 
>  decide on a good hierarchy that strikes a good balance between 
>  usability/quality and reference-able. 
Yes, and we might want to strike toward the former and let other works
do the latter, which is where formal (kbase) and informal (forums, etc.)
fit in.

>  >>>
> http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/ref-guide/
>  >>> http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/security-guide/
>  >>> (e.g. the vpn question)
>  >>> http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/
>  >>> http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/step-guide/
>  Who should we contact to move some strings to free those docs? It
> would 
>  be *great* if we could use them. 
We[1] called in Max Spevack some months ago to help make this happen,
since I wasn't able to get it completed myself.  Anyone who wants to
lend support to this idea, please email Max directly with a personal
plea, useful cases, etc.; he agrees with us, but it is helpful to know
exactly what the community wants when we are discussing schedules with
RHEL team members.

- Karsten
[1] We == Rahul, Paul, and myself
-- 
Karsten Wade, RHCE, 108 Editor    ^     Fedora Documentation Project 
 Sr. Developer Relations Mgr.     |  fedoraproject.org/wiki/DocsProject
   quaid.108.redhat.com           |          gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

[Dimitris Glezos]

Karsten Wade wrote:
>  On Tue, 2006-11-07 at 14:46 +0000, Dimitris Glezos wrote:
>  
> > I think it would be better to avoid having too much information in 
> > FAQ-style, since although referencable, they are not very readable or 
> > usable as a manual.
> >
> > On the other hand, it would be great if we had that information in the 
> > guides/chapters and compile a set of FAQ that the answer is like "More 
> > information for this can be found <there>. For customizing it, see 
> > Chapter <Foo>, paragraph <Bar>".
>  
>  Right, we have to have a process that integrates the two properly.
>  Regardless of our individual preferences, knowledgebase-style content is
>  very popular and useful. 
I believe we can do that. We just have to start designing and agreeing 
on a good hierarchy for our handbook and build on top of that. Oh, and 
of course, decide what our audience will be. :)

>  We might be able to think of this as part of the modularizing of
>  content.  That is, can we write content in such a way that it is both
>  useful in a kbase and fits into an overall document?  Perhaps, perhaps
>  not. 
One definite goal of our should be to *converge* the places/ways we 
maintain content and minimize the same-content-different-location 
issues. Try to move as much informally-written content as possible from 
the wiki to the guides/handbook.

The difficult part would be to strike a good balance for this. Ie, we 
want to minimize duplicate content but at the same time we want the 
Release notes to contain installation notes that should exist in the 
Installation Guide. Modularization implies maintainability but also 
dependencies and we will have to make some choices for the places where 
we will duplicate content instead of referencing.

> > I believe the most difficult part of doing the Handbook would be
> to 
> > decide on a good hierarchy that strikes a good balance between 
> > usability/quality and reference-able.
>  
>  Yes, and we might want to strike toward the former and let other works
>  do the latter, which is where formal (kbase) and informal (forums, etc.)
>  fit in. 
+1. The kbase's aim should be to serve as reference the content of our 
documentation (something like a FAQ).

> >>>>...
> >>>> http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/step-guide/
>  
> > Who should we contact to move some strings to free those docs? It would 
> > be *great* if we could use them.
>  
>  We[1] called in Max Spevack some months ago to help make this happen,
>  since I wasn't able to get it completed myself.  Anyone who wants to
>  lend support to this idea, please email Max directly with a personal
>  plea, useful cases, etc.; he agrees with us, but it is helpful to know
>  exactly what the community wants when we are discussing schedules with
>  RHEL team members. 
I guess we'll know what we really need when we agree on the structure of 
our big doc.

If everyone is OK with the idea, I'll try to bootstrap a tree structure 
based on other guides (like the excellent FreeBSD cookbook) and put it 
on the wiki for further discussion. Thankfully, most of the big parts 
are already there (IG, DUG, FAQ).

-d


-- 
Dimitris Glezos
Jabber ID: glezos(a)jabber.org, PGP: 0xA5A04C3B
http://dimitris.glezos.com/

"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--

[Karsten Wade]

On Thu, 2006-11-09 at 17:02 +0000, Dimitris Glezos wrote:

>  I believe we can do that. We just have to start designing and
> agreeing 
>  on a good hierarchy for our handbook and build on top of that. Oh, and 
>  of course, decide what our audience will be. :) 
s/audience/audiences/ :)

Let's start with where the most pain is, people who are new to Fedora
and/or Linux.  Make sense?

Our plan should be able to handle content addressed at all levels, but
this "Experienced computer user who knows what they want to do but who
is knew to Fedora" is a good place to start.

In parallel, we can work on content that is good for experienced users
who want more formal content that tells how to do more advanced stuff,
like the Administration Guide.  Just given a choice of resources ...
well, admins can adapt content from other distros better than newbies
can. :)

>  One definite goal of our should be to *converge* the places/ways we 
>  maintain content and minimize the same-content-different-location 
>  issues. Try to move as much informally-written content as possible from 
>  the wiki to the guides/handbook. 
+1, except I'd like to see a way, as we are discussing, where the Wiki
is an editor choice.  All content in XML but your choice of editors.
Wow.

>  The difficult part would be to strike a good balance for this. Ie, we
>
>  want to minimize duplicate content but at the same time we want the 
>  Release notes to contain installation notes that should exist in the 
>  Installation Guide. Modularization implies maintainability but also 
>  dependencies and we will have to make some choices for the places where 
>  we will duplicate content instead of referencing. 
We may need to move beyond to DITA to do this, and for us to be
successful at that, we need to make success with what we have so far.
Yes?

>  If everyone is OK with the idea, I'll try to bootstrap a tree
> structure 
>  based on other guides (like the excellent FreeBSD cookbook) and put it 
>  on the wiki for further discussion. Thankfully, most of the big parts 
>  are already there (IG, DUG, FAQ). 
If you didn't see this, this is the page that I threw up recently from
the initial handbook discussion earlier this/last week:

http://fedoraproject.org/wiki/DocsProject/Handbook

Just a place to start from. :)

- Karsten
-- 
Karsten Wade, RHCE, 108 Editor    ^     Fedora Documentation Project 
 Sr. Developer Relations Mgr.     |  fedoraproject.org/wiki/DocsProject
   quaid.108.redhat.com           |          gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

[Karsten Wade]

On Tue, 2006-11-07 at 09:09 -0500, Sam Folk-Williams wrote:

>  +1 on this. I would really like to see a kbase for Fedora. I think
> it's
>  an excellent way to organize a large number of targeted how-to articles.
>  It can also be a lot easier for a contributor to write a brief kbase
>  than to get involved with a larger "guide" type of document. Then, guide
>  writers can pull from the kbase for ideas as well. 
Do you want this enough to help with the research and implementation? :D
I added you to the task on the task schedule, let me know if you cannot
work on this over the next few months, and we'll figure something else
out.

Tasks include figuring out what tool is best (work with FI directly or
through mmcgrath) and what processes to use.  We might be able to make
this part of Plone.  We certainly want to consider all the various
problems of a kbase and how to mitigate them.

http://fedoraproject.org/wiki/DocsProject/SteeringCommittee/TaskSchedule

We definitely want kbase to reference larger content, and a
process/workflow that allows us to easily edit kbase entries.

- Karsten
-- 
Karsten Wade, RHCE, 108 Editor    ^     Fedora Documentation Project 
 Sr. Developer Relations Mgr.     |  fedoraproject.org/wiki/DocsProject
   quaid.108.redhat.com           |          gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

[Sam Folk-Williams]

On Thu, 2006-11-09 at 08:01 -0800, Karsten Wade wrote:
>  On Tue, 2006-11-07 at 09:09 -0500, Sam Folk-Williams wrote:
>  
>  > +1 on this. I would really like to see a kbase for Fedora. I think it's
>  > an excellent way to organize a large number of targeted how-to articles.
>  > It can also be a lot easier for a contributor to write a brief kbase
>  > than to get involved with a larger "guide" type of document. Then, guide
>  > writers can pull from the kbase for ideas as well.
>  
>  Do you want this enough to help with the research and implementation? :D
>  I added you to the task on the task schedule, let me know if you cannot
>  work on this over the next few months, and we'll figure something else
>  out.
>   
Sure thing. Sounds good.

>  Tasks include figuring out what tool is best (work with FI directly
> or
>  through mmcgrath) and what processes to use.  We might be able to make
>  this part of Plone.  We certainly want to consider all the various
>  problems of a kbase and how to mitigate them.
>  
>  http://fedoraproject.org/wiki/DocsProject/SteeringCommittee/TaskSchedule
>  
>  We definitely want kbase to reference larger content, and a
>  process/workflow that allows us to easily edit kbase entries.
>   
I've done a lot of research and work into kbase solutions for my current
job. And i definitely have a favorite. Adding yet another tool is always
a pain, but I am convinced this is *the* kbase tool:

http://sourceforge.net/projects/klear

i believe this was discussed in the past:
http://www.redhat.com/archives/fedora-dsco-list/2005-June/msg00011.html
>  - Karsten
>  -- 
>  fedora-docs-list mailing list
>  fedora-docs-list(a)redhat.com
>  To unsubscribe: 
>  https://www.redhat.com/mailman/listinfo/fedora-docs-list 
-- 
Sam Folk-Williams, RHCE
Global Support Services

[Dimitris Glezos]

Karsten Wade wrote:
>  On Mon, 2006-11-06 at 20:28 +0100, Bela Pesics wrote:
> > [...]
> > I can also imagine using http://kbase.redhat.com/faq/ for something. I
> > am curious if the referenced materials could be used to put together a
> > handbook without double efforts in a efficient way.
>  
>  [...]
>  But ... hmm ... there has been discussion in the past of having a
>  kbase.fedoraproject.org that is a stand-alone knowledgebase.  If we
>  opened it to all Fedora account holders and had kbase articles queued
>  for this team to edit (part of a workflow), maybe we could build up
>  something very useful.  I could see many discussions on e.g. fedora-list
>  or fedoraforum.org being worth migrating into a kbase article.
>  
>  So, this is an idea to follow, but not sure if we can directly connect
>  such live content into a handbook.  Certainly as a source for
>  inspiration, such as finding out the most commonly asked questions to
>  give an idea of what people need us to write about. 
So, as I see it we need a balance between a solid solution like 
"everything in Docbook" or a usable solution like "everything in the 
wiki or in a kbase". With the first approach 
*publication/maintainability* is easier and more simple but with the 
second the actual *writing* is. Second has advantages like better 
monitoring/live results, but with the cost of less functionality and a 
cost overhead for producing the final form.

With the MoinDocbook we try to do a little of both but it seems that the 
transition from wiki to Docbook is not as easy nor as solid as it sounds 
(correct me if I'm wrong here). The problem could be that we are trying 
to maintain the content in two forms instead of one with just two 
front-ends (the web one and the cvs-checkout/emacs one).

I'll throw another idea on the table (probably a bit bold too), since 
now it's the best time to do it.

Maybe a live web front-end to the actual Docbook code in CVS/SVN would 
be a better solution? Let's say, we can see live the Docbook results and 
edit individual paragraphs, with each edit resulting in CVS commits? If 
we hook this up with the accounts system, everybody will be able to chip 
in like with the Beats system, and the result would be maintainable with 
the power of Docobok/CVS (no need to convert). I searched a bit and 
found a project that does exactly that:

  http://doc-book.sourceforge.net

I don't know if it's worth it (the customizing etc.), but it could be a 
candidate to substitute the wiki <-> docbook conversion. It is written 
in PHP, it uses xmltproc and friends, it seems to support multiple 
languages, content approving, intermediate docbook-focused syntax (or 
docbook). Last update was 1.5 year ago.

Actually, a month ago a similar discussion was made on Mark 
Shuttleworth's weblog under a post named "Writing a book collaboratively":

   http://www.markshuttleworth.com/archives/59

It seems that the above project was proposed as a good candidate. So, 
maybe this could be a good candidate for a joint project between the 
Ubuntu and Fedora teams? :)

-d



-- 
Dimitris Glezos
Jabber ID: glezos(a)jabber.org, PGP: 0xA5A04C3B
http://dimitris.glezos.com/

"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--

[Paul W. Frields]

On Tue, 2006-11-07 at 18:46 +0000, Dimitris Glezos wrote:
>  Karsten Wade wrote:
>  > On Mon, 2006-11-06 at 20:28 +0100, Bela Pesics wrote:
>  >> [...]
>  >> I can also imagine using http://kbase.redhat.com/faq/ for something. I
>  >> am curious if the referenced materials could be used to put together a
>  >> handbook without double efforts in a efficient way.
>  > 
>  > [...]
>  > But ... hmm ... there has been discussion in the past of having a
>  > kbase.fedoraproject.org that is a stand-alone knowledgebase.  If we
>  > opened it to all Fedora account holders and had kbase articles queued
>  > for this team to edit (part of a workflow), maybe we could build up
>  > something very useful.  I could see many discussions on e.g. fedora-list
>  > or fedoraforum.org being worth migrating into a kbase article.
>  > 
>  > So, this is an idea to follow, but not sure if we can directly connect
>  > such live content into a handbook.  Certainly as a source for
>  > inspiration, such as finding out the most commonly asked questions to
>  > give an idea of what people need us to write about.
>  
>  So, as I see it we need a balance between a solid solution like 
>  "everything in Docbook" or a usable solution like "everything in the 
>  wiki or in a kbase". With the first approach 
>  *publication/maintainability* is easier and more simple but with the 
>  second the actual *writing* is.  
Don't confuse writing with tagging.  You can *write* in plain old ASCII
for that matter.  DocBook tagging can be done by someone else who knows
how, if a contributor doesn't.  (But DocBook is very easy to learn for
anyone who wants to.)

>  Second has advantages like better 
>  monitoring/live results, but with the cost of less functionality and a 
>  cost overhead for producing the final form. 
The former advantage is erased by a decent content management system,
and the disadvantages then topple this option.  There's a reason the
entire FOSS world, more or less, chooses DocBook rather than one of the
various flavors of wiki markup.

>  With the MoinDocbook we try to do a little of both but it seems that
> the 
>  transition from wiki to Docbook is not as easy nor as solid as it sounds 
>  (correct me if I'm wrong here). The problem could be that we are trying 
>  to maintain the content in two forms instead of one with just two 
>  front-ends (the web one and the cvs-checkout/emacs one). 
Wiki -> DocBook will never approach greatness because there's no way to
map the tagging.  Sad but true. :-)

>  I'll throw another idea on the table (probably a bit bold too),
> since 
>  now it's the best time to do it.
>  
>  Maybe a live web front-end to the actual Docbook code in CVS/SVN would 
>  be a better solution? Let's say, we can see live the Docbook results and 
>  edit individual paragraphs, with each edit resulting in CVS commits? If 
>  we hook this up with the accounts system, everybody will be able to chip 
>  in like with the Beats system, and the result would be maintainable with 
>  the power of Docobok/CVS (no need to convert). I searched a bit and 
>  found a project that does exactly that:
>  
>    http://doc-book.sourceforge.net
>  
>  I don't know if it's worth it (the customizing etc.), but it could be a 
>  candidate to substitute the wiki <-> docbook conversion. It is written 
>  in PHP, it uses xmltproc and friends, it seems to support multiple 
>  languages, content approving, intermediate docbook-focused syntax (or 
>  docbook). Last update was 1.5 year ago. 
(1) PHP will, AFAICT, never be used on fedoraproject.org.  The admins
have spoken.

(2) Even if (1) were not true, I'm not excited about diverting energy
that would be better spent on figuring out a Plone-based solution.  Yes,
there are some Plone issues still being worked, like authentication, but
it's the future.  Let's embrace it.

Let me go out on a limb here and make a suggestion:  If anyone here is
interested in furthering our next publishing platform -- LEARN PLONE!  I
don't mean say, "Yes, we should learn Plone."  (Or worse yet, "Plone
should be learned by someone.")  I mean, "Learn Plone.  Do it.  DO IT."

/me finishes attack on passive voice   :-D

>  Actually, a month ago a similar discussion was made on Mark 
>  Shuttleworth's weblog under a post named "Writing a book collaboratively":
>  
>     http://www.markshuttleworth.com/archives/59
>  
>  It seems that the above project was proposed as a good candidate. So, 
>  maybe this could be a good candidate for a joint project between the 
>  Ubuntu and Fedora teams? :) 
See above.  Joint projects good, PHP... not so much.  (In fairness,
we've looked at this exact solution before.)

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
       Fedora Project Board: http://fedoraproject.org/wiki/Board
    Fedora Docs Project:  http://fedoraproject.org/wiki/DocsProject

[Dimitris Glezos]

Paul W. Frields wrote:
>  On Tue, 2006-11-07 at 18:46 +0000, Dimitris Glezos wrote:
> >   http://doc-book.sourceforge.net
> >
> > I don't know if it's worth it (the customizing etc.), but it could be a 
> > candidate to substitute the wiki <-> docbook conversion. It is written 
> > in PHP, it uses xmltproc and friends, it seems to support multiple 
> > languages, content approving, intermediate docbook-focused syntax (or 
> > docbook). Last update was 1.5 year ago.
>  
>  (1) PHP will, AFAICT, never be used on fedoraproject.org.  The admins
>  have spoken.
>  
>  (2) Even if (1) were not true, I'm not excited about diverting energy
>  that would be better spent on figuring out a Plone-based solution.  Yes,
>  there are some Plone issues still being worked, like authentication, but
>  it's the future.  Let's embrace it. 
I know, but Paul, do we have the resources to build a Plone front-end 
for DocBook from scratch? Don't want to sound pessimistic here, but this 
might require a lot of work to "do it right".

Because there are always some parameters that will be tight, probably we 
shouldn't abolish anything *completely* and probably do some compromises 
at a point. For example (I don't know if this *is* feasible), but if we 
do find the above project useful, we might be able to run PHP on a 
separate XEN machine that handles just the admin/editing part of the 
docs: `http://docs-admin.fedoraproject.org/`. Then this could be 
exported to a live version on a production system.

Just throwing ideas here, because if we are going to collaboratively 
write a book, we should start thinking it's maintainability. Not how to 
write it, but how to maintain it.

>  Let me go out on a limb here and make a suggestion:  If anyone here
> is
>  interested in furthering our next publishing platform -- LEARN PLONE! 
>  I don't mean say, "Yes, we should learn Plone."  (Or worse yet,
> "Plone
>  should be learned by someone.")  I mean, "Learn Plone.  Do it.
>  DO IT." 
OK, here is an idea to get this forward: Someone with knowledge of what 
we have, what we need and how we need it (say, you or Karsten or Bob?) 
write down on the wiki some ideas (UML-style) of what the Plone 
solution/worflows might need, with decreasing importance/urgency. The 
more detailed it is, the more motivating it will be for new members of 
the Docs and Infrastructure team to jump in and try implementing 
something on their installation of Plone at home. The wiki page for this is:

   http://fedoraproject.org/wiki/DocsProject/PloneIssues

An example with details:

Given: Plone v.X, Python v.Y, Mercurial VCS with Docbook, ready-made 
authentication framework from the Infrastructure project.

  * State: We are looking an HTML-rendered page of a doc's page.
  * Priority 1: Front-end to show live-rendered Docbook HTML
  * P2: "Edit" buttons for each Docbook file.
  * P3: "Edit" buttons in each section/paragraph, like Wikipedia ones.
  * P3: Ability for admins to tag changes as "live" from the web.

  * State: An editor sees a tree view of the whole Docbook titles (TOC).
  * P1: Editors to be able to re-organize the structure: Eg. change a 
section's parent section.
  * P3: Ability to quickly edit the Docbook IDs of the sections (anchors).

...etc.

I could write something like this, based on the features of the 
`doc-book.sf.net` software, but you guys know much better what we really 
need to get this done.

Oh, and another issue to have in mind: If we *do* go for a 100% plone 
solution, the tools might need a lot of work, probably too much for FC7 
or even FC8. Correct me if I am wrong. :)

-d


-- 
Dimitris Glezos
Jabber ID: glezos(a)jabber.org, PGP: 0xA5A04C3B
http://dimitris.glezos.com/

"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--

[Paul W. Frields]

On Wed, 2006-11-08 at 14:39 +0000, Dimitris Glezos wrote:
>  Paul W. Frields wrote:
>  > On Tue, 2006-11-07 at 18:46 +0000, Dimitris Glezos wrote:
>  >>   http://doc-book.sourceforge.net
>  >>
>  >> I don't know if it's worth it (the customizing etc.), but it could be a
>
>  >> candidate to substitute the wiki <-> docbook conversion. It is written 
>  >> in PHP, it uses xmltproc and friends, it seems to support multiple 
>  >> languages, content approving, intermediate docbook-focused syntax (or 
>  >> docbook). Last update was 1.5 year ago.
>  > 
>  > (1) PHP will, AFAICT, never be used on fedoraproject.org.  The admins
>  > have spoken.
>  > 
>  > (2) Even if (1) were not true, I'm not excited about diverting energy
>  > that would be better spent on figuring out a Plone-based solution.  Yes,
>  > there are some Plone issues still being worked, like authentication, but
>  > it's the future.  Let's embrace it.
>  
>  I know, but Paul, do we have the resources to build a Plone front-end 
>  for DocBook from scratch? Don't want to sound pessimistic here, but this 
>  might require a lot of work to "do it right". 
I'm out of my depth with Plone, but my understanding is that because of
the way Plone works, there's less to do here than a "from scratch"
solution.  I can't tell you why... but many other people told me that
Plone's built-in XML handling and its object model make this an
attainable goal.  I don't think it's a matter of selecting some options,
but it's probably not much more work than our SoC intern did for Moin ->
DB.

>  > Let me go out on a limb here and make a suggestion:  If anyone
> here is
>   > interested in furthering our next publishing platform -- LEARN PLONE! 
>    > I don't mean say, "Yes, we should learn Plone."  (Or worse yet,
> "Plone
>   > should be learned by someone.")  I mean, "Learn Plone.  Do it.
>   > DO IT."
>  
>  OK, here is an idea to get this forward: Someone with knowledge of what 
>  we have, what we need and how we need it (say, you or Karsten or Bob?) 
>  write down on the wiki some ideas (UML-style) of what the Plone 
>  solution/worflows might need, with decreasing importance/urgency. The 
>  more detailed it is, the more motivating it will be for new members of 
>  the Docs and Infrastructure team to jump in and try implementing 
>  something on their installation of Plone at home. The wiki page for this is:
>  
>     http://fedoraproject.org/wiki/DocsProject/PloneIssues
>  
>  An example with details:
>  
>  Given: Plone v.X, Python v.Y, Mercurial VCS with Docbook, ready-made 
>  authentication framework from the Infrastructure project.
>  
>    * State: We are looking an HTML-rendered page of a doc's page.
>    * Priority 1: Front-end to show live-rendered Docbook HTML
>    * P2: "Edit" buttons for each Docbook file.
>    * P3: "Edit" buttons in each section/paragraph, like Wikipedia ones.
>    * P3: Ability for admins to tag changes as "live" from the web.
>  
>    * State: An editor sees a tree view of the whole Docbook titles (TOC).
>    * P1: Editors to be able to re-organize the structure: Eg. change a 
>  section's parent section.
>    * P3: Ability to quickly edit the Docbook IDs of the sections (anchors).
>  
>  ...etc.
>  
>  I could write something like this, based on the features of the 
>  `doc-book.sf.net` software, but you guys know much better what we really 
>  need to get this done. 
This is a good idea.  If you want to kick this off, I'm sure I and
others will contribute to it as well.

>  Oh, and another issue to have in mind: If we *do* go for a 100% plone
>
>  solution, the tools might need a lot of work, probably too much for FC7 
>  or even FC8. Correct me if I am wrong. :) 
I don't think we're going to know that until someone with Plone
experience gives us a real bead on what's already available for the
platform.  We really need some good informed advice from a true expert
in that product.

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
       Fedora Project Board: http://fedoraproject.org/wiki/Board
    Fedora Docs Project:  http://fedoraproject.org/wiki/DocsProject

[Karsten Wade]

I'll try to reply here with all my thoughts to this part of the thread,
rather than repeating myself into this thread-branch.  HTH.

On Tue, 2006-11-07 at 18:46 +0000, Dimitris Glezos wrote:
>  So, as I see it we need a balance between a solid solution like 
>  "everything in Docbook" or a usable solution like "everything in the 
>  wiki or in a kbase". With the first approach 
>  *publication/maintainability* is easier and more simple but with the 
>  second the actual *writing* is. Second has advantages like better 
>  monitoring/live results, but with the cost of less functionality and a 
>  cost overhead for producing the final form.
>  
>  With the MoinDocbook we try to do a little of both but it seems that the 
>  transition from wiki to Docbook is not as easy nor as solid as it sounds 
>  (correct me if I'm wrong here). The problem could be that we are trying 
>  to maintain the content in two forms instead of one with just two 
>  front-ends (the web one and the cvs-checkout/emacs one). 
It's a combination of technical and procedural.  For something like the
release notes, I think the Wiki -> DB works great, ideally.  We still
have some bugs to work out, but they are minor in comparison.

>  I'll throw another idea on the table (probably a bit bold too),
> since 
>  now it's the best time to do it.
>  
>  Maybe a live web front-end to the actual Docbook code in CVS/SVN would 
>  be a better solution? Let's say, we can see live the Docbook results and 
>  edit individual paragraphs, with each edit resulting in CVS commits? If 
>  we hook this up with the accounts system, everybody will be able to chip 
>  in like with the Beats system, and the result would be maintainable with 
>  the power of Docobok/CVS (no need to convert).  
Not too bold at all, and has been discussed on this list before you came
around.  The idea is solid and we defined some ideas of how to do this
with the upcoming code in Moin Moin.  The basic idea is to have Wiki
constructs for easy block code (<para>, <itemizedlist>, etc.) and then
find some way to expose actual XML within the Wiki itself.  (This is
what 'DocBook Wiki' does that you reference below.)

Personally, I think we need to pursue this with Moin and the plans Mikko
and I made over the summer:

http://fedoraproject.org/wiki/MoinDocBookProject/PassThroughBlocks

Read through this entire road map to understand a little more:

http://fedoraproject.org/wiki/MoinDocBookProject/RoadMap

>  I searched a bit and 
>  found a project that does exactly that:
>  
>    http://doc-book.sourceforge.net
>  
>  I don't know if it's worth it (the customizing etc.), but it could be a 
>  candidate to substitute the wiki <-> docbook conversion. It is written 
>  in PHP, it uses xmltproc and friends, it seems to support multiple 
>  languages, content approving, intermediate docbook-focused syntax (or 
>  docbook). Last update was 1.5 year ago. 
We took a serious look at this internally at Red Hat and ran into
several show-stoppers.  The content is stored in the SCM (CVS or SVN) in
a very unique way that is hard to map to DocBook needs.  In fact, iirc,
we could not use XIncludes properly because of the directory structure.
There were other technical limitations that don't come to mind; Jeff
Fearn might be able to enlighten us further here, if he wants to
decloak.

There are also concerns about maintainability.  This DocBook Wiki would
setup an entirely new piece of infrastructure that no one is familiar
with, and FI is not interested in supporting.  It is also a bit out of
date, and while I don't think Dashamir has abandoned the project, it
does not seem to be his main focus.  So, we would likely need to have
someone become an active upstream supported to have success.

With Moin, we have all that already -- it is understood, supported, and
we are working with the very active upstream to get our changes in and
supported, probably maintained by someone from Fedora.

I will balance this with saying that actually looking at the UI for
DocBook Wiki makes it look like a great idea; it is rather elegant the
way he made it work, which is where I got the idea to embed XML within
the Wiki markup.

- Karsten
-- 
Karsten Wade, RHCE, 108 Editor    ^     Fedora Documentation Project 
 Sr. Developer Relations Mgr.     |  fedoraproject.org/wiki/DocsProject
   quaid.108.redhat.com           |          gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

[Karsten Wade]

On Mon, 2006-11-06 at 17:17 +0000, Dimitris Glezos wrote:

>  I believe we should try to organize our docs in a way that they could
> be 
>  combined into one document (Fedora Handbook?). We have talked about this 
>  in the past: this should be developed in a modular way so that each 
>  document (chapter) has an editor and some writers. See a recent 
>  discussion at [1], [2]:
>  
>     [1]: http://www.fedoraforum.org/forum/showthread.php?t=125807
>     [2]: 
>  https://www.redhat.com/archives/fedora-docs-list/2006-October/msg00081.html 
+1

That has been the goal for about ... 18 months?  Looking at your
outline, we have a large amount of that work done already -
installation, desktop usage, release notes, FAQ.  

I've hesitated at taking on a large project for a single document output
that requires so many people to make it happen.  For the first time in
this project's history, I think we can do it.  It means many of you are
going to need to learn to write in a consistent style using a common
voice and common markup.  But the momentum is here as well as the need,
and obviously we are desiring a single, unified Fedora Handbook. :)

There are still tools we need in place to make this work right (Plone,
PDF toolchain, Wiki <-> XML), but these are just implementation details.

>  The goal should be to ship a new guide with each release that will be
>
>  available in PDF [3]. If we succeed in this, then we will have a 
>  printable manual for Fedora -- something very important IMHO for any 
>  person's bookshelf. 
http://fedoraproject.org/wiki/DocsProject/Handbook

Let's work out the structure and other process details/tasks there.

>     [3]:
> http://fedoraproject.org/wiki/DocsProject/Tools/PDFconversion
>  
>  Having such a goal will give us a vision much greater than "just a doc 
>  on a subpage of our website". I believe that it's importance will be 
>  greater than the sum of the current's docs importance; for example, it 
>  could become something that the FreeMedia program could ship for free 
>  too, or ambassadors hand it (or parts of it) at events and we will have 
>  to have it ready by the release date. 
+1

>  One easy way to handle this would be the wiki, like the Beats with a
>
>  clear hierarchy that has cross-references between chapters. This way, we 
>  could monitor the changes and docs members could "maintain" chapters. If 
>  we go with the wiki-way, we can have people chip in here and there more 
>  easily. 
Yes and no.  Until we have a entirely Wiki front-end to DocBook, there
is some content that we are going to have to work on outside of the
Wiki.  The Installation Guide comes to mind here; converting it to the
Wiki losses much of the semantic markup, and since we'll have to convert
it back out eventually, I don't think it is worth the effort for the
small amount of additional contributions we'd get via the Wiki.

What we could look at doing is a "scratch" conversion, that is, make a
Wiki version of some of the XML content, then do a semi-manual
conversion of the content back into the XML in CVS.

Other content we may choose to have live on the Wiki as the source
content.

>  Some sample contents: 
I moved all this to the DocsProject/Handbook page to collaborate on it.

:) - Karsten

>     * Introduction
>       - The Fedora Project
>         + What is Fedora, FOSS, History
>         + Getting help, Communicating, Participating
>       - Packages
>       - Glossary (jargon-buster)
>     * Fedora Core 7: Tour, Release notes
>     * Installing Fedora Core
>     * Using Fedora's desktop
>     * System administration
>     * Tips and tricks
>     * FAQ
>  
>  And here are some more references:
>  
>     * TLDP guides [4]
>     * Old "Linux Manuals and Documentation" page [5]
>     * Gentoo Linux x86 Handbook [6]
>     * Debian GNU/Linux Desktop Survival Guide [7]
>  
>     [4]: http://tldp.org/guides.html
>     [5]: http://www.estart.co.za/linux_doc.html
>     [6]: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1
>     [7]: http://www.togaware.com/linux/survivor/
>  
>  
>  My 2 cents.
>  
>  -d
>  
>  
>  -- 
>  Dimitris Glezos
>  Jabber ID: glezos(a)jabber.org, PGP: 0xA5A04C3B
>  http://dimitris.glezos.com/
>  
>  "He who gives up functionality for ease of use
>  loses both and deserves neither." (Anonymous)
>  --
>   
-- 
Karsten Wade, RHCE, 108 Editor    ^     Fedora Documentation Project 
 Sr. Developer Relations Mgr.     |  fedoraproject.org/wiki/DocsProject
   quaid.108.redhat.com           |          gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

[cornel panceac]

i personally miss docs for: vpn (interaction wih m$), personal video
recording, authentication/integration of linux clients in active
directory, fedora directory server, getting  address book from
microsoft exchange, etc. also may be interesting one introduction to
linux using fedora. also introduction to programming (C, gtk, qt,
etc).

does all this look to you like the old linux cookbook using fedora?

what if: instead saving the tips and tricks in our email account or
elsewhere, we put them in one common place on fedoraproject.org?

2006/11/6, Karsten Wade <kwade(a)redhat.com&gt;:
>  We now have a small handful of regular documents to keep updated for
>  each release: release notes; Installation Guide; Desktop User Guide.  We
>  also have other documents that get occasional updates, when needed or
>  prodded.
>
>  Looking here:
>
>  http://fedoraproject.org/wiki/Docs/Drafts
>  http://fedora.redhat.com/docs
>  http://fedoraproject.org/wiki/Docs
>
>  What is missing?
>
>  * Do we need to divide into more help for new-to-Fedora users?
>  * Should we put more energy into focusing on systems administrators who
>  are new to Fedora and/or Linux?
>  * How about updating our own Documentation Guide?
>  * There are other guides such as the Packaging Guide and the Developers
>  Guide that could use updating or editing; do we want to adopt these and
>  begin a highly technical interaction with Fedora developers?
>
>  We have a nice influx of new writers, and I'm curious where we all think
>  we should go next.  Let's discuss. :)
>
>  - Karsten
>  --
>  Karsten Wade, RHCE, 108 Editor    ^     Fedora Documentation Project
>   Sr. Developer Relations Mgr.     |  fedoraproject.org/wiki/DocsProject
>     quaid.108.redhat.com           |          gpg key: AD0E0C41
>  ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
>
>
>  --
>  fedora-docs-list mailing list
>  fedora-docs-list(a)redhat.com
>  To unsubscribe:
>  https://www.redhat.com/mailman/listinfo/fedora-docs-list
>
>
>