[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Your favorite CMS running docs.fedoraproject.org?

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

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

Attachment: pgpibeC6RC2tl.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]