The Great Content Migration

Mike McGrath mmcgrath at
Sun Dec 2 04:39:57 UTC 2007

Karsten Wade wrote:
> On Fri, 2007-11-30 at 16:35 -0600, Mike McGrath wrote:
>> (sent to both docs and websites, though not cross posted)
> OK, but I'm going to talk on this list and hope some of the right people
> are on here.  Maybe it belongs on f-websites-l?  I don't think we
> actually have any content that needs permanent moving from the wiki to
> docs.fp.o, so this is all just general websites stuff about

That could very well be, I guess I had just assumed you guys had content 
on the wiki but having thought about it you've had a pretty solid 
release / authoring procedure for a while now. I guess it's just the web 
team thats catching up :)

>> Now that F8 shipped and F9 is on the horizon, its time to look at moving 
>> some more of that content out of the wiki and either into 
>> and  This won't be a fun task.
>> Pros: 
>> 1) We'll have more control and process around the content that goes to 
>> these sites.  This allows us to make it more 'official'. 
>> 2) It will be more easily translatable. 
>> 3) Less reliance on Moin
>> Cons:
>> 1) It raises the barrier to create these pages
>> 2) It adds more process
>> 3) Its difficult to determine what content belongs where.
> It doesn't have to raise the barriers or add more process or be
> difficult, if we had a CMS.
> I'd like to see us running *two* instances of Plone.  The hacked up
> craziness for docs.fp.o that Jon is doing, and a straight-and-plain-Jane
> version for fp.o.
> Can we do that?

I think it will be very unlikely to have multiple instances of Plone 
(one for docs and one for the web team)

>> I've created an initial 
>> page for stuff thats 
>> in the wiki that is a good candidate for the static content.  
>> The trick 
>> here is that, and lets be honest, much of what is on the wiki right now 
>> is garbage.  
> In what sense?

Content duplication, multiple redirects, poor software on the backend 
for what we're doing, no integration with FAS, out-dated inaccurate 
information.  I guess when I look at the docs site I see good accurate 
information and when I go to the wiki (and when people come to me with 
links from the wiki) I often feel like some (not all) of the content 
just is old or otherwise inaccurate.  Either way, very little of it is 
for users and I can see a non-developer getting lost easily.

For example, the tours.  What's the clickstream supposed to be to get 

There's a lot of good content there, but its not linked to from anywhere 
on our site except beats AFAIK:  One thing 
I'd discussed with Max and Jesse on the phone once is getting reps from 
all the main groups together for a few meetings before we release.  This 
bit us this time around for a couple of things like sometimes calling it 
the "Gnome Desktop Spin" when in fact its just the "desktop spin". 

/me makes note to talk to John about that.
> I see a huge mix of items that are there because that has been the only
> place for putting non-source code content.  Meeting minutes, short
> how-tos, scratch notes, task lists, tables, process forms and templates,
> etc.  We could imagine replacing each of those items with a separate
> technology.  But they aren't really garbage, in the sense of being
> worthless.  They just belong somewhere else, ultimately.
That's a good point, I had thought fedorapeople would take some of this 
load off (and it has) but it does feel ill suited to many tasks (like 
meeting notes)
I'm not really concerned about size so much as target content.

>> What do you guys think?
> This is what I think we want to do:
> 1. Call the wiki "community documentation"; define that to mean:
>    - Very fluid
>    - Quality and consistency of writing not guaranteed
>    - Community needs to vet and police
>    - Good, simple procedures in place
>    - Every page needs an owner or the 'wiki police' are going to
> vaporize it

But who's the target audience for the wiki?  In the past its sort of 
been targeted for everyone but the content was mostly just for developers.

> 2. Move any content that does not fit that description into Plone for
> fp.o
>    - Still give projects/contributors appropriate access and control
>    - Content can have lifecycle (EOL, archiving, etc.)
>    - Information architecture is easier
> In addition, consider ...
> a. Running MediaWiki as the "community docs" wiki engine

We've looked into migrating to MediaWiki (I've considered migrating as 
well as just making Moin RO at some point and having people migrate the 
content manually.  Power in numbers :)  So far though both have 
initially seemed like a lot of work and I don't think any serious 
consideration / plan has been put together.

> b. Having Moin be the "docs wiki" that is used by the Fedora Docs
> writers and contributors for drafting content that is going to land in

Once Jon's Plone instance is up will you guys need a wiki anymore at all 
(for your actual docs workflow and stuff?)


More information about the docs mailing list