(sent to both docs and websites, though not cross posted)
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.
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. The trick here is that, and lets be honest, much of what is on the wiki right now is garbage. 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.
What do you guys think?
-Mike
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. The trick here is that, and lets be honest, much of what is on the wiki right now is garbage. 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.
I certainly agree, As of now a lot of documentation/stuff is spread on docs.fedoraprojet or the Wiki, No centralized structure.. Its definitely going to be a pain to centralize, manage with ACL, and integrate with current DocBook style documentation.
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:
- 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:
- It raises the barrier to create these pages
- It adds more process
- 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 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 fedoraproject.org.
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 docs.fedoraproject.org and fedoraproject.org. This won't be a fun task.
Pros:
- 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:
- It raises the barrier to create these pages
- It adds more process
- 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 http://fedoraproject.org/wiki/Websites/Removables 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 to: http://fedoraproject.org/wiki/Tours/Fedora8
There's a lot of good content there, but its not linked to from anywhere on our site except beats AFAIK: http://tinyurl.com/2glg9l 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:
- 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.
- 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 XML
Once Jon's Plone instance is up will you guys need a wiki anymore at all (for your actual docs workflow and stuff?)
-Mike
On Sat, 2007-12-01 at 22:39 -0600, Mike McGrath wrote:
Karsten Wade wrote:
On Fri, 2007-11-30 at 16:35 -0600, Mike McGrath wrote:
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:
- 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:
- It raises the barrier to create these pages
- It adds more process
- 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 am completely talking out of my sitting apparatus here, but isn't it possible for Jon's docs workflow to be applied to only some of the content of a Plone instance -- i.e. the stuff in a Docs-type namespace? In other words, everything else, like marketing pages, front page, etc. could be put through "normal" ("default"?) workflow. I have no idea if this is so; hopefully Jon can say for sure.
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.
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.
Biggest risk of the community contribution model -- it's easy to "fire and forget"... with the emphasis on the last half. I think everyone agrees the benefits outweigh the risk, but it does create maintenance needs.
For example, the tours. What's the clickstream supposed to be to get to: http://fedoraproject.org/wiki/Tours/Fedora8
Linked at the top of the release notes and the release announcement, ISTR.
There's a lot of good content there, but its not linked to from anywhere on our site except beats AFAIK: http://tinyurl.com/2glg9l 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.
Great idea, +1.
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.
That reminds me to point out that the user "personal" page content on the wiki is worthwhile to keep where it is. We can't assume every contributor is going to write his or her own HTML for fedorapeople.org if we want folks like artists, documentation writers, marketing people, and so forth to be attracted to work on the project. Those who are comfortable doing so can certainly choose their location and link as desired.
What do you guys think?
This is what I think we want to do:
- 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.
We have to strike a delicate balance in Fedora, because our distribution is fast-moving. New ideas are coming up all the time and it's too much work to ask contributors to do more than write up a quick wiki page. Having a function to alert users to stale pages of theirs -- pages that haven't been updated or visited in X months -- might help. Pages that seldom change might be better suited as official documentation, but it would depend on how tight the focus of the page is, to avoid jacking up the maintenance cost for trivia pages.
- 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 XML
Once Jon's Plone instance is up will you guys need a wiki anymore at all (for your actual docs workflow and stuff?)
Not really, I guess. We should also note that there are Plone modules available for wiki functionality if they're really needed, although honestly the Plone document writing tools are as easy and inviting as the wiki tools, only better. I have no idea what the ETA of the new workflow stuff is.
On Sun, 2007-12-02 at 12:16 -0500, Paul W. Frields wrote:
On Fri, 2007-11-30 at 16:35 -0600, Mike McGrath wrote:
I am completely talking out of my sitting apparatus here, but isn't it possible for Jon's docs workflow to be applied to only some of the content of a Plone instance -- i.e. the stuff in a Docs-type namespace? In other words, everything else, like marketing pages, front page, etc. could be put through "normal" ("default"?) workflow. I have no idea if this is so; hopefully Jon can say for sure.
I think you are right and I forgot this. Our custom workflow can be applied to just a section of the Plone install, and leave the standard workflow for the rest of the content.
Biggest risk of the community contribution model -- it's easy to "fire and forget"... with the emphasis on the last half. I think everyone agrees the benefits outweigh the risk, but it does create maintenance needs.
... and ...
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.
We have to strike a delicate balance in Fedora, because our distribution is fast-moving. New ideas are coming up all the time and it's too much work to ask contributors to do more than write up a quick wiki page. Having a function to alert users to stale pages of theirs -- pages that haven't been updated or visited in X months -- might help. Pages that seldom change might be better suited as official documentation, but it would depend on how tight the focus of the page is, to avoid jacking up the maintenance cost for trivia pages.
A big wiki really needs a team tasked to touching pages. One job is to decide if a page needs a maintainer (owner) and get that person to commit to it (put their name at the bottom as owner). Another is to fix inconsistencies in markup, format, etc. An important one is to create and maintain clickstreams that are useful on the front page and other sub-pages that are starting points (i.e., ProjectName/ namespaces.)
That reminds me to point out that the user "personal" page content on the wiki is worthwhile to keep where it is. We can't assume every contributor is going to write his or her own HTML for fedorapeople.org if we want folks like artists, documentation writers, marketing people, and so forth to be attracted to work on the project. Those who are comfortable doing so can certainly choose their location and link as desired.
Good point. The wiki isn't a bad place for this content.
Not really, I guess. We should also note that there are Plone modules available for wiki functionality if they're really needed, although honestly the Plone document writing tools are as easy and inviting as the wiki tools, only better. I have no idea what the ETA of the new workflow stuff is.
The part you aren't considering is that the Docs workflow is access controlled. Just anyone cannot drop in and work on it without going through the join-the-project steps. The wiki is different, culturally and programmatically.
I'd suspect that most on-team writers would stop using the wiki, but we still need to be open for contributions from the entirety of the Fedora Project in places such as Docs/Beats/.
The fact is, there are going to be some docs that will never leave the wiki because the subject matter expert doesn't want to work on it in another location. *Maybe* we can get them to work it as a normal workflow Plone document, but not likely to get that xhtml => xml-in-SCM that our custom workflow is for.
- Karsten
On Sun, 2007-12-02 at 10:19 -0800, Karsten Wade wrote:
On Sun, 2007-12-02 at 12:16 -0500, Paul W. Frields wrote:
Not really, I guess. We should also note that there are Plone modules available for wiki functionality if they're really needed, although honestly the Plone document writing tools are as easy and inviting as the wiki tools, only better. I have no idea what the ETA of the new workflow stuff is.
The part you aren't considering is that the Docs workflow is access controlled. Just anyone cannot drop in and work on it without going through the join-the-project steps. The wiki is different, culturally and programmatically.
I'd suspect that most on-team writers would stop using the wiki, but we still need to be open for contributions from the entirety of the Fedora Project in places such as Docs/Beats/.
The fact is, there are going to be some docs that will never leave the wiki because the subject matter expert doesn't want to work on it in another location. *Maybe* we can get them to work it as a normal workflow Plone document, but not likely to get that xhtml => xml-in-SCM that our custom workflow is for.
Is it possible, even with our workflow, to allow the community to edit something in Plone under Docs/Beats (or whatever namespace this becomes), without the changes immediately being published? This is a question to which maybe we don't know the answer. I would love someone Plone-knowledgeable to explain it without launching into undefined jargon.
On Sun, 2007-12-02 at 13:48 -0500, Paul W. Frields wrote:
Is it possible, even with our workflow, to allow the community to edit something in Plone under Docs/Beats (or whatever namespace this becomes), without the changes immediately being published?
Not sure if we would care about changes being immediately published to *Plone*, since it is a draft space anyway.
IIRC, publishing to CVS happens outside of Plone and is an event we trigger.
I believe there is a way we could get it working. It might mean having something that lives in the non-Docs workflow until it is 'done', then we move it into the Docs workflow.
- Karsten
On Sat, 2007-12-01 at 22:39 -0600, Mike McGrath wrote:
Karsten Wade wrote:
I think it will be very unlikely to have multiple instances of Plone (one for docs and one for the web team)
OK, this is probably just my ignorance of how Plone operates. I suppose our custom workflow just sits in a special space, and the regular Plone workflow can be applied to the rest of fedoraproject.org.
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.
...
I'm not really concerned about size so much as target content.
...
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.
Yep, this is the central question. Can we answer it? Is it for:
* Helper contributors writing/maintaining content for end-users (#fedora, fedora-list)?
* Project contributors tracking notes, processes, scratches, ideas, hacky workflow, hacky web forms, etc.?
* Administrators creating hacky processes, etc.?
* Content creators working on drafts and collaborating?
Maybe all that can continue to happen, but we only craft a clickstream for one audience.
If choosing that, I would seriously consider 'community docs for helper contributors.' That is, start to pull in all this helper docs that are all over the place into one place, and make them easy to find.
Then each ProjectName/ namespace would be responsible for it's *own* clickstream from the ProjectName and ProjectName/Join pages.
Once Jon's Plone instance is up will you guys need a wiki anymore at all (for your actual docs workflow and stuff?)
For a while most likely yes. If the WYSIWYG editor in Plone spurs adoption, maybe we'll be able to move e.g. the release notes beats entirely there. The challenge is, right now, we can encourage *all* contributors (with EditGroup) to easily contribute to the release notes. If we move that to a Plone space, we'll see that dry up.
- Karsten
-
Karsten Wade -
Mike McGrath -
Paul W. Frields -
Ruturaj