Make a Fedora feature for F13
As a suggestion, consider making a feature page for 'Fedora-tour', and do it soonest to get on the Fedora 13 schedule. Details on how to make a feature page are at Features.
Reasons for doing this soonest:
- The Features page is commonly the central node for collaborating with other Fedora Project members, such as Marketing and the Docs Project.
- Being a formal feature for a specific release helps draw attention to the feature, which means additional testing, help, users, and so forth.
- The feature process is tracked by project manager within the Fedora release schedule. Having this attention and additional rigorous practice helps the feature be ready by a release.
A formal feature is not required for this idea to work. For example, you could skip the feature tracking and just write the application, package it up, then work on convincing the first-boot maintainer to offer 'Fedora-tour', get it linked from the default desktop, etc. Being a feature may make all of that easier, it gets more attention from other sub-projects, and increases the chance that 'Fedora-tour' is discussed in Fedora marketing/press release materials.
--Quaid 10:47, 26 November 2009 (UTC)
Thanks for chiming in, Karsten. I worried the F13 feature process would be pushing the schedule for this too quickly, but in retrospect this is exactly right - aim high, be as transparent and collaborative as possible, and see how much faster that can help you run. +1 to going on the Features page. Mel Chua 18:53, 26 November 2009 (UTC)
Make it easy for Fedora Marketing and Docs and others to contribute updated content
Even though you may not want the content to change very much between releases, it is likely that a small portion will change. If you want the help of, for example, the Fedora Docs and Marketing teams, you want to consider how to make it easy for them to edit and even update the content for the application.
For example, a specifically structured set of wiki pages could be created. When the pages were finished being edited by other Fedora sub-projects, they would be exported to XML or XHTML for pulling in to the application. (Probably best to handle translation files, PO/POT, from within the 'Fedora-tour' application build environment.)
Another idea is to use the CMS platform that Docs/Marketing is preparing to use, with an export to XML or XHTML.
--Quaid 10:47, 26 November 2009 (UTC)
IMO, for this to be maintainable with any degree of sanity, this requirement is a must; the lowest barrier you can create to editing the content source, the more likely you'll get help with it. (And the more likely various spins/translations/etc are to deploy customized versions of this app, which sounded like something you wanted last night.)
Think about what teams you'd like to edit/maintain the content (Docs and Marketing sound about right to me, perhaps Ambassadors and Spin maintainers as well?) and what tools they already use, and how edited content from those tools can be pulled into whatever final format you decide on (Karsten's "export to XML/XHTML" suggestion rephrased in a slightly more generalized manner). Right now it seems to me that the wiki is the place all these groups share, with zikula as another potential option once that launches (the CMS that Karsten mentioned above).
Eventually you'll want to get into a rhythm where you ask for content (or content edits) around the same time each release; to see how other projects do their timing on this, check out the F12 Marketing schedule and note how close to the various release days each milestone falls (alpha, beta, GA day).
You'll likely want a schedule like the one page release notes or the fedora tour page (which ended up being the same as one page release notes) for the first release or two you do this, but eventually you might want the schedule to be more like the one for in-depth feature profiles.
Mel Chua 19:03, 26 November 2009 (UTC)