Your favorite CMS running docs.fedoraproject.org?

[Karsten Wade]

On Thu, Jan 15, 2009 at 07:59:17PM -0600, King InuYasha wrote:
> Yes, I would be willing to maintain the system if you guys wanted me to.

We also had some good discussions with you on IRC as follow-up.

> Also, I have answers for some of the items on the list just so that I could
> expand on my belief that Enano could get the job done.

I'll also reply to a few items inline:


> """""""""""""""
> * Good security record
> Enano has a good security record, it had few holes in it during its
> development period, and these were quickly spotted and plugged up nicely
> * Proactive, security minded developer community that is ...
> Enano was designed with security in mind, and the developer absolutely
> believes security is top priority
> * Highly responsive, especially to security issues
> The Developer will react VERY quickly to any security issues and fix them
> ASAP

Mike McGrath reminded me there are things we can do to mitigate
security risks, such as isolating the system, but I appreciate the
proactive security approach.

> * Flexible enough auth system to attach to FAS
> Possible. Enano 1.1.x-hg uses HMAC-SHA1 for password storage, and
> DiffieHellman + AES192 for password transmission (that is the whole
> backend). I'm not sure what FAS2 uses for auth system, but it will be likely
> that the auth system backend in Enano would be entirely rewritten for FAS2
> unless FAS2 were to adopt our system. Somehow, I doubt that Fedora would
> adopt OUR system for authentication :)

In IRC, we talked with Toshio for a few minutes.  IIRC, you were going
to look in to the JSON interface to FAS2.

> * L10n that doesn't break the translator workflow
> I have no idea what this means.
> * Output for Transifex (PO/POT)
> Could be done with a helper script according to the Developer.

These two are related.  All software and documentation in Fedora is
translated using PO/POT files.  Many translators use Transifex
(https://l10n.fedoraproject.org) to submit translations.  This
requires that the PO/POT files be put into a version control system.

However, all of that is worked out in advance of building for the
CMS.  We put active content in to projects on fedorahosted.org, where
the PO/POT files live.  The CMS mainly needs to take the rendered HTML
and PDFs (where the toolchain takes PO + XML and creates the
per-language versions of the build document.)  It also needs to keep
track of versions in some way, ideally the same version information
as the actual doc package.

> * Content workflow (write <=> edit => publish)
> No idea what this means.

In my mind, this is the core of what a CMS does.

It lets you create several groups:

* Writers -- can input content up to draft mode; drafts can be
  restricted from being publically viewable, or are shown as clearly
  drafts and not finished work.

* Editors -- can approve/disapprove content.  Some CMS workflows do
  not allow an editor to actually rewrite the content; their only
  choice is to push back to a writer or push ahead to publish.  I
  personally think we should have editors able to make changes in the
  writing; the Docs Project can make that decision.

* Publishers -- take content and push it live as either early-release
  drafts or final content.

People can fill one or more of these roles, even for the same
content.  The key is to make sure that a piece of content is not
published as complete without having an editor read and approve.
However, a team of people could share the effort -- one person writes
Chapter A, one writes Chapter B, and they edit each other's chapters.

> * Content expiration (automatic)
> Not sure, but I think this could be done through a plugin

The idea here is to be able to designate a piece of content as only
relevant for a version of Fedora, and when that version is EOL, the
content is marked as EOL/deprecated.  We don't want to make content
disappear; it remains useful to people who choose not to upgrade.  But
we want to make it clear that we are not supporting content from five
releases ago. :)

> * Multiple roles, e.g. writer, team lead, editor, publisher, managing editor
> Defintely. Group support is in Enano and through its ACLs it is possible to
> set the exact correct permissions for each group to suit its role

OK, and I presume the capabilities tie to the write/edit/publish paradigm.

> * Integrate with FAS
> I'm not sure of the integration points for FAS2 for Enano. It was actually
> because our efforts to get the Fedora Project to use Enano last summer that
> Enano now has Postgres support, so if FAS2 uses Postgres as a backend, it
> could be done through that. A method will have to be investigated.

Toshio specified in IRC that direct access to the db is not likely.

> * Handle making certain pages or content areas static/non-database driven,
> such as for scaling during times of heavy resource demand
> Can be done with adding a plugin

This may or may not matter; the last few releases have handled the
additional load with proxies and caching.  I put it in as a
requirement as a just-in-case feature.

- Karsten
-- 
Karsten 'quaid' Wade, Community Gardener
http://quaid.fedorapeople.org
AD0E0C41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090116/5e58e723/attachment.sig>