The Great Content Migration

[Karsten Wade]

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
fedoraproject.org.

> 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 
> docs.fedoraproject.org and fedoraproject.org.  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've created an initial 
> http://fedoraproject.org/wiki/Websites/Removables page for stuff thats 
> in the wiki that is a good candidate for the static content.  

I'm not sure you can put anything on a list for docs.fp.o.  If there is
content in the wiki that is not in the Docs/Drafts/ namespace to be
worked on, that is where to put it.  From there it gets forked into XML.
None of that is permanently moved from the wiki because the wiki is the
drafting workspace for that content.

> The trick 
> here is that, and lets be honest, much of what is on the wiki right now 
> is garbage.  

In what sense?

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.

I would work on tackling each problem area.  Going after 'static and
formal content', such as you suggest, seems like a good one.

BTW, doing a search for 'a' in a title (pulls up about 1/2 of all pages)
shows a lot of content, but I would say a lot of it is actual content
with a purpose.  *Lots* of user pages.  Yeah, let's move those out to
fedorapeople.org, only use them for a personal wiki drafting namespace.

> This is especially true with regards to our end users.  I 
> think focus on fp.o should be on consolidation.  Users have short 
> attention spans, so less is more.  If we find the need to have a 
> higher-detail document, it should probably be in the docs realm and use 
> its processes.

The challenge is that we will see a huge drop-off of content management
from the general contributors if we force longer items off the wiki and
into Plone or XML.

> 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
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
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
XML

- Karsten
-- 
Karsten Wade, Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-docs-list/attachments/20071201/6433b6d8/attachment.sig>