Paul W. Frields wrote:
On Tue, 2006-11-07 at 18:46 +0000, Dimitris Glezos wrote:
http://doc-book.sourceforge.net
I don't know if it's worth it (the customizing etc.), but it could be a
candidate to substitute the wiki <-> docbook conversion. It is written
in PHP, it uses xmltproc and friends, it seems to support multiple
languages, content approving, intermediate docbook-focused syntax (or
docbook). Last update was 1.5 year ago.
(1) PHP will, AFAICT, never be used on fedoraproject.org. The admins
have spoken.
(2) Even if (1) were not true, I'm not excited about diverting energy
that would be better spent on figuring out a Plone-based solution. Yes,
there are some Plone issues still being worked, like authentication, but
it's the future. Let's embrace it.
I know, but Paul, do we have the resources to build a Plone front-end
for DocBook from scratch? Don't want to sound pessimistic here, but this
might require a lot of work to "do it right".
Because there are always some parameters that will be tight, probably we
shouldn't abolish anything *completely* and probably do some compromises
at a point. For example (I don't know if this *is* feasible), but if we
do find the above project useful, we might be able to run PHP on a
separate XEN machine that handles just the admin/editing part of the
docs: `http://docs-admin.fedoraproject.org/`. Then this could be
exported to a live version on a production system.
Just throwing ideas here, because if we are going to collaboratively
write a book, we should start thinking it's maintainability. Not how to
write it, but how to maintain it.
> Let me go out on a limb here and make a suggestion: If anyone here is
> interested in furthering our next publishing platform -- LEARN PLONE!
> I don't mean say, "Yes, we should learn Plone." (Or worse yet, "Plone
> should be learned by someone.") I mean, "Learn Plone. Do it.
> DO IT."
OK, here is an idea to get this forward: Someone with knowledge of what
we have, what we need and how we need it (say, you or Karsten or Bob?)
write down on the wiki some ideas (UML-style) of what the Plone
solution/worflows might need, with decreasing importance/urgency. The
more detailed it is, the more motivating it will be for new members of
the Docs and Infrastructure team to jump in and try implementing
something on their installation of Plone at home. The wiki page for this is:
http://fedoraproject.org/wiki/DocsProject/PloneIssues
An example with details:
Given: Plone v.X, Python v.Y, Mercurial VCS with Docbook, ready-made
authentication framework from the Infrastructure project.
* State: We are looking an HTML-rendered page of a doc's page.
* Priority 1: Front-end to show live-rendered Docbook HTML
* P2: "Edit" buttons for each Docbook file.
* P3: "Edit" buttons in each section/paragraph, like Wikipedia ones.
* P3: Ability for admins to tag changes as "live" from the web.
* State: An editor sees a tree view of the whole Docbook titles (TOC).
* P1: Editors to be able to re-organize the structure: Eg. change a
section's parent section.
* P3: Ability to quickly edit the Docbook IDs of the sections (anchors).
...etc.
I could write something like this, based on the features of the
`doc-book.sf.net` software, but you guys know much better what we really
need to get this done.
Oh, and another issue to have in mind: If we *do* go for a 100% plone
solution, the tools might need a lot of work, probably too much for FC7
or even FC8. Correct me if I am wrong. :)
-d
--
Dimitris Glezos
Jabber ID: glezos@xxxxxxxxxx, PGP: 0xA5A04C3B
http://dimitris.glezos.com/
"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--
--
fedora-docs-list mailing list
fedora-docs-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-docs-list
