Discussion:
Zynot Documentation/Marketing Vision
Zach Welch
2003-06-28 23:47:41 UTC
Permalink
Zynot Documentation/Marketing Vision

= Documentation =

The success of this distribution will be around the successful
development of documentation suround all of its procedures. Don't forget
about that fabled goal of ISO certification; let that small kernel of an
idea just bury itself deep in your subconcious for now.

As you consider the potential scope of our undertaking, consider the
number of documentation writers it would take to keep up with Gentoo's
development team's changes.... Okay, so, you want to be a developer?
You will be writing documentation too, sorry, that's a necessity for an
embedded or enterprise solution. Let's get this started right:

The code is not done if the docs are not done, and that will prevent
products from being released on time unless proactively managed.

== Really, Documentation Is That Important ==

Unless you can draft a tech writer into the group along with you, I
will ask of every coder that desires to join to consider their own
language abilities and notate their wiki page with one or more of the
following documentation skills: transcriptionist, distiller, translator
(with the language you wish to translate), proof-reader, or editor.

In the future, I would encourage everyone to evangalize our distribution
with your company, school, or other organization. The documentation
team will need volunteers for tasks that do not require special
development skills, just the ability to read and write fluently. Coders
could be releive of documentation responsibilities after recruiting
sufficient additional personal to meet the needs of the project. For
those that have such options: Got Interns? :)

We have already had requests for translations into French and Danish,
and I have see the response ring out across the land. Translation team,
organize yourselves and report.

== Position Descriptions ==

Everyone needed immediately, to fill the following positions:

1) "transcriptionist" - Eventually, IRC bots might log our channels to
the wiki, and summarizing might be solved with AI algorithms. For the
short term, we need a bunch of people in front of their keyboards and
the core problem of transcribing can be addressed by copy and paste
magic.

2) "distiller" - Distill both my words and the words of others into
the wiki on a regular and timely basis, whether from forums, mailing
lists, or IRC. This requires judgement to discern the multifacet issue
of "trust" for each opinion being considered.

3) "translator" - We will want proof-readers to cover all translated
documents, ensuring that the meaning was not lost in translation.

4) "proof-reader" - make sure those words haven't been twisted any
more than they already were when lifted out of my (or others') e-mails.
Be cafeful to read for misinterpretations, clarify assumptions *before*
making them - question everything and everyone if there is doubt, you
will rarely ever be the only one with such doubt.

(Obvious spelling changes being an exception to this "rule" - until I
switch to using an MUA with a spell checker, I am my own dictionary.)
These people also function as fact checkers, ensuring that the clarity
of the message is being conveyed. This often will require in depth
knowledge of the actual material being reviewed.

5) "editor" - re-organize the wiki contents regularly, ensuring that
all of the content is being developed and extending in the right
directions. As effective "architects" of the wiki documentation. Given
the requirement to understand the broader implications of the project,
these roles will require both extensive trust and experience to fill.
Please provide suitable details on your wiki page.

There should be exponentially more personnel required for lower level
tasks, and function closer to the editor end of the spectrum will
require exponentially more experience required to hold those positions.

Calling all professionals, can we make this happen? Does this class
heirarchy seem sane? Remeber, here I am asking for the set of these
skills you believe you possess, not for you to choose one.

= Marketing and Branding =

== What's In A Name? ==

Okay, that gets to the name. For those that might be curious, there's
no hidden meaning to it. Even so, the "Zynot" theme has already begun
to take on a life of its own - as my above examples illustrate. I would
also like to point out that I did not come up with this name, I selected
quasi-random from a list of pseudo-random names presented to me.

Before things gets too out of hand, the community needs to decide
*immediately* if we are going to change the name, or choose to work with
Zynot. There were numerous request to change even before the project
was announce, but we must act decisively and rapidly as a whole - or
nothing can be done about it. Again, not everyone will like the name,
but really, what's in a name?

And 'shhh' to all you marketing folk that answer simply, "Everything."

== What Does Zynot Need? ==

The need for a "complete marketing package" is obvious, and I encourge
those interested in helping with the creation of suhc to create a page
on the wiki to organize this aspect of the foundation. Please provide
both examples of existing site for the community to view.

This will include a name, logo, and complete "brand image" including web
stylesheets, graphic art, etc. A couple of people have introduced
themselves as being capable of providing such services to the
Foundation, and I would love to take them up on that... just as soon as
I dig up their e-mails again. :)

This was just thrown together, somewhat, and I do not want to steal the
thunder of the newly forming doc team. Instead, I want this message to
serve as their rallying cry; post replies here with links to your plans
on the wiki for content layout, infrastructure development plans, etc..
Please keep things fairly high level for now; there will be time to
drive into the details later.

= Final Thought =

Let me know if I can further help organize these things, but I hope this
gives everyone intersted in the distribution a sense of the scope of
these aspects of the project.

Cheers,

Zach
Aaron Goldblatt
2003-06-29 01:20:03 UTC
Permalink
Post by Zach Welch
Zynot Documentation/Marketing Vision
First let me thank you for putting this semi-document together. I
personally don't have the skills to do development. I understand
enough of development concepts to be really dangerous, but I can help
do things like conceptual design and identify resources needed to
accomplish a given task.

My interest in joining the project has been looking toward
documentation.

A major downfall of every distribution I've ever messed with is a lack
of good documentation, especially in the area of troubleshooting guides
and technical problem resultion assistance.

Gentoo has a pretty straight-forward installation guide, but once
that's done, at least in terms of easy access for a new user, it seemed
to me to be catch-as-catch-can on IRC.

Debian's installation documentation is pretty good, but again,
explanation of things like networking configuration has always been
hard for me, and I'm someone who's relatively educated with respect to
Linux distributions.

I've bought the professional docs for things like RedHat and SuSE and
again, found them lacking for problems beyond initial simple
configuration. ISC's dhcpd, for example, has a plethora of options
that an intelligent administrator might find extremely useful, but I
had a hard time deciphering the man page. It shouldn't take me two
hours of trial and error with dhcpd.conf when a well written doc would
have helped me immensely.

For a well-packaged and professional distribution (which is a good
goal for a product meant for the professional world), fix docs are
vital to reduction of our support costs and the increase of the value
of our product to our customers.

We need documentation of APIs. We need documentation of install. We
need simplified and more complete documentation of common utilities,
the structure and execution of /etc/init.d, the order in which various
system services are brought up (both before and after init.d is run),
and how to manipulate and control those services effectively.

We could use a kernel compilation troubleshooting guide, because a
custom kernel is frequently vital to a custom implementation.
Especially with the new problems of gcc and kernel v2.4.19, a
comprehensible documentation consisting of more than just a Perl and
awk/sed script fix is well warranted and will go a long way toward
enhancing the respect with which our distribution will be viewed.

I'm ready to help find the places where we should start a ZDP, and help
identify what we should document first, and coordinate documentation
with development, because they go hand-in-hand.

ag
mark guertin
2003-06-29 01:27:14 UTC
Permalink
Excellent! I very much agree that we have to keep a close link between
these 2 projects, they are really in fact one 'metaproject' so to
speak.

Gerk
Post by Aaron Goldblatt
I'm ready to help find the places where we should start a ZDP, and help
identify what we should document first, and coordinate documentation
with development, because they go hand-in-hand.
jesse
2003-06-29 06:05:09 UTC
Permalink
I think also that there is a need to cross-polinate with the LDP docs.
If your gonna spend the time to make a dhcpd howto with more detial or
slanted towards the newbie ( or even towards the expierienced) then i
think making it in a way that can serve both the Zynot distro adn the
greater comunity is an important and corteous thing to do. This also
helps market our efforts here and attracts more ppl to the project IMHO.
tLDP has a huge ammount of docs, and I don't recall gentoo having ever
leveraged this.

That aside I think that another issue with documentaion in OSS is that
for many things theres good cursory or introductory documentation, but
te advanced topics dont get covered. It would be nice to sutup a rating
system or a system wheras you can select Beginner/intermediate/advanced
on certian high-volume topics or somthing to this effect.

Just some ideas :P
Post by mark guertin
Excellent! I very much agree that we have to keep a close link between
these 2 projects, they are really in fact one 'metaproject' so to
speak.
Gerk
Post by Aaron Goldblatt
I'm ready to help find the places where we should start a ZDP, and help
identify what we should document first, and coordinate documentation
with development, because they go hand-in-hand.
_______________________________________________
Zynaut mailing list
http://lists.zynot.org/mailman/listinfo/zynaut
Kevin Horn
2003-06-29 23:20:03 UTC
Permalink
Likewise, my development skills are not what you might call "polished", and
I would like very much to be involved in the documentation, administration,
and infrastructure facets of this project. I have "cast my hat into the
wiki" and hope to be doing some things there soon...

----- Original Message -----
From: "Aaron Goldblatt" <lists-***@goldblatt.net>
To: <***@lists.zynot.org>
Sent: Saturday, June 28, 2003 8:20 PM
Subject: Re: [zynaut] Zynot Documentation/Marketing Vision
Post by Aaron Goldblatt
Post by Zach Welch
Zynot Documentation/Marketing Vision
First let me thank you for putting this semi-document together. I
personally don't have the skills to do development. I understand
enough of development concepts to be really dangerous, but I can help
do things like conceptual design and identify resources needed to
accomplish a given task.
My interest in joining the project has been looking toward
documentation.
A major downfall of every distribution I've ever messed with is a lack
of good documentation, especially in the area of troubleshooting guides
and technical problem resultion assistance.
Gentoo has a pretty straight-forward installation guide, but once
that's done, at least in terms of easy access for a new user, it seemed
to me to be catch-as-catch-can on IRC.
Debian's installation documentation is pretty good, but again,
explanation of things like networking configuration has always been
hard for me, and I'm someone who's relatively educated with respect to
Linux distributions.
I've bought the professional docs for things like RedHat and SuSE and
again, found them lacking for problems beyond initial simple
configuration. ISC's dhcpd, for example, has a plethora of options
that an intelligent administrator might find extremely useful, but I
had a hard time deciphering the man page. It shouldn't take me two
hours of trial and error with dhcpd.conf when a well written doc would
have helped me immensely.
For a well-packaged and professional distribution (which is a good
goal for a product meant for the professional world), fix docs are
vital to reduction of our support costs and the increase of the value
of our product to our customers.
We need documentation of APIs. We need documentation of install. We
need simplified and more complete documentation of common utilities,
the structure and execution of /etc/init.d, the order in which various
system services are brought up (both before and after init.d is run),
and how to manipulate and control those services effectively.
We could use a kernel compilation troubleshooting guide, because a
custom kernel is frequently vital to a custom implementation.
Especially with the new problems of gcc and kernel v2.4.19, a
comprehensible documentation consisting of more than just a Perl and
awk/sed script fix is well warranted and will go a long way toward
enhancing the respect with which our distribution will be viewed.
I'm ready to help find the places where we should start a ZDP, and help
identify what we should document first, and coordinate documentation
with development, because they go hand-in-hand.
ag
_______________________________________________
Zynaut mailing list
http://lists.zynot.org/mailman/listinfo/zynaut
Loading...