Bertrand Delacretaz wrote:
Le 26 oct. 04, à 21:56, Jorg Heymans a écrit :
Both, but many of us agree that the biggest problem now is accessibility
(both from the user's and from the writer's point of views) of the docs.
point taken, but i don't share that feeling. I trust my searching skills
Bertrand Delacretaz wrote:
Le 26 oct. 04, à 23:36, Helma van der Linden a écrit :
...G4. Make submitting documentation a more straight forward process.
I haven't yet looked at the ins and outs of the xdocs, but I know from
the times I tried to find the documentation in the checked out tree
that
...So we would have two separate instances of Cocoon (or Forrest).
One is the staging server, which is the head. The other is the
live site, which uses the current-docs tag...
Not necessarily two instances, could be one IMHO, with URLs selecting
either the relased docs or other tags (and
On 26 Oct 2004, at 20:46, Bertrand Delacretaz wrote:
So I cannot refrain from sharing this idea, although I have no code to
back it up yet...
Similarly, however not even _hinting_ that this is something I'd want
to push myself, your set of goals and techniques still somehow teased
me in doing a
Bertrand Delacretaz dijo:
Recent discussions here, along with David's ASF-wide documentation
staging and publishing post to infrastructure@ made me think about
this, in a there must be an easier way mood. I'm not ready to discuss
this on infrastructure@ though, it feels safer here ATM ;-)
Bertrand Delacretaz wrote:
Recent discussions here, along with David's ASF-wide documentation
staging and publishing post to infrastructure@ made me think about
this, in a there must be an easier way mood. I'm not ready to
discuss this on infrastructure@ though, it feels safer here ATM ;-)
To understand it right you do not want online editing, workflow,... right?
Sounds like a nice start for doco. Small, slim and lite. ;-)
thorsten
Antonio Gallardo escribió:
Bertrand Delacretaz dijo:
Recent discussions here, along with David's ASF-wide documentation
staging and publishing post to
Le 26 oct. 04, à 21:20, Upayavira a écrit :
...The thing you seem to have missed is the staging process. If I have
written an xdoc, I want to see that as HTML, on a staging server,
before I actually publish it. After all, the XML might not even be
valid, or there might be mistakes. I need to be
Le 26 oct. 04, à 21:23, Scherler, Thorsten a écrit :
To understand it right you do not want online editing, workflow,...
right?
Why not, but separating this concern from the publishing process makes
the problem easier to tackle IMHO.
-Bertrand
smime.p7s
Description: S/MIME cryptographic
Bertrand Delacretaz wrote:
GOALS
G1. Generate our docs and website dynamically, directly from the SVN
repository accessed over http
G2. Give access to older versions of the docs using standard SVN
mechanisms (tags etc)
G3. Index the latest version of the docs, including structured fields
Jorg Heymans wrote:
Bertrand Delacretaz wrote:
GOALS
G1. Generate our docs and website dynamically, directly from the SVN
repository accessed over http
G2. Give access to older versions of the docs using standard SVN
mechanisms (tags etc)
G3. Index the latest version of the docs, including
Bertrand Delacretaz wrote:
Le 26 oct. 04, à 21:20, Upayavira a écrit :
...The thing you seem to have missed is the staging process. If I
have written an xdoc, I want to see that as HTML, on a staging
server, before I actually publish it. After all, the XML might not
even be valid, or there
G3. Index the latest version of the docs, including structured fields
(keywords, target audience, components mentioned, etc), to implement
prepared queries (as links, simply) to improve our docs' accessibility
It seems a good occasion to provide a better LuceneTransformer
implementation for
Upayavira wrote:
GOALS
snip/
G4. Make submitting documentation a more straight forward process. I
haven't yet looked at the ins and outs of the xdocs, but I know from the
times I tried to find the documentation in the checked out tree that I
was unable to figure out how it worked.
TOOLS /
Jorg Heymans wrote:
2)Should any effort towards documentation ATM go into improving its
*quality* or improving its
{searchability|updateability|scaleability|auto-generateability}
WDYT?
Personally, I think that Cocoon has a lot of good documentation, but
poorly/inconsistently organised.
Upayavira wrote:
Bertrand Delacretaz wrote:
Upayavira a écrit :
...The thing you seem to have missed is the staging process. If I
have written an xdoc, I want to see that as HTML, on a staging
server, before I actually publish it. After all, the XML might not
even be valid,
As
Le 26 oct. 04, à 22:34, Upayavira a écrit :
...So you'd use HEAD or whatever to view the latest commit, and the
public would see the current-docs tag. That could work. But would we
want the HEAD to be password protected, or in some way hidden so that
it doesn't get regularly viewed when it
Le 26 oct. 04, à 22:56, Frédéric Glorieux a écrit :
...T2. Build an index with Lucene, triggered via SVN post-commit
hooks, uses a live Cocoon instance to generate an easy to index XML
document for Lucene. Include metadata fields as mentioned in G2
above, generated from (enhanced as compared to
18 matches
Mail list logo
