[Typo3-doc] Wiki people: who's on board now?

[Peter Kindström]

Hi Alex
> Maybe I am just used to asking for suggestions and guidance, then,
> receiving none, pressing on the way I know best until someone complains,
> then turning it back upon them, saying "I asked for comments and you did
> not speak up when directly asked. Now that the work is done, how would
> you do it better?" They usually shut up after that. Perhaps it's just a
> different way of interacting here in the US! :)

My idea was to do like that during this winter: Release my
"vision", ask everybody for comments (probably without getting
much comments) and then just start working!

But before I got the time, I changed my mind. I like doing
things that is useful for others, not only for myself. In this
case it felt more like doing it for my own sake and then I did
not feel like doing it anymore!
(Yes, I´m a little bit strange... :-) )

> I agree. However, as a page structure or name on t3.org changes over
> time, maintenance then becomes a priority for the wiki, rather than
> writing. My concern is less on what the role of each component is than
> integrating the components so that everything remains synchronised. We
> will need all of the current roles to be in the final documentation
> structure. How do we keep them always synched?

I think this will "always" be a problem. Because if you make
*one* framwork that takes care of all documentation/information
it will be so big that you have to maintain the framework
instead!  :-(


> There is a new
> project by the typo3.us team to make a new Learning TYPO3 package that
> guides a new user from having a blank HTML template all the way through
> to having a fully-running site in T3, including a sample set of
> extensions. People have suggested "including the MTB guide" or
> "including the dummy package", or including any number of other existing
> documentation because it contains a gem of information embedded within
> it. The Learning T3 package is going to instead take all of the good
> information and place it in one package rather than just include
> outdated existing documents. If this kind of thing can be done for most
> of the other information, we'd be in really great shape.

It sounds like you are going it the *completely wrong
direction!?* Are you really going to make yet another document
for this? And not delete any of the existing ones?

If so, you are just going to make it worse, because people get
yet another place to look for information. And I guess that much
of the information also will be redundant (can be found in more
than one document) - which is one of the problems today!

No, the way to go is something this:
- In some cases, split up a document into many smaller ones and
make each document have one clear subject.
- Eliminate redundant information - refer to other documents
instead.
- In some cases: Move information to other documents, so that it
have a clear subject.
- Look at the whole suite of documents and make each document
have thier own place like in a big jigsaw.
- THEN you can easily make any package you want: One for newbies
(with document A, B and C), one for admins (with A, C and D) and
one for Editors (just A) and so on!

But I really think this will not happen, because it is much
easier to make a new documents than restructuring the old ones.
And the more new documents you get, the harder will it be to
find information or try to structure information...  :-(

Look at installation manuals for an example:
 http://wiki.typo3.org/index.php/Getting_started
We have 15 different pages/documents about installing and
upgrading! It would not help much to make yet another one, would
it? Unless you delete some of the already existing one, of course.

In this case we should reduce the amount of documents to around
3-4. Then it would be easier to look for information (if you
can´t guess what document to read by its title, you have at
least only 4 documents to read, not 15 like today!).


> Hopefully all our dicussions may attract more people to say
> "I'll help out!" :)

Yes, but you attract them more if you have a clear goal with the
documentation and then split the work up in many smaller
projects - but I think you know that already!  ;-)


/Peter Kindström