Changes between Version 4 and Version 5 of UsingThisSite

Timestamp:

Sep 23, 2007, 1:05:45 AM (16 years ago)

Author:

John Bailey

Comment:

Add a question, eliminate some WikiFormatting that doesn't work in lists, and make a few other tweaks.

UsingThisSite

@@ -12 +12 @@
 == The Ticketing System ==
 
+=== Where do I submit bugs, patches, translations, or feature requests? ===
+[/simpleticket Here].
+
 === Why are so many enhancements closed as "Won't Fix?" ===
-There are three basic arguments for leaving enhancement requests open indefinitely (or in other words, until they happen):[[BR]]
- 1.  Leaving it open might inspire someone to write the patch or plugin necessary[[BR]]
- 2.  Leaving it open might allow someone to comment on the existing request instead of submitting a new one[[BR]]
- 3.  Leaving it open allows for the fact that one or more developers may at some point change their minds.[[BR]]
-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 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.  
+There are three basic arguments for leaving enhancement requests open indefinitely (or in other words, until they happen):
+ 1.  Leaving it open might inspire someone to write the patch or plugin necessary
+ 2.  Leaving it open might allow someone to comment on the existing request instead of submitting a new one
+ 3.  Leaving it open allows for the fact that one or more developers may at some point change their minds.
+Each of these is a decent argument, and together they might be seen as persuasive.  There are, however, reasons for closing enhancement requests aggressively:
+ 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 [http://www106.pair.com/rhp/free-software-ui.html here],  [http://ometer.com/features.html here], and [http://www.actsofvolition.com/archives/2004/april/theriseof here].  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?'"
+ 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).
+ 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.  
 
 We have devoted considerable space to this question because we do '''not''' want to discourage ticket submissions.  We just operate with a finite ability, a finite amount of time, and a finite number of people able to contribute.  This means that most requests, particularly those that could exist as plugins (protocol or otherwise), will be closed.  That being said, a good many fine ideas come from people not already involved with the project, and some things that are rejected might be accepted if they were presented in patch form instead of request form.  This is particularly true if they come from someone who has demonstrated a willingness to work with us, stay the course, and contribute time and time again.