From Fedora Project Wiki

Revision as of 10:32, 15 February 2010 by Subfusc (talk | contribs) (→‎PyQt)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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)


PyQt4 won't look out of place under GNOME at all, see QGtkStyle! I'd be more worried about space issues. The GNOME spin [1] currently doesn't ship Qt at all, so they also don't include liveusb-creator because it uses PyQt4. We ship it on the KDE spin.

I think what would really be nice is to have 2 versions of "Welcome to Fedora", one using PyGTK and showing the GNOME spin, to ship on the GNOME spin, and one using PyQt4, and even PyKDE4 for better integration, showcasing the KDE spin features, to ship on the KDE spin. The spins are very different at the level shown by such an introduction, so the introductions need to be different for them to make sense.

  1. I still refuse to call it the "Desktop spin" as it's not the only desktop spin we ship!

--Kkofler 00:24, 27 November 2009 (UTC)

If there is only resources to do one version, I strongly suggest PyQt as it gives the broadest reach, fitting in in Gnome/XFCE as cleanly as in KDE

--User:Pembo13:Arthur Pemberton 13:34. 28 November 2009 (UTC)

Actually we will be going for neither, and do it in pure clutter. Then we dont need to have this argument ;) --Subfusc 10:31, Feb 15 Jan 2010 (UTC)

Online screen casts

It would be good if such as welcome tool could pull appropriate screencast from a trusted Fedora source if an internet connection is available run.

I am not envisioning this as a core feature, but as a "after the tour" feature, pulling an index of tutorial/screencast description and thumbnails and presenting them to the user in a gallery view:

Adding software Removing software
Viewing your photos Playing your music
Getting Help Online