We can create a 'requirements and tasks' list there for all of the
things that the documentation team is going to be involved in, however
I would suggest leaving the tooling up to the website team.
And I thought I WAS already a part of that web team (??)
OK how many goats I have to sacrifice to become a bona fide member?
Just listing the requirements means identifying the problem statement.
That alone is not enough, because it won't identify the documentation tools that satisfy those requirements.
Further, all authors would have to agree on common set of tools so that they can collaborate.
(Each author can not insist on using his own tool; otherwise there will be compatibility issues later.)
The choice of authoring tool should not be finalized based on the preference of a few early joiners.
It should be based on a thorough analysis and comparison of the available tools.
Since that conference call didn't materialize to finalize the authoring tool, then the next option is the website.
In fact, if Drupal itself has a powerful books module which can be export as viewable OR printable pdf.
Thus "website" and "documentation" are not isolated concepts.
In fact, regardless of the authoring tool chosen, the LibO website will execute the workflow partly or fully.
So the web team is very much a facilitator/enabler for the documentation team.
Therefore the web team and the documentation team would have to work together.
If people do have an attachment to a single tool then that is a
discussion for the people with that experience who will also be
developing the tool.
I don't know what you mean, but no one is going to develop any tool, right?
The authors will simply make use of an existing offline/online application or service.
Say, one of the options is for you to install the Drupal book module.
-Narayan