Changes between Version 3 and Version 4 of UsingThisSite

Timestamp:

May 5, 2007, 10:44:35 PM (17 years ago)

Author:

arhart

Comment:

fix typo

UsingThisSite

@@ -19 +19 @@
 Each of these is a decent argument, and together they might be seen as persuasive.  There are, however, reasons for closing enhancement requests aggressively:[[BR]]
  1.  Many developers believe that there is a sort of "cost" associated with each preference, each menu item, each button.  That the increased code complexity has a non-trivial cost (in time to debug, and need to do so), and that the increased interface complexity will eventually get in the way of users.  Many even argue against the concept of an "advanced user."  This line of argument is developed at length in  http://www106.pair.com/rhp/free-software-ui.html ,  http://ometer.com/features.html and http://www.actsofvolition.com/archives/2004/april/theriseof.  It is also embodied in the following quote from Linus Torvalds: "the question is never EVER 'Why shouldn't it be accepted?', but it is always 'Why do we really not want to live without this?'"[[BR]]
- 2.  As developers and maintainers of Pidgin, Finch and libpurple, we have a limited amount of time available to spend on the enhancement tracker, particularly when so many bugs in the existing code require attention.  As the database grows in side, it becomes harder and harder to be able to remember, much less find, any given ticket in the midst of so many others.  This in turn results in the inability to detect and close true duplicates.  There are only two ways to combat this: closing requests that will not be implemented, and closing requests as they are implemented.  The two, as you can see, go hand in hand.  You can only close requests as they are implemented if you can find them, which in turn depends on closing ones you have no intention of implementing (and thus keeping the database of open tickets small).  [[BR]]
+ 2.  As developers and maintainers of Pidgin, Finch and libpurple, we have a limited amount of time available to spend on the enhancement tracker, particularly when so many bugs in the existing code require attention.  As the database grows in size, it becomes harder and harder to be able to remember, much less find, any given ticket in the midst of so many others.  This in turn results in the inability to detect and close true duplicates.  There are only two ways to combat this: closing requests that will not be implemented, and closing requests as they are implemented.  The two, as you can see, go hand in hand.  You can only close requests as they are implemented if you can find them, which in turn depends on closing ones you have no intention of implementing (and thus keeping the database of open tickets small).  [[BR]]
  3.  History tells us that while there are some users who will search the tracker for similar issues, many users will not.  This means that time *must* be spent detecting duplicate reports.  This is easier to do if the number of such reports are small.  It also tells us that if it grows big enough, developers will ignore the tracker, considering it a waste of time to attempt to do anything with the tickets in there when so many similar reports will be unfound and remain open.  While this means that some requests will be closed many times, it also means that each request has a better chance of having *any* sort of response.