I'm ready, let's do this.
We need one CMS solution (for sanity sake), although >1 install might be OK(?), to cover:
* fedoraproject.org * docs.fedoraproject.org
We need to move some content from the wiki (Licensing/*, Legal/*, Packaging*) to the CMS.
Why a CMS? Read this:
http://iquaid.org/2008/08/13/why-and-where-fedora-needs-a-cms-solution/
Getting a CMS is a solution to a blocker for upgrading MediaWiki. The code we use for MW ACLs is not supported in the latest release, and our version is going out of security update support. By moving all content out of the wiki that needs ACLs, we don't have to have that code and upgrading is made possible. That also gets us to where we can use Nigel's localization setup.
Reportedly we'll get a speed improvement on the wiki without the HNP code. So sayeth Nigel. See #fedora-admin for details.
CMS must haves -------------- * Good security record * Proactive security mindedness of developer community * Flexible enough auth system to attach to FAS * RSS * ...
CMS should haves ---------------- * OpenID * WYSIWYG editor * ...
Have at it!
- Karsten
On 2008-08-13 04:01:35 PM, Karsten 'quaid' Wade wrote:
CMS must haves
- Good security record
- Proactive security mindedness of developer community
- Flexible enough auth system to attach to FAS
- RSS
* l10n that doesn't break the translator workflow
I know it's a very difficult requirement, but it's pretty much the single biggest difficulty that I've had with the website buildscript.
Also, Karsten probably has more on this, but I think the docs team could use some workflow/publishing features as well.
Thanks, Ricky
On Wed, 2008-08-13 at 16:01 -0700, Karsten 'quaid' Wade wrote:
I'm ready, let's do this.
We need one CMS solution (for sanity sake), although >1 install might
be
OK(?), to cover:
- fedoraproject.org
- docs.fedoraproject.org
We need to move some content from the wiki (Licensing/*, Legal/*, Packaging*) to the CMS.
Why a CMS? Read this:
http://iquaid.org/2008/08/13/why-and-where-fedora-needs-a-cms-solution/
Getting a CMS is a solution to a blocker for upgrading MediaWiki. The code we use for MW ACLs is not supported in the latest release, and
our
version is going out of security update support. By moving all
content
out of the wiki that needs ACLs, we don't have to have that code and upgrading is made possible. That also gets us to where we can use Nigel's localization setup.
Reportedly we'll get a speed improvement on the wiki without the HNP code. So sayeth Nigel. See #fedora-admin for details.
Okay, heres the run down, in a completely unscientific test (although nearly scientific), I found that Mediawiki+HNP makes the wiki THREE times slower.
Now the problems also are (with the current setup): 1. HNP does not support Mediawiki > 1.11.2 2. Per 1. we are locked into Mediawiki 1.11.2 3. Per 2, we won't have any security updates once Mediawiki 1.13.x comes out (anytime now) 4. We are limited in options for l10n content 5. With the current state of the Mediawiki codebase, it could be more desirable (imo) for us to work off SVN versions like Wikipedia etc do (they update the wiki every couple of days from SVN once it's been proven as working on the test wiki). 6. HNP is just slow, and the code is disgusting.
CMS must haves
- Good security record
- Proactive security mindedness of developer community
- Flexible enough auth system to attach to FAS
- RSS
- ...
CMS should haves
- OpenID
- WYSIWYG editor
- ...
Have at it!
That said... http://www.silverstripe.com looks rather nifty. Plus they are having a meetup in Auckland not too far from me, so if we are interested I'll pop along and say hi on behalf of Fedora :)
- Nigel
On 2008-08-13 04:01:35 PM, Karsten 'quaid' Wade wrote:
We need one CMS solution (for sanity sake), although >1 install might be OK(?), to cover:
- fedoraproject.org
- docs.fedoraproject.org
If you don't mind, I'd like to focus this discussion on docs.fedoraproject.org first - the way I see it, if a CMS won't work for docs, then it's not worth using it on fp.o (plus maintaining a completely separate setup for docs).
The one main requirement (featurewise) from fp.o would be not breaking translator workflows. What features/use cases does docs need/want?
Thanks, Ricky
On Thu, 2008-08-14 at 13:34 -0400, Ricky Zhou wrote:
On 2008-08-13 04:01:35 PM, Karsten 'quaid' Wade wrote:
We need one CMS solution (for sanity sake), although >1 install might be OK(?), to cover:
- fedoraproject.org
- docs.fedoraproject.org
If you don't mind, I'd like to focus this discussion on docs.fedoraproject.org first - the way I see it, if a CMS won't work for docs, then it's not worth using it on fp.o (plus maintaining a completely separate setup for docs).
The one main requirement (featurewise) from fp.o would be not breaking translator workflows. What features/use cases does docs need/want?
You are totally correct. My reason for jamming it together was to capture and move one-time the various ACL'd pages in the wiki. Another option we've discussed previously is to move them to e.g. Packaging: namespace. Then we have to re-jiggle the default search, etc. But it is far less disruptive.
Ideally we'd match or improve the l10n workflow, such as by kicking out PO files from the CMS in to Transifex.
- Karsten
On 2008-08-14 03:19:44 PM, Karsten 'quaid' Wade wrote:
You are totally correct. My reason for jamming it together was to capture and move one-time the various ACL'd pages in the wiki. Another option we've discussed previously is to move them to e.g. Packaging: namespace. Then we have to re-jiggle the default search, etc. But it is far less disruptive.
Ah, that makes sense - so we can add fine-grained ACLs to the list of stuff to want, then hopefully focus on docs's publishing workflow needs. I don't know if we want to move both at the same time, though. I'd *hate* to end up using anything for the website that docs would not end up using long term as well.
Either way, I'm just bringing this up in the context of finding good candidates. Just something to keep in mind when listing features that we'd want in a CMS.
Thanks, Ricky
On Friday 15 August 2008 08:19:44 Karsten 'quaid' Wade wrote:
On Thu, 2008-08-14 at 13:34 -0400, Ricky Zhou wrote:
On 2008-08-13 04:01:35 PM, Karsten 'quaid' Wade wrote:
We need one CMS solution (for sanity sake), although >1 install might be OK(?), to cover:
- fedoraproject.org
- docs.fedoraproject.org
If you don't mind, I'd like to focus this discussion on docs.fedoraproject.org first - the way I see it, if a CMS won't work for docs, then it's not worth using it on fp.o (plus maintaining a completely separate setup for docs).
The one main requirement (featurewise) from fp.o would be not breaking translator workflows. What features/use cases does docs need/want?
You are totally correct. My reason for jamming it together was to capture and move one-time the various ACL'd pages in the wiki. Another option we've discussed previously is to move them to e.g. Packaging: namespace. Then we have to re-jiggle the default search, etc. But it is far less disruptive.
Ideally we'd match or improve the l10n workflow, such as by kicking out PO files from the CMS in to Transifex.
It would be great if the l10n workflow doesn't break the authoring workflow as well. For example, if the CMS supports draft->review->$foo->publish workflows, to be able to ship the content for l10n only at certain stages, and have the workflow go back to a certain stage if a mistake/error is found in the source- language content by the translator... And also, it would be great for translators to have a 'review' step in the workflow for translated content before it is published, so that they can see translations in context.
These are not necessarily requirements, but would be very nice to have :)
cheers, asgeir
On Fri, 2008-08-15 at 11:57 +1000, Asgeir Frimannsson wrote:
These are not necessarily requirements, but would be very nice to have :)
+1 ... good additions, thanks.
- Karsten
websites@lists.fedoraproject.org