Hello all.
As you may know, we ship a launcher called "Release Notes" in our default install. During the F18 Launcher Purge[1] Allan asked the docs team to remove it from the default install, but his request was rejected[2].
But now we have guidelines[3], and the guidelines state: * An "app" is an application as defined by the GNOME 3 HIG[4] * An app launcher SHOULD Launch software that is an actual app - see the GNOME 3 HIG for the exact definition
And the release notes, well, are not an app (per the definition in the GNOME 3 HIG).
Moreover, I don't really think users expect to find release notes inside the OS itself - no other OS does that.
We can link to the release notes in our download page, our help page on the website (which will be linked from start.fpo once I finish implementing the new designs we got), and a bookmark in Firefox (pointing to a local copy of the release notes) - so the release notes won't exactly be invisible or inaccessible.
We could also go the extra step (of craziness) and copy the release note PDF into the liveuser's Document directory (in the kickstart), where it will be indexed by tracker and thus accessible via documents and people who search for "release notes" in the shell would be able to find it (why would they do that? I don't know). It's possible, but for me it seems extremely crazy and unnecessary.
While I'm aware what I'm suggesting here might be a little bit controversial, I do think it is something which we should consider.
[1] https://fedoraproject.org/wiki/Design/F18_Launcher_Purge [2] https://bugzilla.redhat.com/show_bug.cgi?id=846316 [3] https://fedoraproject.org/wiki/User:Elad/Draft_app_guidelines [4] https://people.gnome.org/~tobiasmue/hig3/application-basics.html
----- Original Message -----
Hello all.
As you may know, we ship a launcher called "Release Notes" in our default install. During the F18 Launcher Purge[1] Allan asked the docs team to remove it from the default install, but his request was rejected[2].
But now we have guidelines[3], and the guidelines state:
- An "app" is an application as defined by the GNOME 3 HIG[4]
- An app launcher SHOULD Launch software that is an actual app - see
the GNOME 3 HIG for the exact definition
And the release notes, well, are not an app (per the definition in the GNOME 3 HIG).
Moreover, I don't really think users expect to find release notes inside the OS itself - no other OS does that.
We can link to the release notes in our download page, our help page on the website (which will be linked from start.fpo once I finish implementing the new designs we got), and a bookmark in Firefox (pointing to a local copy of the release notes) - so the release notes won't exactly be invisible or inaccessible.
Or it could simply be in Software, which is where software is.
On Fri, Aug 29, 2014 at 1:46 AM, Bastien Nocera bnocera@redhat.com wrote: [snip]
Or it could simply be in Software, which is where software is.
But this is documentation, not Software... it makes no sense to put it in Software from UX perspective. You don't go to the Android appstore to look for android documentation, right?
On Fri, Aug 29, 2014 at 12:50 AM, Elad Alfassa elad@fedoraproject.org wrote:
On Fri, Aug 29, 2014 at 1:46 AM, Bastien Nocera bnocera@redhat.com wrote: [snip]
Or it could simply be in Software, which is where software is.
But this is documentation, not Software... it makes no sense to put it in Software from UX perspective. You don't go to the Android appstore to look for android documentation, right?
But you still find plenty of books and manuals in the Google store.
Giovanni
On Fri, Aug 29, 2014 at 2:02 AM, Giovanni Campagna giocampagna92@gmail.com wrote:
On Fri, Aug 29, 2014 at 12:50 AM, Elad Alfassa elad@fedoraproject.org wrote:
On Fri, Aug 29, 2014 at 1:46 AM, Bastien Nocera bnocera@redhat.com wrote: [snip]
Or it could simply be in Software, which is where software is.
But this is documentation, not Software... it makes no sense to put it in Software from UX perspective. You don't go to the Android appstore to look for android documentation, right?
But you still find plenty of books and manuals in the Google store.
Giovanni
desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
Huh. So, well, as long as Release Notes is not a launcher we install by default, it might be okay to show it in Software... still a bit weird, but it could work. maybe.
On Fri, 2014-08-29 at 02:05 +0300, Elad Alfassa wrote:
On Fri, Aug 29, 2014 at 2:02 AM, Giovanni Campagna giocampagna92@gmail.com wrote:
On Fri, Aug 29, 2014 at 12:50 AM, Elad Alfassa elad@fedoraproject.org wrote:
On Fri, Aug 29, 2014 at 1:46 AM, Bastien Nocera bnocera@redhat.com wrote: [snip]
Or it could simply be in Software, which is where software is.
But this is documentation, not Software... it makes no sense to put it in Software from UX perspective. You don't go to the Android appstore to look for android documentation, right?
But you still find plenty of books and manuals in the Google store.
Giovanni
desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
Huh. So, well, as long as Release Notes is not a launcher we install by default, it might be okay to show it in Software... still a bit weird, but it could work. maybe.
It wouldn't be so weird if there were other books and manuals, maybe in a dedicated category, in Software.
On 29 Aug 2014 08:21, "Mathieu Bridon" bochecha@fedoraproject.org wrote:
Huh. So, well, as long as Release Notes is not a launcher we install by default, it might be okay to show it in Software... still a bit weird, but it could work. maybe.
It wouldn't be so weird if there were other books and manuals, maybe in a dedicated category, in Software.
Yeah, that was my thought too. Given there isn't such a category though, and if there was it would currently only contain the release notes, I'm not sure that Software is the right place for them.
R
On 29 August 2014 08:25, Richard Turner rjt@zygous.co.uk wrote:
Yeah, that was my thought too. Given there isn't such a category though, and if there was it would currently only contain the release notes, I'm not sure that Software is the right place for them.
Right, agreed.
Richard (gnome-software maintainer)
----- Original Message -----
On 29 August 2014 08:25, Richard Turner rjt@zygous.co.uk wrote:
Yeah, that was my thought too. Given there isn't such a category though, and if there was it would currently only contain the release notes, I'm not sure that Software is the right place for them.
Right, agreed.
Huh. You show the updates that were installed in the Updates panel. Showing something like that: http://www.engadget.com/2012/03/07/ios-5-1-update-now-rolling-out/ in it wouldn't be that much of a stretch.
It doesn't need to be the full release notes (in fact, I don't think that I would install the release notes package, not one with so much easily outdated data).
In the worst case, we could have that get added to the Details panel, we already show the OS version, we could link to the release notes for it.
----- Original Message -----
----- Original Message -----
On 29 August 2014 08:25, Richard Turner rjt@zygous.co.uk wrote:
Yeah, that was my thought too. Given there isn't such a category though, and if there was it would currently only contain the release notes, I'm not sure that Software is the right place for them.
Right, agreed.
Huh. You show the updates that were installed in the Updates panel. Showing something like that: http://www.engadget.com/2012/03/07/ios-5-1-update-now-rolling-out/ in it wouldn't be that much of a stretch.
It doesn't need to be the full release notes (in fact, I don't think that I would install the release notes package, not one with so much easily outdated data).
Well, not installing release notes package would even streamline release process (release notes are being worked on by the release but we have to make sure at least some up to date version is included in final compose). I'd say docs guys prefer web too - it's easy to publish docs to web, it's harder to release as package and maintain it. Let me check it with them.
Jaroslav
Before chiming in on this discussion, I figured I should look at what we actually ship as the release notes.
Here is what I get on f21 when trying to launch fedora-release-notes. $ gtk-launch fedora-release-notes.desktop gvfs-open: file:///usr/share/doc/fedora-release-notes-20/index.html: error opening location: Error when getting information for file '/usr/share/doc/fedora-release-notes-20/index.html': No such file or directory
I'm not easily discouraged, so I pointed manually at the right file: gvfs-open file:///usr/share/doc/fedora-release-notes/en-US/index.html
This succeeds in opening a web browser, with a page that reads:
This document provides the release notes for Fedora 19...
I think this nicely illustrates some of the downsides of locally installing frequently changing content, in particular if this is not the sole (or primary) means of publication:
It breaks, it gets outdated, and nobody notices.
Given this state of affairs, and the fact that we already bury the release notes launcher in the sundry folder, I think it would make a lot of sense to instead arrange for it to become pre-seeded content in documents, like the gnome-document getting-started guide is treated currently. If we do that, the release notes will still show up prominently in shell searches, thanks to the gnome-documents search provider.
Matthias
----- Original Message -----
Before chiming in on this discussion, I figured I should look at what we actually ship as the release notes.
Here is what I get on f21 when trying to launch fedora-release-notes. $ gtk-launch fedora-release-notes.desktop gvfs-open: file:///usr/share/doc/fedora-release-notes-20/index.html: error opening location: Error when getting information for file '/usr/share/doc/fedora-release-notes-20/index.html': No such file or directory
I'm not easily discouraged, so I pointed manually at the right file: gvfs-open file:///usr/share/doc/fedora-release-notes/en-US/index.html
This succeeds in opening a web browser, with a page that reads:
This document provides the release notes for Fedora 19...
I think this nicely illustrates some of the downsides of locally installing frequently changing content, in particular if this is not the sole (or primary) means of publication:
It breaks, it gets outdated, and nobody notices.
Given this state of affairs, and the fact that we already bury the release notes launcher in the sundry folder, I think it would make a lot of sense to instead arrange for it to become pre-seeded content in documents, like the gnome-document getting-started guide is treated currently. If we do that, the release notes will still show up prominently in shell searches, thanks to the gnome-documents search provider.
That seems like a good short-term solution, though we'd need it to be in PDF format instead of HTML as it is now.
Crazy idea, why don't we place it in GNOME Documents? Or as some sort of section in Help? Or why don't we provide a link from the default page on Firefox? I kind of agree with Elad that putting this in Software is kind of odd, I am certain that it wouldn't be the most obvious place for people to find this info. (In fact I think most people looking for this would just google for it, that's what I'd do).
On Fri, 2014-08-29 at 09:20 +0200, Mathieu Bridon wrote:
On Fri, 2014-08-29 at 02:05 +0300, Elad Alfassa wrote:
On Fri, Aug 29, 2014 at 2:02 AM, Giovanni Campagna giocampagna92@gmail.com wrote:
On Fri, Aug 29, 2014 at 12:50 AM, Elad Alfassa elad@fedoraproject.org wrote:
On Fri, Aug 29, 2014 at 1:46 AM, Bastien Nocera bnocera@redhat.com wrote: [snip]
Or it could simply be in Software, which is where software is.
But this is documentation, not Software... it makes no sense to put it in Software from UX perspective. You don't go to the Android appstore to look for android documentation, right?
But you still find plenty of books and manuals in the Google store.
Giovanni
desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
Huh. So, well, as long as Release Notes is not a launcher we install by default, it might be okay to show it in Software... still a bit weird, but it could work. maybe.
It wouldn't be so weird if there were other books and manuals, maybe in a dedicated category, in Software.
-- Mathieu
----- Original Message -----
On Fri, Aug 29, 2014 at 1:46 AM, Bastien Nocera bnocera@redhat.com wrote: [snip]
Or it could simply be in Software, which is where software is.
But this is documentation, not Software... it makes no sense to put it in Software from UX perspective. You don't go to the Android appstore to look for android documentation, right?
That's where you would go to see the software you've installed, and the latest upgrades you've made. I guess that the release notes for the major version of the OS you installed could be seen around there.
On Fri, 2014-08-29 at 00:05 +0300, Elad Alfassa wrote:
We can link to the release notes in our download page, our help page on the website (which will be linked from start.fpo once I finish implementing the new designs we got), and a bookmark in Firefox (pointing to a local copy of the release notes) - so the release notes won't exactly be invisible or inaccessible.
Any of these would be a good replacement for the release notes launcher. I'd rather our app launchers corresponded 1:1 with actual applications.
I think it makes perfect sense to drop the release notes into ~/Documents and remove the .desktop file.
R
On Fri, 2014-08-29 at 07:08 +0100, Richard Turner wrote:
I think it makes perfect sense to drop the release notes into ~/Documents and remove the .desktop file.
Yup. If you don't want them, you'll delete them. They're more useful than the weird sample music and video that Ubuntu puts in your home folder....
On Aug 28, 2014 3:05 PM, "Elad Alfassa" elad@fedoraproject.org wrote:
Hello all.
As you may know, we ship a launcher called "Release Notes" in our default install. During the F18 Launcher Purge[1] Allan asked the docs team to remove it from the default install, but his request was rejected[2].
But now we have guidelines[3], and the guidelines state:
- An "app" is an application as defined by the GNOME 3 HIG[4]
- An app launcher SHOULD Launch software that is an actual app - see
the GNOME 3 HIG for the exact definition
And the release notes, well, are not an app (per the definition in the GNOME 3 HIG).
Moreover, I don't really think users expect to find release notes inside the OS itself - no other OS does that.
We can link to the release notes in our download page, our help page on the website (which will be linked from start.fpo once I finish implementing the new designs we got), and a bookmark in Firefox (pointing to a local copy of the release notes) - so the release notes won't exactly be invisible or inaccessible.
We could also go the extra step (of craziness) and copy the release note PDF into the liveuser's Document directory (in the kickstart), where it will be indexed by tracker and thus accessible via documents and people who search for "release notes" in the shell would be able to find it (why would they do that? I don't know). It's possible, but for me it seems extremely crazy and unnecessary.
While I'm aware what I'm suggesting here might be a little bit controversial, I do think it is something which we should consider.
[1] https://fedoraproject.org/wiki/Design/F18_Launcher_Purge [2] https://bugzilla.redhat.com/show_bug.cgi?id=846316 [3] https://fedoraproject.org/wiki/User:Elad/Draft_app_guidelines [4] https://people.gnome.org/~tobiasmue/hig3/application-basics.html --
-Elad Alfassa.
This seems like [another] case of "we want to show all available desktop files without filters, but that looks cluttered, so all other packages should change so we don't have to add filters." I appreciate the work you're putting into the details on the default install, really, but as has often been pointed out it will be really easy to gain that clutter back with Software. Two things can change here; *all* packages shipping desktop files, or the *one* displaying them.
Okay, backseat developer hat off, docs hat on. Yeah, I'd like to be free of the fedora-release-notes RPM. It's a little extra work - really just a spec bump and rebuild at that stage - I wouldn't have to do.
That said, users *should* have Release Notes, by default, offline, and discoverable. Fedora changes a lot between releases, and I sincerely believe that taking the extra measures to expose users to this documentation helps alleviate frustration and prevents dissatisfaction when something doesn't work as expected. What seems obvious in context isn't always so apparent to those on the outside of your process. A measurable portion of users will look for the reasoning and recommended remedies for unexpected things they encounter.
Not everyone will simply think "oh, I can install that firewall config tool with Software, I'm just going to accept that and not question it or look for more information." Some will look for RNs, some will look for speculative forum posts, some will look for blog posts, and some will look for *you* to *personally justify* your actions. Our goal is to provide all of these people the information they need to understand the behavior they encounter and achieve the behavior they want. It's a service provided by the Docs team to both users *and* developers. The benefits outweigh the pain of having an icon that you aren't that interested in.
As a maintainer of that package, I'd welcome specific suggestions or requests to improve presentation.
--Pete
On Fri, Aug 29, 2014 at 4:09 PM, Pete Travis lists@petetravis.com wrote:
This seems like [another] case of "we want to show all available desktop files without filters, but that looks cluttered, so all other packages should change so we don't have to add filters." I appreciate the work you're putting into the details on the default install, really, but as has often been pointed out it will be really easy to gain that clutter back with Software. Two things can change here; *all* packages shipping desktop files, or the *one* displaying them.
If your criticism can't be constructive, don't say anything.
That said, users *should* have Release Notes, by default, offline, and discoverable. Fedora changes a lot between releases, and I sincerely believe that taking the extra measures to expose users to this documentation helps alleviate frustration and prevents dissatisfaction when something doesn't work as expected. What seems obvious in context isn't always so apparent to those on the outside of your process. A measurable portion of users will look for the reasoning and recommended remedies for unexpected things they encounter.
No other operation system comes with the release notes bundled with the OS. This is not really a thing users *expect*.
Not everyone will simply think "oh, I can install that firewall config tool with Software, I'm just going to accept that and not question it or look for more information." Some will look for RNs, some will look for speculative forum posts, some will look for blog posts, and some will look for *you* to *personally justify* your actions. Our goal is to provide all of these people the information they need to understand the behavior they encounter and achieve the behavior they want. It's a service provided by the Docs team to both users *and* developers. The benefits outweigh the pain of having an icon that you aren't that interested in.
I don't understand what's the problem with having the release notes available on the web and linked to in the download page and in the support page.
As a maintainer of that package, I'd welcome specific suggestions or requests to improve presentation.
Few options: * Instead of installing a launcher, make it available in gnome-documents or yelp. You can separate the launcher to a subpackage for desktops that don't care about the application model or having a consistent user experience. * Do nothing. We can exclude the release notes from the Workstation media. It will still be available in the web.
On 08/29/2014 07:26 AM, Elad Alfassa wrote:
On Fri, Aug 29, 2014 at 4:09 PM, Pete Travis lists@petetravis.com wrote:
This seems like [another] case of "we want to show all available desktop files without filters, but that looks cluttered, so all other packages should change so we don't have to add filters." I appreciate the work you're putting into the details on the default install, really, but as has often been pointed out it will be really easy to gain that clutter back with Software. Two things can change here; *all* packages shipping desktop files, or the *one* displaying them.
If your criticism can't be constructive, don't say anything.
Please stop proposing disruptive changes so late in the release cycle. We're into alpha freeze now, it isn't a good time to tweak things that touch release criteria.
Please take a collaborative approach to dealing with issues when they touch on other groups' products and priorities. I don't have a problem with the Workstation WG making their own choices, but your proposals affect others. Bring the discussion to stakeholders, we're not uncompromising about these things. If you leave other contributors out of the discussion, it leads to the inference that you are unhappy with their work, unwilling to voice your concerns or address them cooperatively, and are deliberately obfuscating controversial decisions in the hope that noone will notice and disagree with you. I don't think that's what is actually happening here, but you asked for constructive criticism...
That said, users *should* have Release Notes, by default, offline, and discoverable. Fedora changes a lot between releases, and I sincerely believe that taking the extra measures to expose users to this documentation helps alleviate frustration and prevents dissatisfaction when something doesn't work as expected. What seems obvious in context isn't always so apparent to those on the outside of your process. A measurable portion of users will look for the reasoning and recommended remedies for unexpected things they encounter.
No other operation system comes with the release notes bundled with the OS. This is not really a thing users *expect*.
Are we trying for parity with other operating systems? The point seems a bit non sequitur, but to address it directly: Fedora is different from other operating systems. The purpose of the Release Notes is to communicate that. There are a lot of complaints about unexpected behavior and confusion following each release in the support venues I monitor, so yes, I think the extra exposure really does help.
Not everyone will simply think "oh, I can install that firewall config tool with Software, I'm just going to accept that and not question it or look for more information." Some will look for RNs, some will look for speculative forum posts, some will look for blog posts, and some will look for *you* to *personally justify* your actions. Our goal is to provide all of these people the information they need to understand the behavior they encounter and achieve the behavior they want. It's a service provided by the Docs team to both users *and* developers. The benefits outweigh the pain of having an icon that you aren't that interested in.
I don't understand what's the problem with having the release notes available on the web and linked to in the download page and in the support page.
There's no problem with those things. More exposure is better - and remember, part of the goal here is to represent *your work* to your users. I want people who install Fedora Workstation to understand the design goals and purpose of Workstation, the features it offers, and how to use it.
As a maintainer of that package, I'd welcome specific suggestions or requests to improve presentation.
Few options:
- Instead of installing a launcher, make it available in
gnome-documents or yelp. You can separate the launcher to a subpackage for desktops that don't care about the application model or having a consistent user experience.
- Do nothing. We can exclude the release notes from the Workstation
media. It will still be available in the web.
I don't buy the idea that presenting users with documentation conflicts with a consistent user experience. If anything, presenting the Release Notes as a GNOME product rather than a Fedora product, but only in Workstation, is not consistent for this package.
Meanwhile... On 08/29/2014 07:30 AM, Matthias Clasen wrote:
Before chiming in on this discussion, I figured I should look at what we actually ship as the release notes.
Here is what I get on f21 when trying to launch fedora-release-notes. $ gtk-launch fedora-release-notes.desktop gvfs-open: file:///usr/share/doc/fedora-release-notes-20/index.html: error opening location: Error when getting information for file '/usr/share/doc/fedora-release-notes-20/index.html': No such file or directory
I'm not easily discouraged, so I pointed manually at the right file: gvfs-open file:///usr/share/doc/fedora-release-notes/en-US/index.html
This succeeds in opening a web browser, with a page that reads:
This document provides the release notes for Fedora 19...
Ugh... fair point. At this stage in the release cycle, we're still writing copy. I have a draft with 'this is a pre-release made for testing, please report bugs to bz and feature observations to docs' around somewhere to bridge the gap, and will add that to my list for this weekend.
I think this nicely illustrates some of the downsides of locally installing frequently changing content, in particular if this is not the sole (or primary) means of publication:
It breaks, it gets outdated, and nobody notices.
It changes *a lot* prior to GA. After that, it's minor corrections and translation updates. If we're talking about the efficacy of the copy itself, we could always use some help! Keeping track of Workstation alone has been difficult.
Given this state of affairs, and the fact that we already bury the release notes launcher in the sundry folder, I think it would make a lot of sense to instead arrange for it to become pre-seeded content in documents, like the gnome-document getting-started guide is treated currently. If we do that, the release notes will still show up prominently in shell searches, thanks to the gnome-documents search provider.
Matthias
Bastien replies with a note that PDFs are needed for this - we can do PDFs. How does this pre-seeding work in practice? How does having the documentation show up prominently in shell searches via this mechanism better align with the design goals of Workstation, as compared to the current implementation?
I'm not a WG member, so take these comments as you will.
On 2014-08-29 23:06, Pete Travis wrote:
On 08/29/2014 07:26 AM, Elad Alfassa wrote:
On Fri, Aug 29, 2014 at 4:09 PM, Pete Travis lists@petetravis.com wrote:
This seems like [another] case of "we want to show all available desktop files without filters, but that looks cluttered, so all other packages should change so we don't have to add filters." I appreciate the work you're putting into the details on the default install, really, but as has often been pointed out it will be really easy to gain that clutter back with Software. Two things can change here; *all* packages shipping desktop files, or the *one* displaying them.
If your criticism can't be constructive, don't say anything.
Please stop proposing disruptive changes so late in the release cycle. We're into alpha freeze now, it isn't a good time to tweak things that touch release criteria.
Maybe we can target Fedora 22 for this then if necessary. The original bug was raised about 2 years ago, it's not going anywhere..
Please take a collaborative approach to dealing with issues when they touch on other groups' products and priorities. I don't have a problem with the Workstation WG making their own choices, but your proposals affect others. Bring the discussion to stakeholders, we're not uncompromising about these things. If you leave other contributors out of the discussion, it leads to the inference that you are unhappy with their work, unwilling to voice your concerns or address them cooperatively, and are deliberately obfuscating controversial decisions in the hope that noone will notice and disagree with you. I don't think that's what is actually happening here, but you asked for constructive criticism...
This clearly goes both ways. The original bug was obviously discussed extensively by docs, with some rather impolite responses given to the original reporter, which is not particularly conducive for a re-engagement. Brigading on both sides is not constructive. This affects lots of people, most importantly the Fedora end users (such as everyone who is now rapidly trying to leave XP :)).
That said, users *should* have Release Notes, by default, offline, and discoverable. Fedora changes a lot between releases, and I sincerely believe that taking the extra measures to expose users to this documentation helps alleviate frustration and prevents dissatisfaction when something doesn't work as expected. What seems obvious in context isn't always so apparent to those on the outside of your process. A measurable portion of users will look for the reasoning and recommended remedies for unexpected things they encounter.
No other operation system comes with the release notes bundled with the OS. This is not really a thing users *expect*.
Are we trying for parity with other operating systems? The point seems a bit non sequitur, but to address it directly: Fedora is different from other operating systems. The purpose of the Release Notes is to communicate that. There are a lot of complaints about unexpected behavior and confusion following each release in the support venues I monitor, so yes, I think the extra exposure really does help.
You are complaining about introducing a non sequitur, but your answer seems to be that in order to help people find information about things Fedora does that are unconventional and unexpected we should continue to provide this information primarily by a method that is unconventional and unexpected. This seems like very faulty reasoning to me.
Release notes, however you wish to spin it are not an *application*. Talking about involving the relevant parties, have we had feedback from people on the Usability SIG as to whether it is confusing to have to look in Applications for something that is not an Application?
FWIW I genuinely had no idea Fedora 20 had a release notes item in the applications menu. I wasn't looking for it there. I'm unconvinced how helpful it is and the argument that 'it should be everywhere because then people will find it sooner or later' is pretty thin to me - it just starts to look messy.
If we want to highlight the release notes we put it in their home folder and maybe even look into how to make it open on first boot of Fedora. This is the logical place I feel. Personally I'd add it to their desktop but you have to add extensions to get that to happen in Gnome 3.
It is possible that we still have to fix GNOME Help and put it there instead (which feels like the best place to me), but dismissing removing the webpage shortcut from the applications list is not a reasonable position.
Not everyone will simply think "oh, I can install that firewall config tool with Software, I'm just going to accept that and not question it or look for more information." Some will look for RNs, some will look for speculative forum posts, some will look for blog posts, and some will look for *you* to *personally justify* your actions. Our goal is to provide all of these people the information they need to understand the behavior they encounter and achieve the behavior they want. It's a service provided by the Docs team to both users *and* developers. The benefits outweigh the pain of having an icon that you aren't that interested in.
I don't understand what's the problem with having the release notes available on the web and linked to in the download page and in the support page.
There's no problem with those things. More exposure is better - and remember, part of the goal here is to represent *your work* to your users. I want people who install Fedora Workstation to understand the design goals and purpose of Workstation, the features it offers, and how to use it.
As a maintainer of that package, I'd welcome specific suggestions or requests to improve presentation.
Few options:
- Instead of installing a launcher, make it available in
gnome-documents or yelp. You can separate the launcher to a subpackage for desktops that don't care about the application model or having a consistent user experience.
- Do nothing. We can exclude the release notes from the Workstation
media. It will still be available in the web.
I don't buy the idea that presenting users with documentation conflicts with a consistent user experience. If anything, presenting the Release Notes as a GNOME product rather than a Fedora product, but only in Workstation, is not consistent for this package.
I really hope we are talking about presenting users with documentation in a format that is appropriate for the GNOME environment, not whether we present it at all. Certainly all the focus in this thread has been about how to make it available in other ways.
Meanwhile... On 08/29/2014 07:30 AM, Matthias Clasen wrote:
Before chiming in on this discussion, I figured I should look at what we actually ship as the release notes.
Here is what I get on f21 when trying to launch fedora-release-notes. $ gtk-launch fedora-release-notes.desktop gvfs-open: file:///usr/share/doc/fedora-release-notes-20/index.html: error opening location: Error when getting information for file '/usr/share/doc/fedora-release-notes-20/index.html': No such file or directory
I'm not easily discouraged, so I pointed manually at the right file: gvfs-open file:///usr/share/doc/fedora-release-notes/en-US/index.html
This succeeds in opening a web browser, with a page that reads:
This document provides the release notes for Fedora 19...
Ugh... fair point. At this stage in the release cycle, we're still writing copy. I have a draft with 'this is a pre-release made for testing, please report bugs to bz and feature observations to docs' around somewhere to bridge the gap, and will add that to my list for this weekend.
I think this nicely illustrates some of the downsides of locally installing frequently changing content, in particular if this is not the sole (or primary) means of publication:
It breaks, it gets outdated, and nobody notices.
It changes *a lot* prior to GA. After that, it's minor corrections and translation updates. If we're talking about the efficacy of the copy itself, we could always use some help! Keeping track of Workstation alone has been difficult.
Given this state of affairs, and the fact that we already bury the release notes launcher in the sundry folder, I think it would make a lot of sense to instead arrange for it to become pre-seeded content in documents, like the gnome-document getting-started guide is treated currently. If we do that, the release notes will still show up prominently in shell searches, thanks to the gnome-documents search provider.
Matthias
Bastien replies with a note that PDFs are needed for this - we can do PDFs. How does this pre-seeding work in practice? How does having the documentation show up prominently in shell searches via this mechanism better align with the design goals of Workstation, as compared to the current implementation?
A search finds files and documents, as well as applications.
The Applications menu shows applications. I think there is a definite difference here. If Release Notes launched an application rather than a web page shortcut it might be debatable.
-- -- Pete Travis
- Fedora Docs Project Leader
- 'randomuser' on freenode
- immanetize@fedoraproject.org
Philip Whitehouse
On Sat, 2014-08-30 at 16:14 +0100, Philip Whitehouse wrote:
Maybe we can target Fedora 22 for this then if necessary. The original bug was raised about 2 years ago, it's not going anywhere..
I agree. It's not a big deal. Why not leave this be for now, and revisit after F22 is released?
Release notes, however you wish to spin it are not an *application*.
Yup.
Talking about involving the relevant parties, have we had feedback from people on the Usability SIG as to whether it is confusing to have to look in Applications for something that is not an Application?
No, but check out this draft of the upcoming HIG, which will be released next month: https://people.gnome.org/~tobiasmue/hig3/application-basics.html
In particular, this rule: "In GNOME 3, only software that conforms to these characteristics should install an application launcher."
On Sat, Aug 30, 2014 at 7:20 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Sat, 2014-08-30 at 16:14 +0100, Philip Whitehouse wrote:
Maybe we can target Fedora 22 for this then if necessary. The original bug was raised about 2 years ago, it's not going anywhere..
I agree. It's not a big deal. Why not leave this be for now, and revisit after F22 is released?
I really don't undertand why "not installing the release notes" is such a big change we need to wait for the next cycle to implement. It's really just a one line change. And if we want to install them but not provide a launcher (so they could be opened by a bookmark in Firefox) than I'd happily provide a patch to split the launcher to a subpackage.
-Elad Alfassa.
On Sat, Aug 30, 2014 at 6:22 PM, Elad Alfassa elad@fedoraproject.org wrote:
On Sat, Aug 30, 2014 at 7:20 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Sat, 2014-08-30 at 16:14 +0100, Philip Whitehouse wrote:
Maybe we can target Fedora 22 for this then if necessary. The original bug was raised about 2 years ago, it's not going anywhere..
I agree. It's not a big deal. Why not leave this be for now, and revisit after F22 is released?
I really don't undertand why "not installing the release notes" is such a big change we need to wait for the next cycle to implement. It's really just a one line change. And if we want to install them but not provide a launcher (so they could be opened by a bookmark in Firefox) than I'd happily provide a patch to split the launcher to a subpackage.
Yeah. Well I doubt that "release notes as a package" makes any sense.
When I want to read the release notes of Fedora (or anything else) I just Google "Fedora 20 release notes" or "Firefox 31 release notes" ... I do not expect it to be in some package and I am pretty sure most use the web version anyway.
On Sat, 2014-08-30 at 19:22 +0300, Elad Alfassa wrote:
I really don't undertand why "not installing the release notes" is such a big change we need to wait for the next cycle to implement. It's really just a one line change. And if we want to install them but not provide a launcher (so they could be opened by a bookmark in Firefox) than I'd happily provide a patch to split the launcher to a subpackage.
Eh, I'm just picking my battles here. A Release Notes launcher that starts Firefox is not good and we should get rid of it, but it's not very bad either and if the release notes people want another cycle to rethink how to present the release notes, well why not let them have it?
Another thing we could do is add it as a default web app. GNOME Software requires "epiphany-runtime" which is all of Epiphany except the desktop file, so that it can install and remove web apps. Well, why not make the release notes a web app -- then the release notes team gets to keep the desktop launcher, and we are happy since it's a real application.
On Sat, Aug 30, 2014 at 7:42 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
Eh, I'm just picking my battles here. A Release Notes launcher that starts Firefox is not good and we should get rid of it, but it's not very bad either and if the release notes people want another cycle to rethink how to present the release notes, well why not let them have it?
I don't get what's there to re-think, tbh, we *already* link to them in the website and we will continue to do so after the re-design as well. In fact, it would even be more prominent because the new start.fpo design will have a big "get help" link which would link to a help page which will include all the resources the user would need to get help, *including* documentation.
Another thing we could do is add it as a default web app. GNOME Software requires "epiphany-runtime" which is all of Epiphany except the desktop file, so that it can install and remove web apps. Well, why not make the release notes a web app -- then the release notes team gets to keep the desktop launcher, and we are happy since it's a real application.
Because the release notes are *not* an app. Not a web app and not a normal app. They are documentation. Web apps should conform with the same standards as regular apps.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/30/2014 10:42 AM, Michael Catanzaro wrote:
On Sat, 2014-08-30 at 19:22 +0300, Elad Alfassa wrote:
I really don't undertand why "not installing the release notes" is such a big change we need to wait for the next cycle to implement. It's really just a one line change. And if we want to install them but not provide a launcher (so they could be opened by a bookmark in Firefox) than I'd happily provide a patch to split the launcher to a subpackage.
Eh, I'm just picking my battles here. A Release Notes launcher that starts Firefox is not good and we should get rid of it, but it's not very bad either and if the release notes people want another cycle to rethink how to present the release notes, well why not let them have it?
Another thing we could do is add it as a default web app. GNOME Software requires "epiphany-runtime" which is all of Epiphany except the desktop file, so that it can install and remove web apps. Well, why not make the release notes a web app -- then the release notes team gets to keep the desktop launcher, and we are happy since it's a real application.
Someone had proposed that in #fedora-docs late yesterday, I like it. I'm working on some copy right now, and will go for an ephiphany web-app style presentation in GNOME for the next RPM.
For the record, the collaboration part of my arguments here are *far* more important to me than the actual inclusion of a Release Notes RPM. It's a valid discussion, and I would much rather start on that basis, instead of potentially missing a discussion about a design philosophy on a SIG list, then finding out about the impact when I learn that an RC isn't meeting release criteria because of my package.
- -- - -- Pete Travis - Fedora Docs Project Leader - 'randomuser' on freenode - immanetize@fedoraproject.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/30/2014 10:52 AM, Pete Travis wrote:
On 08/30/2014 10:42 AM, Michael Catanzaro wrote:
On Sat, 2014-08-30 at 19:22 +0300, Elad Alfassa wrote:
I really don't undertand why "not installing the release notes" is such a big change we need to wait for the next cycle to implement. It's really just a one line change. And if we want to install them but not provide a launcher (so they could be opened by a bookmark in Firefox) than I'd happily provide a patch to split the launcher to a subpackage.
Eh, I'm just picking my battles here. A Release Notes launcher that starts Firefox is not good and we should get rid of it, but it's not very bad either and if the release notes people want another cycle to rethink how to present the release notes, well why not let them have it?
Another thing we could do is add it as a default web app. GNOME Software requires "epiphany-runtime" which is all of Epiphany except the desktop file, so that it can install and remove web apps. Well, why not make the release notes a web app -- then the release notes team gets to keep the desktop launcher, and we are happy since it's a real application.
Someone had proposed that in #fedora-docs late yesterday, I like it.
I'm working on some copy right now, and will go for an ephiphany web-app style presentation in GNOME for the next RPM.
For the record, the collaboration part of my arguments here are *far*
more important to me than the actual inclusion of a Release Notes RPM. It's a valid discussion, and I would much rather start on that basis, instead of potentially missing a discussion about a design philosophy on a SIG list, then finding out about the impact when I learn that an RC isn't meeting release criteria because of my package.
There's a more native presentation in an RPM available at http://koji.fedoraproject.org/koji/buildinfo?buildID=573983 , or soon from an updates-testing mirror near you. What do you think? - -- - -- Pete Travis - Fedora Docs Project Leader - 'randomuser' on freenode - immanetize@fedoraproject.org
Pete, Release notes are not an app. They are documentation and should be presented as such. The change you just made has little to no benefit for us. Regardless to what desktop files you choose to install, according to the approved guidelines for applications and launchers in Fedora Workstation, launchers that launch things that are not apps should include the X-GNOME-Sundry in their desktop file. Please add this category as it is part of a mandatory policy for default launchers in Fedora Workstation.
Thanks,
Hi all,
On Fri, 29 Aug 2014 16:06:46 -0600 Pete Travis lists@petetravis.com wrote:
Given this state of affairs, and the fact that we already bury the release notes launcher in the sundry folder, I think it would make a lot of sense to instead arrange for it to become pre-seeded content in documents, like the gnome-document getting-started guide is treated currently. If we do that, the release notes will still show up prominently in shell searches, thanks to the gnome-documents search provider.
Matthias
Bastien replies with a note that PDFs are needed for this - we can do PDFs. How does this pre-seeding work in practice? How does having the documentation show up prominently in shell searches via this mechanism better align with the design goals of Workstation, as compared to the current implementation?
This is not new, it has been brought up before, also as part of the GNOME upstream discussions. Back in 2012, I put together some notes about possible ways to improve integration of our Publican-based, locally installed documents, such as the Fedora Release Notes, with the GNOME desktop:
https://wiki.gnome.org/Design/Apps/Help
(Scroll down to Comments, some parts of that page discuss an outdated yelp redesign proposal, which is quite irrelevant here.)
One idea was to use yelp to display the Release Notes. Also, we could prominently link to the Notes from the GNOME Help landing page, and also from the Getting Started tutorial that is shown to desktop users at first login.
What really got my interest was an idea to implement a new GNOME Shell search provider (https://bugzilla.gnome.org/show_bug.cgi?id=690058) that would integrate with Tracker to index locally installed docs (with the search possibly restricted to /usr/share/help/). Similarly to already indexed user documents in ~/Documents or personal contacts, users could then search for locally installed documentation, including the Release Notes, from within the Shell's Activities overview. This would allow for a far better (as in systematic) approach to finding files on the user's desktop, with a neat categorization in the Shell's search results as an added bonus.
I still like this idea, especially if we really want to continue shipping and installing the Release Notes locally.
Cheers, pk
----- Original Message ----- <snip>
What really got my interest was an idea to implement a new GNOME Shell search provider (https://bugzilla.gnome.org/show_bug.cgi?id=690058) that would integrate with Tracker to index locally installed docs (with the search possibly restricted to /usr/share/help/). Similarly to already indexed user documents in ~/Documents or personal contacts, users could then search for locally installed documentation, including the Release Notes, from within the Shell's Activities overview. This would allow for a far better (as in systematic) approach to finding files on the user's desktop, with a neat categorization in the Shell's search results as an added bonus.
Search providers are all backed by applications. What's the application to read the docs in /usr/share/help? What would be in there other than the release notes?
It would probably be better to have those docs be converted to something Yelp can read and integrated in the Help, at least for GNOME and for Workstation.
On Fri, Sep 5, 2014 at 7:21 AM, Bastien Nocera bnocera@redhat.com wrote:
Search providers are all backed by applications. What's the application to read the docs in /usr/share/help?
That would depend on the format, I think. A browser for HTML docs, evince for PDF, or Yelp for DocBook/Mallard.
It would probably be better to have those docs be converted to something Yelp can read and integrated in the Help, at least for GNOME and for Workstation.
The release notes, like most of the docs written the Docs team, are already written in DocBook, which Yelp handles just fine. The docs team can also easily convert them to PDF, HTML (multi-page), HTML (single-page), and even Markdown (with the latest release of the Publican tool). In short, I don't think conversion is a problem here -- we simply need to agree on what format(s) we want, and figure out the new workflow.
-- Jared Smith
On Fri, 2014-09-05 at 10:36 -0400, Jared K. Smith wrote:
A browser for HTML docs, evince for PDF, or Yelp for DocBook/Mallard.
I think a yelp search provider for searching /usr/share/help would maybe make sense....
The Web search provider is for Internet searches. (This isn't currently installed by default in Workstation, but it probably will be soon -- I just need to make it launch the user's default browser instead of Web/Epiphany.)
The Files search provider is for local documents of all file types, but it searches only your home directory. An evince search provider be undesirable since it'd be redundant with this.
On Fri, 5 Sep 2014 07:21:41 -0400 (EDT) Bastien Nocera bnocera@redhat.com wrote:
----- Original Message -----
<snip> > What really got my interest was an idea to implement a new GNOME Shell > search provider (https://bugzilla.gnome.org/show_bug.cgi?id=690058) that > would integrate with Tracker to index locally installed docs (with > the search possibly restricted to /usr/share/help/). Similarly to already > indexed user documents in ~/Documents or personal contacts, users could > then search for locally installed documentation, including the Release > Notes, from within the Shell's Activities overview. This would allow for a > far better (as in systematic) approach to finding files on the user's > desktop, with a neat categorization in the Shell's search results as an > added bonus.
Search providers are all backed by applications. What's the application to read the docs in /usr/share/help? What would be in there other than the release notes?
It could be gnome-documents as Matthias proposed if we choose to ship PDF instead of a bunch of HTML pages.
It could be yelp as it supports transforming DocBook/Mallard XML as well as viewing HTML pages. I just tested it and yelp works quite well:
$ yelp /usr/share/doc/fedora-release-notes/index.html
The right thing to do would probably be to move Release Notes from /usr/share/doc/ to /usr/share/help/. Indexing /usr/share/help/ would get users easy access to both downstream (Release Notes) as well as upstream documentation (GNOME Help, application help, GNOME System Admin Guide, etc.).
It would probably be better to have those docs be converted to something Yelp can read and integrated in the Help, at least for GNOME and for Workstation.
Yes, we could do integration in the GNOME Help. Few things would have to be figured out, though:
* Whether we want to do this integration upstream with the help of Mallard conditionals. We would probably need a new test token (http://projectmallard.org/if/1.0/tokens) for that implemented in yelp.
* Alternatively, we could create a downstream patch. Maintaining this and figuring out what to do with translations is not something I would personally want to do. ;)
Cheers, pk
On Fri, 2014-09-05 at 16:52 +0200, Petr Kovar wrote: \
It could be gnome-documents as Matthias proposed if we choose to ship PDF instead of a bunch of HTML pages.
It could be yelp as it supports transforming DocBook/Mallard XML as well as viewing HTML pages. I just tested it and yelp works quite well:
$ yelp /usr/share/doc/fedora-release-notes/index.html
I think all of these questions about formats and tools are a bit secondary though.
Having the release notes on the system really makes most sense if we actually make an effort to present them to the user when he would be most interested in seeing them - right after installation.
The current post-install workflow already launches yelp with the gnome-getting-started guide. Maybe that page can be expanded to include the release notes in some form ?
On Fri, Sep 05, 2014 at 03:12:04PM -0400, Matthias Clasen wrote:
Having the release notes on the system really makes most sense if we actually make an effort to present them to the user when he would be most interested in seeing them - right after installation.
The current post-install workflow already launches yelp with the gnome-getting-started guide. Maybe that page can be expanded to include the release notes in some form ?
Makes sense. And in the future, it would also be nice to have them nicely visible in the event of an upgrade from one Workstation release to the next — or even presented in some way when a release-to-release update is _available_.
On Fri, 05 Sep 2014 15:12:04 -0400 Matthias Clasen mclasen@redhat.com wrote:
On Fri, 2014-09-05 at 16:52 +0200, Petr Kovar wrote: \
It could be gnome-documents as Matthias proposed if we choose to ship PDF instead of a bunch of HTML pages.
It could be yelp as it supports transforming DocBook/Mallard XML as well as viewing HTML pages. I just tested it and yelp works quite well:
$ yelp /usr/share/doc/fedora-release-notes/index.html
I think all of these questions about formats and tools are a bit secondary though.
I agree that these are secondary as long as desktop users can find what they are looking for. Providing a docs search functionality would surely help with that need.
Having the release notes on the system really makes most sense if we actually make an effort to present them to the user when he would be most interested in seeing them - right after installation.
+1
The current post-install workflow already launches yelp with the gnome-getting-started guide. Maybe that page can be expanded to include the release notes in some form ?
Yes, this is something we can do. Assuming that we want to provide a link to the Release Notes from the GNOME Getting Started landing page, there are multiple ways to approach this. As I said, we could add the link upstream and use Mallard conditionals to only display the link on Fedora since the link is downstream-specific. We could also provide a downstream patch but translations would be a problem then.
GNOME Initial Setup could also get an extra button that would launch the Release Notes.
Cheers, pk
On Mon, 8 Sep 2014 19:50:49 +0200 Petr Kovar pkovar@redhat.com wrote:
On Fri, 05 Sep 2014 15:12:04 -0400 Matthias Clasen mclasen@redhat.com wrote:
On Fri, 2014-09-05 at 16:52 +0200, Petr Kovar wrote: \
It could be gnome-documents as Matthias proposed if we choose to ship PDF instead of a bunch of HTML pages.
It could be yelp as it supports transforming DocBook/Mallard XML as well as viewing HTML pages. I just tested it and yelp works quite well:
$ yelp /usr/share/doc/fedora-release-notes/index.html
I think all of these questions about formats and tools are a bit secondary though.
I agree that these are secondary as long as desktop users can find what they are looking for. Providing a docs search functionality would surely help with that need.
Having the release notes on the system really makes most sense if we actually make an effort to present them to the user when he would be most interested in seeing them - right after installation.
+1
The current post-install workflow already launches yelp with the gnome-getting-started guide. Maybe that page can be expanded to include the release notes in some form ?
Yes, this is something we can do. Assuming that we want to provide a link to the Release Notes from the GNOME Getting Started landing page, there are multiple ways to approach this. As I said, we could add the link upstream and use Mallard conditionals to only display the link on Fedora since the link is downstream-specific. We could also provide a downstream patch but translations would be a problem then.
I filed an upstream bug https://bugzilla.gnome.org/show_bug.cgi?id=736511 to track this change. Please leave your comments there.
Cheers, pk
Am Freitag, den 29.08.2014, 16:26 +0300 schrieb Elad Alfassa:
On Fri, Aug 29, 2014 at 4:09 PM, Pete Travis lists@petetravis.com wrote:
This seems like [another] case of "we want to show all available desktop files without filters, but that looks cluttered, so all other packages should change so we don't have to add filters." I appreciate the work you're putting into the details on the default install, really, but as has often been pointed out it will be really easy to gain that clutter back with Software. Two things can change here; *all* packages shipping desktop files, or the *one* displaying them.
If your criticism can't be constructive, don't say anything.
Actually I think this is a constructive statement.
Pete correctly pointed out that the activity view tends to be cluttered as it does not provide a filter mechanism. We now have folders, but we hardly make use of them yet.
Please try to look at the bigger picture. Do we want something that works in the default install or also on a poweruser's desktop with tons of applications installed? Do we want to limit ourselves or do we want a solution that scales?
I think we want the latter. I want the dash to look good everywhere. I want to be able to quickly find any app no matter how many apps are installed.
That said, users *should* have Release Notes, by default, offline, and discoverable. Fedora changes a lot between releases, and I sincerely believe that taking the extra measures to expose users to this documentation helps alleviate frustration and prevents dissatisfaction when something doesn't work as expected. What seems obvious in context isn't always so apparent to those on the outside of your process. A measurable portion of users will look for the reasoning and recommended remedies for unexpected things they encounter.
No other operation system comes with the release notes bundled with the OS. This is not really a thing users *expect*.
As mentioned earlier, comparing to other OSes is moot. We are talking about the expectations of *our* users, not other OS'es users.
Not everyone will simply think "oh, I can install that firewall config tool with Software, I'm just going to accept that and not question it or look for more information." Some will look for RNs, some will look for speculative forum posts, some will look for blog posts, and some will look for *you* to *personally justify* your actions. Our goal is to provide all of these people the information they need to understand the behavior they encounter and achieve the behavior they want. It's a service provided by the Docs team to both users *and* developers. The benefits outweigh the pain of having an icon that you aren't that interested in.
I don't understand what's the problem with having the release notes available on the web and linked to in the download page and in the support page.
Currently it would violate our final release criteria, see https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria#Release_note...
Note: I'm not saying we cannot adjust the release criteria, but if we change the workstation product, we must make sure the release criteria get updated, too.
As a maintainer of that package, I'd welcome specific suggestions or requests to improve presentation.
Few options:
- Instead of installing a launcher, make it available in
gnome-documents or yelp.
This will still result in less visibility, but sounds like a viable solution, at least for the workstation product.
You can separate the launcher to a subpackage
While this is technically possible, I consider it problematic. * A single file in a package means the rpm metadata is bigger then it's content. * If we have fedora-release-notes and fedora-release-notes-launcher, we cannot be sure the launcher actually gets installed. fedora-release-notes would need to contain the launcher and the release notes would have to become fedora-release-notes-data or -common. Highly confusing.
While I'm not a friend of it, I think that "NotShowin=GNOME;" would be the best technical solution. But it still does not solve the community aspect, that is the danger of devaluing the work of the docs team by no longer giving it the necessary visibility in our default product.
for desktops that don't care about the application model or having a consistent user experience.
Don't you see how biased your reasoning is? Just because other desktops do something different than your favorite desktop, that does not mean they "don't care" of have no "consistent user experience".
If you want all stakeholders to agree to your proposal, please try to convince them. Try to come up with a technically compelling solution and a convincing reasoning. With a biased reasoning you will convince nobody.
- Do nothing. We can exclude the release notes from the Workstation
media. It will still be available in the web.
Release criteria, see above.
Best regards, Christoph
On Aug 28, 2014, at 3:05 PM, Elad Alfassa elad@fedoraproject.org wrote:
Moreover, I don't really think users expect to find release notes inside the OS itself - no other OS does that.
Apple used to do this, but they don't anymore. I'm indifferent about release notes included. More valuable would be a wireless guide.
Chris Murphy
Am Freitag, den 29.08.2014, 00:05 +0300 schrieb Elad Alfassa:
Hello all.
HI Elad,
thanks for bringing this up.
As you may know, we ship a launcher called "Release Notes" in our default install. During the F18 Launcher Purge[1] Allan asked the docs team to remove it from the default install, but his request was rejected[2].
To me it looks like the removal was rejected for good reasons, In the bug, Robyn pointed out some important points, e. g. our release criteria.
If you disagree, please be so kind to respond these points and make sure the release criteria get updates accordingly.
But now we have guidelines[3], and the guidelines state:
I was under the impression that these guidelines were not ratified yet. Because of all the netspilts, we were not able to discuss them at full. Some of my questions were not answered and my concerns were not addressed. Last but not least, I did not have a chance to cast my vote.
- An "app" is an application as defined by the GNOME 3 HIG[4]
- An app launcher SHOULD Launch software that is an actual app - see
the GNOME 3 HIG for the exact definition
And the release notes, well, are not an app (per the definition in the GNOME 3 HIG).
The removal of the launcher from the package affects more than just GNOME or the workstation product. Therefor arguing with GNOME guidelines is moot.
Moreover, I don't really think users expect to find release notes inside the OS itself - no other OS does that.
Most of our users are not migrating from other OSes but are existing users. As they had release notes in the past, it is save to assume they expect them.
We can link to the release notes in our download page, our help page on the website (which will be linked from start.fpo once I finish implementing the new designs we got), and a bookmark in Firefox (pointing to a local copy of the release notes) - so the release notes won't exactly be invisible or inaccessible.
None of these sound compelling. * We cannot assume people actually download the ISO. As an ambassador, I distribute quite a number of media. * A bookmark in Firefox assumes people already are searching the web, otherwise they wouldn't start a browser. People who expect to find them locally will not do this.
I'm not saying the release notes need to be shipped with the OS itself. These days, a link to a website should be fine, if it is displayed prominently in the OS. That is not in the browser. Or are bookmarks searchable in the dash now?
We could also go the extra step (of craziness) and copy the release note PDF into the liveuser's Document directory (in the kickstart), where it will be indexed by tracker and thus accessible via documents and people who search for "release notes" in the shell would be able to find it (why would they do that? I don't know). It's possible, but for me it seems extremely crazy and unnecessary.
I wouldn't call it crazy, but it's definitely everything but elegant. * It will not help us with installs but only in live mode. * But in live mode, tracker should not be run.
But I wouldn't call it unnecessary either. I still believe there is a need for the release notes in a prominent location.
While I'm aware what I'm suggesting here might be a little bit controversial, I do think it is something which we should consider.
I read through this thread and I did consider your proposal. However I remain skeptic.
Before I can make a final decision, I need to be sure that all stakeholders were involved in this discussion and agreed to your proposal. This not only includes the other desktops but also the docs team. I'm afraid that their hard work is significantly degraded if we no longer ship or prominently show it in our default product.
I suggest we continue this discussion once the other groups signal they are fine with this change.
Best regards, Christoph
[1] https://fedoraproject.org/wiki/Design/F18_Launcher_Purge [2] https://bugzilla.redhat.com/show_bug.cgi?id=846316 [3] https://fedoraproject.org/wiki/User:Elad/Draft_app_guidelines [4] https://people.gnome.org/~tobiasmue/hig3/application-basics.html -- -Elad Alfassa.
On Tue, Sep 2, 2014 at 4:18 AM, Christoph Wickert christoph.wickert@gmail.com wrote:
Am Freitag, den 29.08.2014, 00:05 +0300 schrieb Elad Alfassa:
Hello all.
HI Elad,
thanks for bringing this up.
As you may know, we ship a launcher called "Release Notes" in our default install. During the F18 Launcher Purge[1] Allan asked the docs team to remove it from the default install, but his request was rejected[2].
To me it looks like the removal was rejected for good reasons, In the bug, Robyn pointed out some important points, e. g. our release criteria.
If you disagree, please be so kind to respond these points and make sure the release criteria get updates accordingly.
But now we have guidelines[3], and the guidelines state:
I was under the impression that these guidelines were not ratified yet. Because of all the netspilts, we were not able to discuss them at full. Some of my questions were not answered and my concerns were not addressed. Last but not least, I did not have a chance to cast my vote.
A vote was called for in the thread itself. It received 5 +1s so the guidelines passed. I'll be moving them under the main Workstation wiki page at some point this week.
josh
Hi all.
To clarify my opinion on this, my proposal is:
We drop the launcher. Main fedoraproject.org page will link to the release notes if it fits the design and website team's design. Release notes will also be linked from get.fpo and the Fedora help page (the help page will be linked to from basically everywhere).
In addition, in the first month after GA we will have a very prominent "news bar" saying Fedora 21 was released recently and people can download it or read the release notes, with appropriate links. After this month the link will stay but move to a less distracting location at the bottom of the page.
It will be *way* more visible than it is now, and we won't need to deal with the problematic launcher.
On Wed, 2014-09-03 at 19:00 +0300, Elad Alfassa wrote:
In addition, in the first month after GA we will have a very prominent "news bar" saying Fedora 21 was released recently and people can download it or read the release notes, with appropriate links. After this month the link will stay but move to a less distracting location at the bottom of the page.
It will be *way* more visible than it is now, and we won't need to deal with the problematic launcher.
This is a good idea.
Michael
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/03/2014 12:00 PM, Elad Alfassa wrote:
Hi all.
To clarify my opinion on this, my proposal is:
We drop the launcher. Main fedoraproject.org page will link to the release notes if it fits the design and website team's design. Release notes will also be linked from get.fpo and the Fedora help page (the help page will be linked to from basically everywhere).
In addition, in the first month after GA we will have a very prominent "news bar" saying Fedora 21 was released recently and people can download it or read the release notes, with appropriate links. After this month the link will stay but move to a less distracting location at the bottom of the page.
It will be *way* more visible than it is now, and we won't need to deal with the problematic launcher.
I think this is an elegant solution. Can you propose this to the Websites team and get their input?
On Wed, Sep 3, 2014 at 7:24 PM, Stephen Gallagher sgallagh@redhat.com wrote:
I think this is an elegant solution. Can you propose this to the Websites team and get their input?
Hi Stephen. I'm a websites team member and I'm the one who's going to implement the new start.fpo design, so It's more or less me who decides what will be there, since the websites team seems to act mostly as a meritocracy.
Also I want input on this from Christoph and the docs team to make sure it's an acceptable solution before I discuss this with the rest of the websites team.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/03/2014 01:29 PM, Elad Alfassa wrote:
On Wed, Sep 3, 2014 at 7:24 PM, Stephen Gallagher sgallagh@redhat.com wrote:
I think this is an elegant solution. Can you propose this to the Websites team and get their input?
Hi Stephen. I'm a websites team member and I'm the one who's going to implement the new start.fpo design, so It's more or less me who decides what will be there, since the websites team seems to act mostly as a meritocracy.
I didn't realize that. Thanks for doing this, then. As I said, I think this is an elegant solution.
Also I want input on this from Christoph and the docs team to make sure it's an acceptable solution before I discuss this with the rest of the websites team.
*nod*
desktop@lists.fedoraproject.org
-
Alberto Ruiz -
Bastien Nocera -
Chris Murphy -
Christoph Wickert -
drago01 -
Elad Alfassa -
Giovanni Campagna -
Jared K. Smith -
Jaroslav Reznik -
Josh Boyer -
Mathieu Bridon -
Matthew Miller -
Matthias Clasen -
Michael Catanzaro -
Pete Travis -
Petr Kovar -
Philip Whitehouse -
Richard Hughes -
Richard Turner -
Stephen Gallagher