Re: Usability: Technical details in package descriptions?
[John Hasler] So I'd suggest concentrating on the 3% of packages non-technical users might actually want to select manually, and making sure those have legible and searchable descriptions. Technical users don't deserve legible and searchable descriptions? I meant legible and searchable to ignorant people. It should go without saying that all package descriptions should be legible and searchable for their respective target audiences. That's not at all the same thing as what this subthread seems to be suggesting. signature.asc Description: Digital signature
Re: Usability: Technical details in package descriptions?
Peter Samuelson writes: I meant legible and searchable to ignorant people. Everyone is ignorant in some areas. Many intelligent and highly skilled people know little about programming. It should go without saying that all package descriptions should be legible and searchable for their respective target audiences. It _should_... -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
On Tue, 02 Aug 2005 22:51:11 -0700, Dustin Harriman [EMAIL PROTECTED] said: Wouldn't it make sense that debtags and Package Descriptions not do redundant work of each other? But Debtags information is not yet integrated into the package selection front-ends, like the description is. I use aptitude, and every packages description is shown to me when I browse the new or un-installed package lists; the debtags information is not present. I propose that by a simple split in the use of the Package Description and debtags between the internal world (ie. relative to the computer) and external world (ie. relative to the end user's real life apart from their computer), respectively, I think we can make the best use of volunteer effort as they review the Package Descriptions and create debtags. Firstly, this is an artificial distinction; my selection criteria for installing new packages does take into consideration the so called technical facets of the package. I think that the Package Description should be (re)written using language intended at your grandma. This way she can intuitively find packages also without needing to learn about the debtags system. Learning how to use the search button in Synaptic is work enough for her, let alone learn and play with debtags to do wild and crazy searching (with logical operators no less). I strongly oppose such discrimination against techinically competent people. We should not not make package selection harder for a group of people we do not consider the desired target audience by removing information they use in there selection criteria. I am all for clarified descriptions that make package selection easier for every user; but deliubrately removing information, based on the arrogant view point that our users are too dumb to understand, or presuming to decide that their selection criteria could not possibly be the same as us elite developers, is both silly and counter productive. Integrating debtags into package selection and browsing front-ends may mitigate the need for duplicating the information, but we are not there yet. manoj -- Most people's favorite way to end a game is by winning. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
On Wed, 03 Aug 2005 09:16:23 +0200, Benjamin Mesing [EMAIL PROTECTED] said: Especially details like written in C++ should be left to the debtags system as there is no use for the end user. I am a potential end user for the vast majority of packages in Debian -- as I am for the vast majority of the packages installed on my machines. I find lasnguage of implementation a useful selection criteria for selecting between completing implementations of similar functionality. I may not fit into your jaundiced view of what an end user /should/ be -- but that is merely lack of imagination on your part. I think Debian as a whole should not be discriminating against the segment of the user base that does tend to be somewhat technical -- I suspect there are a large number of us out there. manoj -- Nudists are people who wear one-button suits. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
On Thu, 04 Aug 2005 19:08:22 -0500, John Hasler [EMAIL PROTECTED] said: Peter Samuelson writes: There is no need for dumbing down descriptions for things non-technical users aren't going to be selecting anyway. One can be a highly technical user of a package without knowing (or caring) squat about the language it is implemented in. Descriptions should focus on the domain of application. Why should we only cater to a subset of selection criteria that we deem proper? What is wrong with having clear description of the domain of the application _and_ technical factes as well, so that we cater to all possible users, not just those who are deemed kosher by the powers that be? manoj ps: presenting technical facets may well be done by presenting debtags information, but, lacking that, the description has been traditionally used to do so -- Blessed are the young, for they shall inherit the national debt. Herbert Hoover Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Debtags-devel] Re: Usability: Technical details in package descriptions?
Hello, If the debtags also get searched when she does a simple search, then great. This will depend on how seamlessly debtags get integrated into package managers (like Synaptic's) search facilities (for example, a simple search by default, then an Advanced button to expand the search dialog, and there are all the debtags to select or exclude, with logical operators). Well that is what some of us have in mind. The user enters a search expression, and the search application somehow proposes some tags the user can select to refine the search (based on the search expression entered). That's a good point. Since this is CC'ed to debtags-devel, perhaps there could be a quality measuring facet called Maturity::, with Sourceforge-like values such as: Conceptual - Planning - Pre-Alpha - Alpha - Beta - Stable - Mature I think we had this discussion a while back, though I don't know exactly where it went. One problem I ca remember of is, that tags are no values. And searches like: Maturity:: Beta are not supported and conceptually very difficult to be implemented. Greetings Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
[Dustin Harriman] 1) Package descriptions should tend towards readers like grandma by default (ie. are as general as possible by default), and What about the majority of packages in Debian? You know, the ones your hypothetical ancestor would never wish to install explicitly, under any circumstances? The ones whose purpose she will never understand or see a need for on her system, even if you use very large type? Whatever is wrong with the very simple concept of if you don't understand what this does, don't install it? There is no need for dumbing down descriptions for things non-technical users aren't going to be selecting anyway. The set of packages whose descriptions your geriatric relative needs to be able to understand is a very small subset of Debian. It would even be a very small subset of Ubuntu. So I'd suggest concentrating on the 3% of packages non-technical users might actually want to select manually, and making sure those have legible and searchable descriptions. signature.asc Description: Digital signature
Re: Usability: Technical details in package descriptions?
Peter Samuelson writes: There is no need for dumbing down descriptions for things non-technical users aren't going to be selecting anyway. One can be a highly technical user of a package without knowing (or caring) squat about the language it is implemented in. Descriptions should focus on the domain of application. So I'd suggest concentrating on the 3% of packages non-technical users might actually want to select manually, and making sure those have legible and searchable descriptions. Technical users don't deserve legible and searchable descriptions? -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
Hello, I agree with you, that the documentation review team should have the debtags approach in mind. Also debtags-edit being able to edit descriptions would be desirable - however someone would need to implement this, and Enrico is very busy ;-). Being able to edit the package information in one program does have a lot of charm :-) Note that it took Thaddeus Black years(!) to categorize all the packages in sarge (for debram). Being done by a team makes a lot of sense - but even more to be cared for by the package maintainers themselves. However I have to say that I disagree with you in some points. You are correct, that the package description should be as non technical as possbile, without underminining the usefullness of it. Especially details like written in C++ should be left to the debtags system as there is no use for the end user. However not every description should be tuned for your grandma, they should be written towards the target audience. No use to describe an IDE, the debhelper packages and other to your grandma. Science applications are also canditates were it might make sense, that many of us may not understand their purpose without doing us any harm. I think the following formula should hold true: What you don't understand that should be of no use to you. E.g. I don't have any use for programs evaluating DICOM images (I only know what it is from a recent discussion in debtags-devel). Additionally I do strongly disagree with debtags describing only the internals! Debtags is designed to allow an effective search without the fuzziness you get, when doing a full-text search. And it fullfills this task very good (have a look at the use:: and works-with:: facet). Or should your grandma read the 15.000 package descriptions to find a program to archive her receipies? Finally I disagree with debtags being highly technical. It is only one step further from hierachies, and in my opinion even more intuitive. Take a look at the packagesearch program to see a really simple user interface. It does allow only an combination of tags, but for most end-users this is sufficient. I have CCed debtags-devel and attached your original message for the benefit of those reading only debtags-devel. Best regards Ben Hi all, Debtags shows great promise in covering the technical aspect of describing Debian packages. Debtags do a better job than Package Descriptions when it comes to precisely describing a package in a highly-technical, highly-searchable format (that is fully geek compliant). Wouldn't it make sense that debtags and Package Descriptions not do redundant work of each other? I propose that by a simple split in the use of the Package Description and debtags between the internal world (ie. relative to the computer) and external world (ie. relative to the end user's real life apart from their computer), respectively, I think we can make the best use of volunteer effort as they review the Package Descriptions and create debtags. I think that the Package Description should be (re)written using language intended at your grandma. This way she can intuitively find packages also without needing to learn about the debtags system. Learning how to use the search button in Synaptic is work enough for her, let alone learn and play with debtags to do wild and crazy searching (with logical operators no less). As debtags cater to the geek, I think the Package Description should cater to grandma. I think the package desription should state the purpose of the software as it relates to the real world, whenever possible: eg. helps you easily keep lists of contact information on people along with details like their birthdays. A description like this is useful to grandma. Anything more technical and you lose her to the likes of Ubuntu or Linspire. Come on, throw grandma a (less than 80 character) bone! Grandma can give back some day by helping to file a bug report or something. I therefore propose that ***the package description should explain how a package could be used for real-world usefulness for the end user***, giving an example or two for those with dimmer imaginations than hard core geeks. In my example above, mentioning tracking birthdays helps users start imagining the potential usefulness of the software. Note how mozilla.org has a screenshot of the craiglist website on the front page to help users *imagine* visiting a website like craigslist using the browser (albeit visually, not textually). Same idea. Imagining how some piece of software could be useful is hard work for most people, and you can help them tremendously by providing a simple and obvious-to-you example in the package description. Debtags will much better handle all the fine-grained, geeky details, like the language it was written in, and to which suite it belongs. Therefore ***I think debtags should aim to exclusively describe a package's
Re: Usability: Technical details in package descriptions?
Benjamin Mesing wrote: However I have to say that I disagree with you in some points. You are correct, that the package description should be as non technical as possbile, without underminining the usefullness of it. Yes, I agree. Instead of the absolutes I proposed, perhaps it still makes alot of sense to have generally have rules of thumb that: 1) Package descriptions should tend towards readers like grandma by default (ie. are as general as possible by default), and 2) Debtags tend toward geekly, highly-accurate searchability by default (ie. are specific by default) This would still help reduce redundancy and economize the efforts of volunteers who edit the Package Descriptions and add Debtags. I think the following formula should hold true: What you don't understand that should be of no use to you. E.g. I don't have any use for programs evaluating DICOM images (I only know what it is from a recent discussion in debtags-devel). I strongly agree here. Additionally I do strongly disagree with debtags describing only the internals! Debtags is designed to allow an effective search without the fuzziness you get, when doing a full-text search. And it fullfills this task very good (have a look at the use:: and works-with:: facet). Or should your grandma read the 15.000 package descriptions to find a program to archive her receipies? My point is that Grandma should be able to merely use the simple search dialog in Synaptic without having to mess around with selecting/surfing through debtags. Moreover, her search terms are going to be very general, eg. money (instead of accounting) or recipes (instead of cooking). Therefore, let her general query turn up the best results, and hopefully having a general description (ideally with example use mentioned) in Package Descriptions helps in this regard. A Package Description provides the opportunity to squeeze in a few synonyms, or related words for even better searchability beyond the rather standard values in Debtags. If the debtags also get searched when she does a simple search, then great. This will depend on how seamlessly debtags get integrated into package managers (like Synaptic's) search facilities (for example, a simple search by default, then an Advanced button to expand the search dialog, and there are all the debtags to select or exclude, with logical operators). Finally I disagree with debtags being highly technical. It is only one step further from hierachies, and in my opinion even more intuitive. That's a good point. Since this is CC'ed to debtags-devel, perhaps there could be a quality measuring facet called Maturity::, with Sourceforge-like values such as: Conceptual - Planning - Pre-Alpha - Alpha - Beta - Stable - Mature I have CCed debtags-devel and attached your original message for the benefit of those reading only debtags-devel. Best regards Ben Wouldn't it make sense that debtags and Package Descriptions not do redundant work of each other? And on a related tangent, wouldn't it also make sense that all the volunteers who are going to examine all the package descriptions one at a time also create the appropriate debtags while they are at it? This could further help eliminate redundancy in what debtags and package descriptions explain. At the very least, wouldn't it make sense for there to be more coordination between the debtags effort, and the Packages Descriptions review campaign? Maybe the gui tool debtags-editor should/could be extended to *also* allow editing of package descriptions? Cheers, -- Dustin Harriman http://annexia.ca -- Dustin Harriman http://annexia.ca -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
Hi all, Debtags shows great promise in covering the technical aspect of describing Debian packages. Debtags do a better job than Package Descriptions when it comes to precisely describing a package in a highly-technical, highly-searchable format (that is fully geek compliant). Wouldn't it make sense that debtags and Package Descriptions not do redundant work of each other? I propose that by a simple split in the use of the Package Description and debtags between the internal world (ie. relative to the computer) and external world (ie. relative to the end user's real life apart from their computer), respectively, I think we can make the best use of volunteer effort as they review the Package Descriptions and create debtags. I think that the Package Description should be (re)written using language intended at your grandma. This way she can intuitively find packages also without needing to learn about the debtags system. Learning how to use the search button in Synaptic is work enough for her, let alone learn and play with debtags to do wild and crazy searching (with logical operators no less). As debtags cater to the geek, I think the Package Description should cater to grandma. I think the package desription should state the purpose of the software as it relates to the real world, whenever possible: eg. helps you easily keep lists of contact information on people along with details like their birthdays. A description like this is useful to grandma. Anything more technical and you lose her to the likes of Ubuntu or Linspire. Come on, throw grandma a (less than 80 character) bone! Grandma can give back some day by helping to file a bug report or something. I therefore propose that ***the package description should explain how a package could be used for real-world usefulness for the end user***, giving an example or two for those with dimmer imaginations than hard core geeks. In my example above, mentioning tracking birthdays helps users start imagining the potential usefulness of the software. Note how mozilla.org has a screenshot of the craiglist website on the front page to help users *imagine* visiting a website like craigslist using the browser (albeit visually, not textually). Same idea. Imagining how some piece of software could be useful is hard work for most people, and you can help them tremendously by providing a simple and obvious-to-you example in the package description. Debtags will much better handle all the fine-grained, geeky details, like the language it was written in, and to which suite it belongs. Therefore ***I think debtags should aim to exclusively describe a package's relationship to the internal system it lives in, ie. relative to Debian.*** And on a related tangent, wouldn't it also make sense that all the volunteers who are going to examine all the package descriptions one at a time also create the appropriate debtags while they are at it? This could further help eliminate redundancy in what debtags and package descriptions explain. At the very least, wouldn't it make sense for there to be more coordination between the debtags effort, and the Packages Descriptions review campaign? Maybe the gui tool debtags-editor should/could be extended to *also* allow editing of package descriptions? Cheers, -- Dustin Harriman http://annexia.ca -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
On Thu, 21 Jul 2005 16:02:21 +0200, Olaf van der Spek [EMAIL PROTECTED] said: On 7/21/05, Thaddeus H. Black [EMAIL PROTECTED] wrote: I see another side to it, however. At least seven reasons occur to me why a user might care what language a program is written in. A 'normal' user doesn't know what C, C++ and Perl are. The user I am creating packages for does. I am not really that interested in working for user who do not know the distinction, personally speaking. manoj -- Meade's Maxim: Always remember that you are absolutely unique, just like everyone else. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
On Thu, 21 Jul 2005 15:08:43 -0300, Ben Armstrong [EMAIL PROTECTED] said: On Thu, 2005-07-21 at 19:58 +0200, Thijs Kinkhorst wrote: nstead of putting it in the first sentence, the second paragraph would be a fine place to mention details like this, satisfying both novice and advanced users. But why bother, when debtags does implemented-in does the job better? Because that information is not presented to me in aptitude, one of the preferred front ends to package management. Once the deb tags system gets integrated into the front ends, the long description can stop shouldering some of the load of presenting all the useful/relevant infdormation to the user interested in making an informed decision. manoj -- I want to dress you up as TALLULAH BANKHEAD and cover you with VASELINE and WHEAT THINS ... Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
On Sat, 23 Jul 2005, Manoj Srivastava wrote: A 'normal' user doesn't know what C, C++ and Perl are. The user I am creating packages for does. I am not really that interested in working for user who do not know the distinction, personally speaking. So your personal target user might be able to find out the programming language himself and mentioning it in the description is also redundant. -- We found another reason to leave the language out of the description. Thanks Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
On Thu, 21 Jul 2005 12:33:32 -0300, Ben Armstrong [EMAIL PROTECTED] said: 2. Programs written in obscure languages may prove unmaintainable if the original developer disappears. Besides threatening obsolescence, this can be a security issue. You've furnished a reason *not* to put the language in the description (if I wrote a package in an obscure language and took your point to heart, I'd not want to advertise the fact). Besides, what is obscure? Ruby? Ocaml? Snobol? Fortran? Scheme? How is a user to assess whether these are up-and-coming languages, less popular but still well supported, or completely obsolete? I doubt if most users know the difference. BZZZT. The idea is not to con the user into using the package willy nilly, the idea is to provide him enough information to make an informed choice. If providing you with information about the implementation language causes you to change your decision, then delibrately withholding that information is akin to fraud and underhanded dealing we should steer clear off. Now we're *really* getting touchy-feely. I think we're losing sight of the goal: the user, reading the description, should get a sense of what the package does, whether it is likely to meet their needs, and whether it offers distinct advantages over any of the alternatives. While I can appreciate that some small minority of users out their are aware of the mindset, aesthetic and development culture of an implementation language, and therefore have some mild bias towards packages implemented in it, it certainly isn't a primary indicator of whether the package is suitable for a particular use or not. I also select a program based on languages I know; since it makes it more likely that I can tweak the program rto my needs, or help with stalled development. Given a choice, I would invest in the learning curve of programs I can help modify, develop, and contribute to. Since I find the information useful, I am not going to pretend my suers are idiots who couldn't possibly make use of such iformation, because, you see, I am so special, and only I can use the information, not the oh so dumb users. So, I am going to continue to provide information in the descriptions of my packages that I would find useful, in the hopes that it is useful to the users of my packages as well. manoj -- Encyclopedia for sale by father. Son knows everything. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
On Sat, 23 Jul 2005 08:32:50 +0200 (CEST), Andreas Tille [EMAIL PROTECTED] said: On Sat, 23 Jul 2005, Manoj Srivastava wrote: A 'normal' user doesn't know what C, C++ and Perl are. The user I am creating packages for does. I am not really that interested in working for user who do not know the distinction, personally speaking. So your personal target user might be able to find out the programming language himself and mentioning it in the description is also redundant. I am the prime representative of my target user. I use aptitude; hit u to upgrade, look at the new package list, and try to decide which of these new packages to install. The information in the Description field is far from redundant here. -- We found another reason to leave the language out of the -- description. If this is an example of the illogic governing the move to get useful information out of descriptions, to facour dumbing down and simplifying for users who seem to be confused by the littlelest things, I see no reason to favour the proposal. If the proponents of this proposal are so desparate to stretch things in order to make up support for the proposal out of whole cloth, surely there must be something wrong with the proposal? Or else why are people being so shrill? Indeed, this leap of illogic is disturbing in its own right. manoj -- If a camel flies, no one laughs if it doesn't get very far. Paul White Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
On Sat, 2005-07-23 at 01:21 -0500, Manoj Srivastava wrote: Because that information is not presented to me in aptitude, one of the preferred front ends to package management. Once the deb tags system gets integrated into the front ends, the long description can stop shouldering some of the load of presenting all the useful/relevant infdormation to the user interested in making an informed decision. Your criticism is valid. Indeed this is a flaw in the current proposal. But on one point, I think you have been unfair. I believe you have mistaken enthusiasm for an idea that is good, but cannot yet be fully implemented without the appropriate tools in place and the cooperation of maintainers, with a shrill defense of a weak proposal. The proposal does need refinement to account for pieces of the system that are not ready yet, and to clarify when package descriptions should be changed today, but it is not fundamentally flawed. I do not believe anyone in this thread has claimed that appropriate mention of the langauge appears in the description now should be removed. If I gave this misimpression, please understand this is not what I meant. I merely challenge maintainers to consciously compensate for our implementation-centric bias as developers, recognizing that users focus on utility. If those users are themselves developers, certainly implementation will be important. If they are, as a rule, not, we should think twice about including implementation trivia in our descriptions. I see potential for debtags to help streamline the information in our package descriptions down to the essential qualities that help a typical user decide whether or not they want to try the package. This is by no means a dumbing down of package descriptions. The process can start now, both with the voluntary removal by maintainers of non-essential details from their own descriptions and supporting the development of debtags. Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
On Sat, 23 Jul 2005 10:58:34 -0300, Ben Armstrong [EMAIL PROTECTED] said: On Sat, 2005-07-23 at 01:21 -0500, Manoj Srivastava wrote: Because that information is not presented to me in aptitude, one of the preferred front ends to package management. Once the deb tags system gets integrated into the front ends, the long description can stop shouldering some of the load of presenting all the useful/relevant infdormation to the user interested in making an informed decision. Your criticism is valid. Indeed this is a flaw in the current proposal. But on one point, I think you have been unfair. I believe you have mistaken enthusiasm for an idea that is good, but cannot yet be fully implemented without the appropriate tools in place and the cooperation of maintainers, with a shrill defense of a weak proposal. Not quite. I meant to target my irritation at one respondent, who took my mail about current inability to leverage debtags while selecting packages, and without addressing my objection, tried a jejune stretching of the statement to pretned I had provided additional support for the proposal, rather than pointing to something that needs to be put into place. The proposal does need refinement to account for pieces of the system that are not ready yet, and to clarify when package descriptions should be changed today, but it is not fundamentally flawed. Indeed, I like the proposal, and in time it would probably make the package selection mechanism easier (perhaps scroing debtag attributes by individual preference to help sort through new or alternate package choices). I do not believe anyone in this thread has claimed that appropriate mention of the langauge appears in the description now should be removed. If I gave this misimpression, please understand this is not what I meant. Then I have indeed misread what we were leading to. If we are not talking about running through current descriptions and excising such language from the description, then I am not sure what the discussion is about, and my objections are likely to be moot. I merely challenge maintainers to consciously compensate for our implementation-centric bias as developers, recognizing that users focus on utility. If those users are themselves developers, certainly implementation will be important. If they are, as a rule, not, we should think twice about including implementation trivia in our descriptions. I am all for providing information to users to help them select packages. I am not, however, much in favour of displaying bias for one class of users over others; so while I'll entertain ideas about how to improve my package descriptions to help novice user also get information relevant to their selection criteria, I am opposed to removing information relevant to some users on the grounds that that information is not required for the selection criteria of the so called target users. I see potential for debtags to help streamline the information in our package descriptions down to the essential qualities that help a typical user decide whether or not they want to try the package. This is by no means a dumbing down of package descriptions. The process can start now, both with the voluntary removal by maintainers of non-essential details from their own descriptions and supporting the development of debtags. This is where I have misgivings. What is a typical user? What if we are wrong about typical users? What if the audience for a package changes over time? Why should we discriminate against users who do not fit our model of typical and approved users by withholding information from the description that they require for their selection criteria? I am all for giving people options, and information, to help select between the options, or packages. I am not so much in favour of curtailing information that some users use foir the selection just because they do not fit my definition of the right kind of user. manoj -- Home on the Range was originally written in beef-flat. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
On Sat, Jul 23, 2005 at 01:30:24AM -0500, Manoj Srivastava wrote: On Thu, 21 Jul 2005 12:33:32 -0300, Ben Armstrong [EMAIL PROTECTED] said: 2. Programs written in obscure languages may prove unmaintainable if the original developer disappears. Besides threatening obsolescence, this can be a security issue. Now we're *really* getting touchy-feely. I think we're losing sight of the goal: the user, reading the description, should get a sense of what the package does, whether it is likely to meet their needs, and whether it offers distinct advantages over any of the alternatives. (...) have some mild bias towards packages implemented in it, it certainly isn't a primary indicator of whether the package is suitable for a particular use or not. I also select a program based on languages I know; since it makes it more likely that I can tweak the program rto my needs, or help with stalled development. And this is one of the central points behind free software after all: the freedom, both legal and practical, to do exactly that. That in the current times most people are technically unable to do that is just an unfortunate temporary situation to me, that comes from a conjunction of factors like youth of the field, that the programming language of choice still changes way too often (probably linked to youth of the field), etc. Our (grand-)^n parents' generation got to the point of a society where *everyone*, or nearly, can read and write. So I don't see why our (grand-)^n children's generation cannot get to the point of a society where everyone can program. Not everyone has to be a Don Knuth, of course. Just like not everyone is a Shakespeare today. I like to see the Free Software movement as a precursor in this direction. And Debian as a spearhead of the Free Software movement, not merely a provider of prepackaged goods. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
On Wed, Jul 20, 2005 at 08:48:46PM +0200, Andreas Tille wrote: On Wed, 20 Jul 2005, W. Borgert wrote: Foo is a Perl-based program that... libBar is written in C... libBang is written in only 42 lines of source code... Baz has been written by me... Do such descriptions justify bug reports of severity=minor? Well, I would guess wishlist is the right way to go and the language should go into debtags information as suggested by others. The language a program is written in is completely irrelevant for user applications and might more confuse user than beeing helpful. For librarie-dev packages it might be helpful because it is relevent developer information. Thanks for pointing this out It seems to me that WB and Andreas make a valid point. Why should the user care what language a program is written in, so long as the program works right? Functionality is the important thing. I see another side to it, however. At least seven reasons occur to me why a user might care what language a program is written in. 1. Compiled programs (C, C++, Fortran 77, Ada, ...) usually run leaner and faster than do interpreted ones (Perl, Python, Ruby, ...). 2. Programs written in obscure languages may prove unmaintainable if the original developer disappears. Besides threatening obsolescence, this can be a security issue. 3. Programs written in widely used languages (C, C++, Perl, Python, ...) may work better simply because the programmer had adequate access during development to high-quality modules and library bindings. 4. With a language come a mindset, an aesthetic and a development culture. Although one cannot speak in absolutes, generally speaking, which program would you expect to be more focused and reliable: a program written in C++ or an alternative written in Perl? (On the other hand, which of the two programs would you expect to be available sooner?) 5. Some languages are inherently more debuggable (or less bug-prone) than others. C++ is more debuggable than C, which itself is more debuggable than Fortran 77. Python is more debuggable than Perl. Programs written in the more debuggable languages may rationally be expected to suffer fewer bugs. 6. Some languages enjoy not only free compilers or interpreters, but also well written, complete free documentation. It may not seem like much, but a limited ideological motive may exist to promote programs written in such languages. 7. Some users may want to be able to read parts of the source of the programs they use---even if they have no intention of contributing to development. This is Debian, after all. Programs written in obscure languages may be vaguely deprecated for this reason. If it matters, the languages I personally use most on a daily basis are Perl, Fortran 77, Octave and Bash (also occasionally C, C++ or Python)---some of which do not rank very well by my own criteria. However, I do tend to avoid publishing things written in Perl, because I use Perl often and know Perl's nature. As a user, I tend to prefer software compiled from C/C++. Hence the language in which a program is implemented is somewhat relevant, at least to me. -- Thaddeus H. Black 508 Nellie's Cave Road Blacksburg, Virginia 24060, USA +1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED] pgpNj11HIQWzj.pgp Description: PGP signature
Re: Usability: Technical details in package descriptions?
On 7/21/05, Thaddeus H. Black [EMAIL PROTECTED] wrote: I see another side to it, however. At least seven reasons occur to me why a user might care what language a program is written in. A 'normal' user doesn't know what C, C++ and Perl are.
Re: Usability: Technical details in package descriptions?
Hello, I started a page on the Debian wiki for this project http://wiki.debian.net/?PackagesDescriptionsReview Feel free to edit any part of it. If everyone agrees, I intend to add some thoughts about the organization details we could set up (code to track the work and ease the work of the reviewers). Regards, -- Clément -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
On Thu, Jul 21, 2005 at 01:45:55PM +, Thaddeus H. Black wrote: 4. With a language come a mindset, an aesthetic and a development culture. Although one cannot speak in absolutes, generally speaking, which program would you expect to be more focused and reliable: a program written in C++ or an alternative written in Perl? (On the other hand, which of the two programs would you expect to be available sooner?) I think you are expecting people to say C++, and on the other hand, Perl: However, I think perl for both :-) -- Jon Dowland http://jon.dowland.name/ PGP fingerprint: 7032F238 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
On Thu, 21 Jul 2005, Thaddeus H. Black wrote: I see another side to it, however. At least seven reasons occur to me why a user might care what language a program is written in. 1. Compiled programs (C, C++, Fortran 77, Ada, ...) usually run leaner and faster than do interpreted ones (Perl, Python, Ruby, ...). This could be expressed by caracterizing the runtime behaviour verbal (if necessary - I guess no package description will contain: this program runs slowly because it is written in an interpreted language). Moreover the users we talk about in this thread might not have the necessary knowledge to draw these conclusions. 2. Programs written in obscure languages may prove unmaintainable if the original developer disappears. Besides threatening obsolescence, this can be a security issue. Security issues should be sorted out by the maintainer / security team and not by users who need a certain knowledge about a programming language. 3. Programs written in widely used languages (C, C++, Perl, Python, ...) may work better simply because the programmer had adequate access during development to high-quality modules and library bindings. If there are competing packages with same functionality this might be a minor point. In the end the decision pro or contra is done on the usability side, not based upon the programming language. 4. With a language come a mindset, an aesthetic and a development culture. Although one cannot speak in absolutes, generally speaking, which program would you expect to be more focused and reliable: a program written in C++ or an alternative written in Perl? (On the other hand, which of the two programs would you expect to be available sooner?) Our target users will probably not do such consideratione. 5. Some languages are inherently more debuggable (or less bug-prone) than others. C++ is more debuggable than C, which itself is more debuggable than Fortran 77. Python is more debuggable than Perl. Programs written in the more debuggable languages may rationally be expected to suffer fewer bugs. Also more a developers consideration. 6. Some languages enjoy not only free compilers or interpreters, but also well written, complete free documentation. It may not seem like much, but a limited ideological motive may exist to promote programs written in such languages. Ditto. 7. Some users may want to be able to read parts of the source of the programs they use---even if they have no intention of contributing to development. This is Debian, after all. Programs written in obscure languages may be vaguely deprecated for this reason. They might find it out from Debtags. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
Jon Dowland writes: I think you are expecting people to say C++, and on the other hand, Perl: However, I think perl for both :-) I agree. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
On Thu, 2005-07-21 at 13:45 +, Thaddeus H. Black wrote: 1. Compiled programs (C, C++, Fortran 77, Ada, ...) usually run leaner and faster than do interpreted ones (Perl, Python, Ruby, ...). In general, algorithm choice is much more important than language. Also, the language the main program is written in may be of little significance to the program's overall performance if the grunt work is done in libraries written in a compiled language. In the end, the user wants to know if the program's speed and size is acceptable for their needs. The language that the program is written in does not directly answer these questions, and sometimes is even misleading. 2. Programs written in obscure languages may prove unmaintainable if the original developer disappears. Besides threatening obsolescence, this can be a security issue. You've furnished a reason *not* to put the language in the description (if I wrote a package in an obscure language and took your point to heart, I'd not want to advertise the fact). Besides, what is obscure? Ruby? Ocaml? Snobol? Fortran? Scheme? How is a user to assess whether these are up-and-coming languages, less popular but still well supported, or completely obsolete? I doubt if most users know the difference. 3. Programs written in widely used languages (C, C++, Perl, Python, ...) may work better simply because the programmer had adequate access during development to high-quality modules and library bindings. A false sense of security at best. You could argue conversely that the more popular the language, the more likely a novice programmer has chosen it to dash off their first programming project and has managed to get it into Debian. And perhaps using an obscure language could be viewed as a filter, weeding out the less-motivated and less-skilled programmers. Again, the user cannot use implementation language as a reliable indicator of quality. 4. With a language come a mindset, an aesthetic and a development culture. Although one cannot speak in absolutes, generally speaking, which program would you expect to be more focused and reliable: a program written in C++ or an alternative written in Perl? (On the other hand, which of the two programs would you expect to be available sooner?) Now we're *really* getting touchy-feely. I think we're losing sight of the goal: the user, reading the description, should get a sense of what the package does, whether it is likely to meet their needs, and whether it offers distinct advantages over any of the alternatives. While I can appreciate that some small minority of users out their are aware of the mindset, aesthetic and development culture of an implementation language, and therefore have some mild bias towards packages implemented in it, it certainly isn't a primary indicator of whether the package is suitable for a particular use or not. 5. Some languages are inherently more debuggable (or less bug-prone) than others. C++ is more debuggable than C, which itself is more debuggable than Fortran 77. Python is more debuggable than Perl. Programs written in the more debuggable languages may rationally be expected to suffer fewer bugs. A more direct measure of this can be determined by a bit of research by the user first: check the Debian bug database, the changelogs, the upstream bug database, the support development mailing lists. Ask your friends. Is this a good program, or is it a buggy piece of waste product? 6. Some languages enjoy not only free compilers or interpreters, but also well written, complete free documentation. It may not seem like much, but a limited ideological motive may exist to promote programs written in such languages. We're getting further and further from real user concerns. See my answer to 5. 7. Some users may want to be able to read parts of the source of the programs they use---even if they have no intention of contributing to development. This is Debian, after all. Programs written in obscure languages may be vaguely deprecated for this reason. apt-get source packagename and look it over if you're an aspiring developer. There isn't any better way to get acquainted with the source than to actually look at it. If it matters, the languages I personally use most on a daily basis are Perl, Fortran 77, Octave and Bash (also occasionally C, C++ or Python)---some of which do not rank very well by my own criteria. Octave, what's that? Hm, I guess it must be one of those shoddy deprecated languages. I'll make sure to avoid anything you've written in it. ;) However, I do tend to avoid publishing things written in Perl, because I use Perl often and know Perl's nature. As a user, I tend to prefer software compiled from C/C++. Hence the language in which a program is implemented is somewhat relevant, at least to me. And somewhat relevant is exactly what the debtags aspect implemented-in is for, as mentioned earlier. Ben -- To
Re: Usability: Technical details in package descriptions?
On Thu, 2005-07-21 at 13:45 +, Thaddeus H. Black wrote: Hence the language in which a program is implemented is somewhat relevant, at least to me. The conclusion is clear: the programming language is relevant to some users, but not to others (who are presumed to be large in quantity). So it's perfectly ok to mention the programming language, but not at the start of the description. nstead of putting it in the first sentence, the second paragraph would be a fine place to mention details like this, satisfying both novice and advanced users. Regards, Thijs signature.asc Description: This is a digitally signed message part
Re: Usability: Technical details in package descriptions?
On Thu, 2005-07-21 at 19:58 +0200, Thijs Kinkhorst wrote: nstead of putting it in the first sentence, the second paragraph would be a fine place to mention details like this, satisfying both novice and advanced users. But why bother, when debtags does implemented-in does the job better? Extra verbiage in the long description that adds no value for most users is best simply left out. It will just make the description a longer read (not to mention introducing possible false hits in an apt-cache search) which is a net negative effect on the users that don't need or want this information. Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
On Wed, 2005-07-20 at 18:13 +0200, Nico Golde wrote: I think one reason could be that some poeple would rather install a programm in a language they know and they are able to debug. Just a guess. On Wed, Jul 20, 2005 at 01:41:31PM -0300, Ben Armstrong wrote: Debtags facets[0] are better for this. Descriptions are supposed to help *ordinary* users decide which programs to install. (Hint: most of the world doesn't know how to debug in *any* language.) I *love* this idea, and it can be one good first use of Debtags, now that we have the data readily accessible in the Packages file. On Wed, Jul 20, 2005 at 06:42:42PM +0200, Steinar H. Gunderson wrote: You might want to look into the implemented-in debtags facet instead, then; it's probably more reliable :-) Note: due to recent refactoring, the implemented-in facet has been merged into the broader made-of facet. Thanks Ben and Steinar for the idea: it's the first application of Debtags as pure information that's been pointed to me. I've always only thought of tags as data to use for smarter package searches. That quite broadens my view. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Usability: Technical details in package descriptions?
On Wed, Jul 20, 2005 at 02:47:22PM -0500, Steve Greenland wrote: On 20-Jul-05, 10:47 (CDT), W. Borgert [EMAIL PROTECTED] wrote: what do you think about the usefulness of technical (and other strange) details in package description? While mostly agreeing with the other comments (libbar is a C library is useful/appropriate; foo is a perl program is not.), I'd guess this is a symptom of a more general problem: far too many package descriptions are taken verbatim from the upstream website/whatever. This leads to the irrelevant technical details you noted, as well as unfounded hyperbola (Foo is the world's best baz mangler) and generally bad writing. Most of these are probably worth a wishlist bug, but ONLY if accompanied by a suggested improvement. Most such phrases I have seen can be 'improved' merely by deleting them. They're content-free. I guess you could provide patches reducing the description to one or two lines, but it seems kinda like a waste of effort. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Usability: Technical details in package descriptions?
Hi, * W. Borgert [EMAIL PROTECTED] [2005-07-20 18:08]: what do you think about the usefulness of technical (and other strange) details in package description? I think, those are annoying and should be avoided, but maybe I can learn, why they are useful. Examples: Foo is a Perl-based program that... libBar is written in C... [...] I think one reason could be that some poeple would rather install a programm in a language they know and they are able to debug. Just a guess. I don't think this would justify a bug report. Maybe wishlist for a better control description but in general it is only further information... Regards Nico -- Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
On Wed, 2005-07-20 at 18:13 +0200, Nico Golde wrote: [...] I think one reason could be that some poeple would rather install a programm in a language they know and they are able to debug. Just a guess. Debtags facets[0] are better for this. Descriptions are supposed to help *ordinary* users decide which programs to install. (Hint: most of the world doesn't know how to debug in *any* language.) I agree that minor bugs are called for when descriptions contain non-descriptive technical trivia like this. Ben [0] http://debtags.alioth.debian.org/paper-debtags.html#facets -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
On Wed, Jul 20, 2005 at 06:13:22PM +0200, Nico Golde wrote: I think one reason could be that some poeple would rather install a programm in a language they know and they are able to debug. Just a guess. You might want to look into the implemented-in debtags facet instead, then; it's probably more reliable :-) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
On Wednesday 20 July 2005 08:47 am, W. Borgert wrote: Do such descriptions justify bug reports of severity=minor? Yes, with perhaps one exception: libBar is written in C... This is almost a sensible start to a description, since the language of implementation actually matters for a library. Better would be libBar is a C library... ...the difference being that a library can provide a C API without being implemented in C. Daniel -- /--- Daniel Burrows [EMAIL PROTECTED] --\ | Since TeX's value for infinity is quite low... | | -- The LaTeX Companion | \ The Turtle Moves! -- http://www.lspace.org ---/ pgphckRZaazRZ.pgp Description: PGP signature
Re: Usability: Technical details in package descriptions?
On Wed, 20 Jul 2005, W. Borgert wrote: Foo is a Perl-based program that... libBar is written in C... libBang is written in only 42 lines of source code... Baz has been written by me... Do such descriptions justify bug reports of severity=minor? Well, I would guess wishlist is the right way to go and the language should go into debtags information as suggested by others. The language a program is written in is completely irrelevant for user applications and might more confuse user than beeing helpful. For librarie-dev packages it might be helpful because it is relevent developer information. Thanks for pointing this out Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
On 20-Jul-05, 10:47 (CDT), W. Borgert [EMAIL PROTECTED] wrote: what do you think about the usefulness of technical (and other strange) details in package description? While mostly agreeing with the other comments (libbar is a C library is useful/appropriate; foo is a perl program is not.), I'd guess this is a symptom of a more general problem: far too many package descriptions are taken verbatim from the upstream website/whatever. This leads to the irrelevant technical details you noted, as well as unfounded hyperbola (Foo is the world's best baz mangler) and generally bad writing. Most of these are probably worth a wishlist bug, but ONLY if accompanied by a suggested improvement. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
ke, 2005-07-20 kello 14:47 -0500, Steve Greenland kirjoitti: While mostly agreeing with the other comments (libbar is a C library is useful/appropriate; foo is a perl program is not.), I'd guess this is a symptom of a more general problem: far too many package descriptions are taken verbatim from the upstream website/whatever. This leads to the irrelevant technical details you noted, as well as unfounded hyperbola (Foo is the world's best baz mangler) and generally bad writing. It seems to me that many package descriptions could be improved: misspellings, bad grammar, unclarity, hyperbole or advertising, irrelevant things, missing things, etc. Maybe it would be worthwhile to have a weekend, similar to a bug squashing party, where all descriptions are proofread and for those that need it, a proposed new description filed as a wishlist bug? Given 15000 packages, and 20 volunteers, and on average two minutes per description (given that most descriptions probably only need little or no tweaking), this would take only about 24 hours. This would require people who can proof-read and fix English text pretty well, however. A checklist of things to watch out for would help, but isn't enough. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
Hello Maybe it would be worthwhile to have a weekend, similar to a bug squashing party, where all descriptions are proofread and for those that need it, a proposed new description filed as a wishlist bug? Given 15000 packages, and 20 volunteers, and on average two minutes per description (given that most descriptions probably only need little or no tweaking), this would take only about 24 hours. This would require people who can proof-read and fix English text pretty well, however. A checklist of things to watch out for would help, but isn't enough. I would be very interested in helping setting up these guidelines and coordinating the work. I think it might be good to do this in two pass, first by just checking the descriptions and flagging the packages that need work, and a second pass working on improving the descriptions and filing bugs (it would imply a real mass bug filing, which is not really recommended, but seems the better way). Having at least two people making the review and two people working on an updated description seems a must. I guess a quickly crafted web interface could do the trick. Regards, -- Clément -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
On 20-Jul-05, 15:18 (CDT), Lars Wirzenius [EMAIL PROTECTED] wrote: ke, 2005-07-20 kello 14:47 -0500, Steve Greenland kirjoitti: Given 15000 packages, and 20 volunteers, and on average two minutes per description (given that most descriptions probably only need little or no tweaking), this would take only about 24 hours. This would require people who can proof-read and fix English text pretty well, however. A checklist of things to watch out for would help, but isn't enough. I think 2 min/pkg for *spotting* problems is reasonable, but not nearly enough for fixing them. Decent writing is non-trivial. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
Hello Steve, On Wed, Jul 20, 2005 at 05:25:35PM -0500, Steve Greenland wrote: I think 2 min/pkg for *spotting* problems is reasonable, but not nearly enough for fixing them. Decent writing is non-trivial. Especially for cases like where some research is necessary to find out what the package actually does. Some randomly chosen examples where the function of the package is not clear to me from reading the description: djview: DjVu viewer djview. libaca0: This is the files for ACA which are needed to compile binaries from sources. There aren't any documentations, only examples yet. libsvncpp0: Shared library package. libcml-smlnj: An SML library for message-passing concurrency. libocc0c2: OpenC++ is a tool for source-code translation for C++. libx500-dn-perl: style DN strings. . mpdconn.app: MPDCon is a simple GNUstep controller for MPD. netcdfg-dev: Includes headers, static libraries, and documentation. riece-lsdb: This package is cooperates with LSDB. xjokes: xjokes contains 4 jokes. yasiti, blackhole, mori1, and mori2. It might also be easy to spend time on deciding whether the following should be improved. LibAST is the Library of Assorted Spiffy Things. It contains many spiffy things, and it is a library. Thus, the ever-so-creative name. LibAST has been previously known as libmej, the Eterm helper library which nobody really understood and certainly never used. My current plan is to gradually remove some of the neat stuff from Eterm that could be made generic (things like the theme parsing engine, the command-line options parser, perhaps the event engine, ...) and place it here in the hopes that others will find them useful. But however long it takes, some concerted effort should be able to improve things a lot. I would be interested to help with this. All the best, Jochen -- http://seehuhn.de/ signature.asc Description: Digital signature
Re: Usability: Technical details in package descriptions?
On Thu, Jul 21, 2005 at 12:12:41AM +0100, Jochen Voss wrote: Especially for cases like where some research is necessary to find out what the package actually does. Some randomly chosen examples where the function of the package is not clear to me from reading the description: I looked through several hundred descriptions now. Most of them really seem to fixable within a reasonable amount of time. The largest group of non-typo style problems seems to be long descriptions which are not useful on its own. Examples: bnlib1: Assembly language routines are used to make this library very fast. initscripts: These scripts are meant for standard Debian/GNU/Linux installations. ld.so.preload-manager This script is written to be used with the installation of libsafe, but perhaps it could prove itself useful for more things ;) trr19: This is just a beta version. . Trr19 won't work with XEmacs. All of these do not fit the following policy clause very well. The extended description should describe what the package does and how it relates to the rest of the system (in terms of, for example, which subsystem it is which part of). I hope this helps, Jochen -- http://seehuhn.de/ signature.asc Description: Digital signature
Re: Usability: Technical details in package descriptions?
In article [EMAIL PROTECTED] you wrote: But however long it takes, some concerted effort should be able to improve things a lot. I would be interested to help with this. Just file bugs for the above descriptions, I do that also if i find a description to confusing. Since we have no central source repository where one could make a quick run and update those strings we have to go with NMUs or patches, therefore nothing speas against using the BTS for that job. I think this is a good example for putting at least the base system in a central CVS could improve the packages quality. We could learn that from BSD or commercial distributions (I think even Fedora Core?). Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
