[Typo3-documentation] New item up for vote on DocumentTeam Meeting page

[Coby Pachmayr]

Sorry Coby, this might sound harsh and i am not the one who may judge
you but your postings are wasting a *lot* of time and i can´t see a lot
of sense in it. Actually its about building documentation for typo3 and
not about documentating yourself or your discussions or whatever.

- Johannes

<sarcasm on>Hmm... you're right... that didn't sound judgemental at
all!</sarcasm>

Here's a tip:  Don't read my posts.
Another tip:  Don't read my wiki writings
A final tip: Don't read the rest of this message

Okay... Johannes... (or anyone else) if you read the rest of this, you only
have you to blame! :-)

@ Everyone:

If everyone feels the same as Johannes, then I apologize for trying to
help... but everyone has the same choice... don't read my posts... how hard
is it to skip over them?  Don't click on links in the wiki. What's the
problem? In fact... stop reading now if you don't want to hear the rest of
what I say.  No need to respond if you don't have the time.  So I don't
think it is fair to blame me for *wasting* time.  I didn't realize that
everyone here was getting paid for their time!  Oh? They aren't?  Neither am
I.  Whatever time you think it has taken to read my posts, here or on the
Wiki... it has taken me considerably more time to write them.

All I have done was try to make a suggestion, that *I* think will help... if
you are too confused by it... then don't participate.  If you think it is
garbage, then don't participate.  If you don't want to read the Wiki... drop
me an e-mail and I'll go add your name to the "No" vote for you, and save
you some time.  Or better yet... do nothing... wouldn't that essentially be
a "no" vote?

I also apologize if this newsgroup was supposed to be *private*.  Silly
me... I thought it was an "open" newsgroup where people who wanted to work
on improving the documentation could volunteer their time.  I'm sorry if
some can't see that documentation has more to do with than "information on a
page".  A critical part of *quality* documentation is the implenentation of
the *controls* that go into producing the documentation.

I see *lots* of discussion about what documentation is needed... and *very*
little discussion about how to ensure that it is of quality.  Guess what --- 
there are no shortcuts... if you want *quality* then you have to put
*quality* effort into it.  If you want the same problems you have now...
keep doing it the same way.  If you think you have no problems with the way
it is now... well... then nothing I say matters to you anyway, so skip it.
End of story.

If you think that there are problems... then why not make a different
suggestion?  Or take my suggestion and modify it... isn't that what the
whole point of the Wiki is??

I have been posting and writing many things to make at least (3) critical
points... so here they are again:

(1) Documentation should not exist apart from the code... it should be a
*part* of the code.  Sofware is only as good as its documentation.  If the
docs are broken, then so is the software.  Software and Documentation
*should* be released together.  The programmer makes a spec sheet, the
technical writer begins writing.  The programmer updates the spec sheet, the
technical writer updates the document.  This process continues until both
are *released* ... you now have Software version X, and a manual for that
details Software version X.

(2) Any committee (the DocTeam is no exception) needs a methodology that
each member subscribes to for operating independently and with each other.
In a "virtual" committee where we are separated by geography, time zone,
language and culture this is even more critical.  It is also critcal that
the discussion *and* the decisions be documented so that others who are
particpating can easily see what has been discussed, decidided, voted on,
and implemented.  A committee may be democratic in its operation... but it
only works if each one voluntarily aheres to the rules... especially in this
group because nobody's job is danger if they choose not to do so.

(3) Currently this community does not subscribe to either #1 or #2.  The
result is a semi-organized chaos, where a great tool is severely limited by
lack of quality control... especially in the documentation.  People
initially think that structure and rules are "rigid" and "binding" ... but
in reality they are freeing... they release great power because clear
boundaries are set.  It is kind of like running... you can run forward with
your arms and legs wildly flailing to the sides... only bound by the
constraints of being attached to the body.  But if you put your arms, and
legs all working in the same direction, and close to the body... you
actually move faster and with less effort.  This is why athletes work on
"technique" because technique improves... right now... we have no
"technique".

I can offer up countless links (but of course you don't have time to click
on them) that support me on this.  These aren't just *my* opinions... these
are the way things are done... at least by those who prefer quality over
quantity.


-Coby-




>>What's the item that we vote for? The process of voting or what?
>>
>>You guys lost me.
>>
>>
>
>Yes.. Peter suggested that one of the first questions was "Should we use
>this method?"  So I actually decided to use his question as a way to
>demonstrate how it could work (which can be modified by anyone else who has
>any suggestions).
>
>I think it "looks" more confusing that it actually is... because I had to
>put a lot of descriptive text in to explain the idea.  But under the
>
>So under the heading "Agenda Items to Decide This Week" there are two
blocks
>which show basic formating (to demonstrate concept)... then below is an
>actual item (Peter's question) as an actual example.  But though it is an
>example... we can (if desired) "try" this process of voting... by voting on
>whether or not to use this process.
>
>It's kind of a recursive thing.
>
>I put all of the "instructions" (proposed) through out the process.  In
>other words, if you read through the Team Meeting Page, you will find the
>Agenda Items to Vote on and descriptions about that page and examples.
>
>If you click on the link "Should we use this method?" it will take you to
>page where you will see more information on voting for (or against) this
>item.
>
>Again, it's really harder to explain than use... but if you keep an open
>mind... and try it I think you will see it accomplishes the following:
>
>1.) It is an easy way to use the Wiki to discuss items to be decided
>
>2.) The structure will be very easy for others to catch-up / review all
past
>items that have been discussed in a quick and logical manner; because the
>very process "becomes" the document ... yet the document is separated from
>the discussion (like separating style from content)
>
>3.) It is democratic... but.... it also has a way to not just decide... but
>to follow up on what needs to be done.
>
>4.) Because it is democratic... even the very process itself can be
>modified... by using the process. (just like voting to change a country's
>constitution)
>
>If nobody likes it... then they won't use it.... and will essentially have
>"voted" through non-action.  After all it's just a suggestion... I'm just
>trying to resolve the problems of lots of conversation in the NG's without
>any easy way to "summarize" what has already been discussed, to clearly
>vote, then implement as well.  I'm open to anything that will help
>accomplish this.
>
>In fact... my 4 points above... will now be posted on the Discussion page
>for the question to be voted on... check it out! :-)
>
>
>
>_______________________________________________
>Typo3-project-documentation mailing list
>Typo3-project-documentation at lists.netfielders.de
>http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-project-document
ation
>
>
>