Long and "advertising" descriptions (was: Fedora 8 Update: enlightenment-0.16.999.043-3.fc8)
Hi all!
just noticed this:
On 14.09.2008 08:51, updates@fedoraproject.org wrote:
Fedora Update Notification FEDORA-2008-8052 2008-09-13 04:56:07
Name : enlightenment Product : Fedora 8 Version : 0.16.999.043 Release : 3.fc8 URL : http://enlightenment.org/p.php?p=about/e17&l=en Summary : Enlightenment DR17 - a next generation desktop shell Description : Enlightenment 0.17 is the next generation of UNIX graphical environments. It is not just a window manager, but it is also a desktop shell. A desktop shell means, a window manager plus a file manager, plus configuration utilitys all in one. They are not separated as usual.
Enlightenment is fast. No, really. It's fast. It is known to run on very slow machines (like 100 Mhz CPU, 64 MB of RAM) well. So you really don't need a modern desktop to see some eye-candy and to use a modern graphical environment. Even more – you can control how fast you want it by using it's Performance configuration panel to change the cache settings and more.
The high performance does not mean that there is no eye candy. There is eye candy that you have never seen before. Starting from the animated boot screen, to continue with the all animations and effects that themes could provide, to end up with fancy animated backgrounds. But not some huge .GIF files, but really nice animations. Every virtual desktop (at the moment you can have 24) can have it's own background (animated or not), so you can put different wallpapers on the different virtual desktops. There are a number of effects that can be shown when you switch from the different virtual desktops. The menus, the borders and all other usual parts of a normal window manager are animated as well as some of the widgets (the sliders, for example). Remember that those effects are provided by the theme, so every theme makes E to look different, with different effects, look and feel and animations.
As we already mentioned, E17 provides a file manager as well. Of the time of writing, it is not completed and is in active development (as E17 as a whole itself), but after it is finished it will be a very nice, configurable and eye candy. Even right now, you can do the basic things with it – browse, copy, move, delete files. It will provide thumbnails for your pictures and will be able to open your files with the coresponding application of your choice.
E17 is highly configurable. Currently it has a nice configuration panel with dialogs for all kinds of things. You can change your wallpaper or your theme, your fonts, your screen resolution, your screen's power settings, your keyboard and mouse settings, the language that Enlightenment talks to you, and so on. You can contol almost every apsect of what E is doing and how. It will do what you want it to do.
As you already know, Enlightenment 0.17 has lots of features, but one of the most important is, that you can add and remove functionality by using modules. Modules are small applications that extend E17. There can be modules tho show you the weather outside, or calendar modules, or modules to control your volume or whatever you may think. Developing a module is not that hard, so, if you have programming skills, you are more than welcome to develop and maintain some modules for the community.
Wow, that's a really long description.
(1) Is that really needed? Do we want that? I tend to say "no" -- a description with maybe 10, 15 or 20 lines with 80 chars per line should be enough, as everything else often takes way to much time to read for the user and thus it in the end might be more confusing and time-wasting than helpful.
(2) Quoting some things from above description again:
Enlightenment 0.17 is the next generation of UNIX graphical environments. [...] Enlightenment is fast. No, really. It's fast.[...] [...]after it is finished it will be a very nice, configurable and eye candy.[...]
Yes, I know, enlightenment is designed for small machines and quite fast on them. But those things I quoted and other sections in the description sound more like advertising than a proper description. Up to a specific point that's okay IMHO, but here the packager IMHO shoot way over the top.
Note: both things are not that important. But I found them odd and thought it might be a good idea to might bring them up here.
CU knurd
P.S.: Review bug for enlightenment: https://bugzilla.redhat.com/show_bug.cgi?id=448337
P.P.S.: Nice to finally see Enlightenment in Fedora :-)
On Sun, 2008-09-14 at 10:36 +0200, Thorsten Leemhuis wrote:
Yes, I know, enlightenment is designed for small machines and quite fast on them. But those things I quoted and other sections in the description sound more like advertising than a proper description. Up to a specific point that's okay IMHO, but here the packager IMHO shoot way over the top.
Wow. That is indeed too much information. :) I'm not sure how we should "guideline" that, other than something like:
== Descriptions == Your package description should contain useful data about the package, and answer the question "what is this and what does it do?". In general, the description should not exceed 10 lines or so. Try not to put too much here, this isn't an epic novel, it's just a package description. Also, there is no real need to "advertise" the package here, so statements like "this is the best perl module that has ever been created by humans", while possibly accurate, are not terribly useful in answering the question "what is this and what does it do?".
OT: Would an Enlightenment spin of Fedora be called "Eedora"? What about an eepc Enlightenment spin? Eeeedora? ;)
~spot
On Sunday, 14 September 2008 at 15:35, Tom spot Callaway wrote:
On Sun, 2008-09-14 at 10:36 +0200, Thorsten Leemhuis wrote:
Yes, I know, enlightenment is designed for small machines and quite fast on them. But those things I quoted and other sections in the description sound more like advertising than a proper description. Up to a specific point that's okay IMHO, but here the packager IMHO shoot way over the top.
Wow. That is indeed too much information. :) I'm not sure how we should "guideline" that, other than something like:
== Descriptions == Your package description should contain useful data about the package, and answer the question "what is this and what does it do?". In general, the description should not exceed 10 lines or so. Try not to put too much here, this isn't an epic novel, it's just a package description. Also, there is no real need to "advertise" the package here, so statements like "this is the best perl module that has ever been created by humans", while possibly accurate, are not terribly useful in answering the question "what is this and what does it do?".
+1
OT: Would an Enlightenment spin of Fedora be called "Eedora"? What about an eepc Enlightenment spin? Eeeedora? ;)
E^4dora? ;)
Regards, R.
On Sun, 14 Sep 2008 09:35:06 -0400, Tom "spot" Callaway wrote:
On Sun, 2008-09-14 at 10:36 +0200, Thorsten Leemhuis wrote:
Yes, I know, enlightenment is designed for small machines and quite fast on them. But those things I quoted and other sections in the description sound more like advertising than a proper description. Up to a specific point that's okay IMHO, but here the packager IMHO shoot way over the top.
Wow. That is indeed too much information. :) I'm not sure how we should "guideline" that, other than something like:
== Descriptions == Your package description should contain useful data about the package, and answer the question "what is this and what does it do?". In general, the description should not exceed 10 lines or so. Try not to put too much here, this isn't an epic novel, it's just a package description. Also, there is no real need to "advertise" the package here, so statements like "this is the best perl module that has ever been created by humans", while possibly accurate, are not terribly useful in answering the question "what is this and what does it do?".
I think these types of "advertising" and/or packager's notes are better put into /usr/share/doc/package/README.RPM or similar. Maybe just an additional sentence that packager's can stick extra additional info there. Packagers already do this.
zing
On 14.09.2008 15:35, Tom "spot" Callaway wrote:
On Sun, 2008-09-14 at 10:36 +0200, Thorsten Leemhuis wrote:
Yes, I know, enlightenment is designed for small machines and quite fast on them. But those things I quoted and other sections in the description sound more like advertising than a proper description. Up to a specific point that's okay IMHO, but here the packager IMHO shoot way over the top.
Wow. That is indeed too much information. :) I'm not sure how we should "guideline" that, other than something like:
== Descriptions == Your package description should contain useful data about the package, and answer the question "what is this and what does it do?". In general, the description should not exceed 10 lines or so. Try not to put too much here, this isn't an epic novel, it's just a package description. Also, there is no real need to "advertise" the package here, so statements like "this is the best perl module that has ever been created by humans", while possibly accurate, are not terribly useful in answering the question "what is this and what does it do?".
Sounds good. Not sure, but maybe it's possible to write it a bit shorter to work against the "guidelines grow and grow" trend (¹). Maybe something like this is enough:
""" The description should not be exceed round about ten lines of text and contain useful data about what the packaged software does. The description should be written from a distance point of view and not sound like advertising. """
I suppose a native English speaker is able to write it more clear in less words.
CU knurd
(¹) -- heck, maybe this should not be in the guidelines at all; maybe a new "best practices" document might be a better place for this and similar things, as "description not to long, no advertising style" is obvious to round about 99 percent of our packagers...
On Mon, 2008-09-15 at 13:53 +0200, Thorsten Leemhuis wrote:
On 14.09.2008 15:35, Tom "spot" Callaway wrote:
On Sun, 2008-09-14 at 10:36 +0200, Thorsten Leemhuis wrote:
Yes, I know, enlightenment is designed for small machines and quite fast on them. But those things I quoted and other sections in the description sound more like advertising than a proper description. Up to a specific point that's okay IMHO, but here the packager IMHO shoot way over the top.
Wow. That is indeed too much information. :) I'm not sure how we should "guideline" that, other than something like:
== Descriptions == Your package description should contain useful data about the package, and answer the question "what is this and what does it do?". In general, the description should not exceed 10 lines or so. Try not to put too much here, this isn't an epic novel, it's just a package description. Also, there is no real need to "advertise" the package here, so statements like "this is the best perl module that has ever been created by humans", while possibly accurate, are not terribly useful in answering the question "what is this and what does it do?".
+1
Sounds good. Not sure, but maybe it's possible to write it a bit shorter
Agreed. Shorter would be better.
Futhermore, I'd like to see some words added aiming at use of non-self-explanatory acronyms/names and redundant wording.
I am getting the creeps when reading descriptions similar to "Hawaii, the Moscow-daemon for Tokio, a free open-source implemention of PROZL/RKNR for GNIZL implemented by Dr. J.Doe at IRTX in Nutbush-City/TX."
Everything in Fedora is supposed to be "open source" ... who implemented it and where is non-interesting ... Hawaii, Moscow, Tokio etc. don't tell much to anybody, who aren't already familiar with any of these.
Ralf
On Mon, Sep 15, 2008 at 01:53:55PM +0200, Thorsten Leemhuis wrote:
Sounds good. Not sure, but maybe it's possible to write it a bit shorter to work against the "guidelines grow and grow" trend (¹). Maybe something like this is enough:
""" The description should not be exceed round about ten lines of text and contain useful data about what the packaged software does. The description should be written from a distance point of view and not sound like advertising. """
I don't think advertising should be mentionned, nor removing the authors, in my opinion this should be left to the packager (and the reviewer). This allows to have a description that fits with what upstream would have wanted for the package description which is, in my opinion, a desirable option to leave, even though it means having some kind of advirtising. So in my opinion it should only be
""" The description should not be exceed round about ten lines of text and contain useful data about what the packaged software does """
This should rule out the obscure acronyms, since they are need to be explained to have 'useful data about what the packaged software does', but leave to the packager room for optional items like advertisement and author names.
-- Pat
On Mon, 2008-09-15 at 17:00 +0200, Patrice Dumas wrote:
On Mon, Sep 15, 2008 at 01:53:55PM +0200, Thorsten Leemhuis wrote:
Sounds good. Not sure, but maybe it's possible to write it a bit shorter to work against the "guidelines grow and grow" trend (¹). Maybe something like this is enough:
""" The description should not be exceed round about ten lines of text and contain useful data about what the packaged software does. The description should be written from a distance point of view and not sound like advertising. """
I don't think advertising should be mentionned, nor removing the authors, in my opinion this should be left to the packager (and the reviewer).
-1
This allows to have a description that fits with what upstream would have wanted for the package description which is, in my opinion, a desirable option to leave, even though it means having some kind of advirtising. So in my opinion it should only be
""" The description should not be exceed round about ten lines of text and contain useful data about what the packaged software does """
This should rule out the obscure acronyms, since they are need to be explained to have 'useful data about what the packaged software does', but leave to the packager room for optional items like advertisement and author names.
No.
On 15.09.2008 17:00, Patrice Dumas wrote:
I don't think advertising should be mentionned, nor removing the authors
I totally disagree, as both advertising and authors can lead to really big problems ("can of worms"):
- look at the enlightenment description -- it sounds a bit like "this is better then GNOME or KDE"; thus those people maintaining GNOME or KDE might start adding "no, our Desktop is in fact better than Enlightenment"; I'd say nobody want such a mess (even if it sounds unlikely that things really get that worse)
- Open-Source is about working together; thus most of the packages we ship have multiple authors; which ones do you mention? the one that started the project? the most important one? If the first: what if he has left ages ago? If the second: who maintains that list and decides?
And mentioning the author in one package could lead to other upstream authors to requests like "you guys mention the author in the description for package foo, but you don't mention *my name* in the description of bar, which contains software I wrote. That will get interesting when it comes to packages like the kernels, which has multiple thousand authors
CU knurd
On Tue, Sep 16, 2008 at 04:16:50PM +0200, Thorsten Leemhuis wrote:
On 15.09.2008 17:00, Patrice Dumas wrote:
I don't think advertising should be mentionned, nor removing the authors
I totally disagree, as both advertising and authors can lead to really big problems ("can of worms"):
I am not saying that we should always add the authors. In general, when I do the description I copy paste something on the web page of th esoftware or in the README. I prefer to keep things as-is, including 'advertisement' and authors, since it seems to me to be how upstream wants the software to be described. That being said, trimming blatant and uninformative advertisement, and authors when they are too numerous is certainly a good practice, but I don't think this should be in the guidelines, the guideline should only have something about the length and the purpose of the %description, in my opinion.
-- Pat
On Sun, 2008-09-14 at 09:35 -0400, Tom "spot" Callaway wrote:
Wow. That is indeed too much information. :) I'm not sure how we should "guideline" that, other than something like:
== Descriptions == Your package description should contain useful data about the package, and answer the question "what is this and what does it do?". In general, the description should not exceed 10 lines or so. Try not to put too much here, this isn't an epic novel, it's just a package description. Also, there is no real need to "advertise" the package here, so statements like "this is the best perl module that has ever been created by humans", while possibly accurate, are not terribly useful in answering the question "what is this and what does it do?".
I think first and foremost, what is needed is to figure out what audience the description is targeted for. Everything else will fall in place once that is clear...
On Mon, 2008-09-15 at 17:10 -0400, Matthias Clasen wrote:
On Sun, 2008-09-14 at 09:35 -0400, Tom "spot" Callaway wrote:
Wow. That is indeed too much information. :) I'm not sure how we should "guideline" that, other than something like:
== Descriptions == Your package description should contain useful data about the package, and answer the question "what is this and what does it do?". In general, the description should not exceed 10 lines or so. Try not to put too much here, this isn't an epic novel, it's just a package description. Also, there is no real need to "advertise" the package here, so statements like "this is the best perl module that has ever been created by humans", while possibly accurate, are not terribly useful in answering the question "what is this and what does it do?".
I think first and foremost, what is needed is to figure out what audience the description is targeted for. Everything else will fall in place once that is clear...
I can think of a few off the top of my head:
* Someone who is looking for a package that does $FOO * Someone who is trying to figure out what this package that yum just installed is for
~spot
On Mon, 2008-09-15 at 17:12 -0400, Tom "spot" Callaway wrote:
I can think of a few off the top of my head:
- Someone who is looking for a package that does $FOO
- Someone who is trying to figure out what this package that yum just
installed is for
Some folks have asked about places to stick keywords they want for matching their packages in yum search. This is the only reasonable place to put them currently.
-sv
packaging@lists.fedoraproject.org
-
Dominik 'Rathann' Mierzejewski -
Matthias Clasen -
Patrice Dumas -
Ralf Corsepius -
Seth Vidal -
Thorsten Leemhuis -
Tom Callaway -
zing