| 20 | | |
| 21 | | |
| 22 | | |
| | 20 | 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]] |
| | 21 | 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]] |
| | 22 | 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. |
| 24 | | 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. |
| | 24 | 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. |
| 27 | | We get emails from every update on every ticket, both those closed and those still open. We try to read and consider all of these emails. If you disagree with the decision that has been made regarding your ticket, post a comment that effect in it. Chances are we will read it, and consider reopening it. This is particularly true of your response is polite and well reasoned, instead of being a knee-jerk reaction or a flame. If you suspect that your post might have been missed, you can either post an email to the devel mailing list or open a new ticket. However, if the new ticket is shortly closed as duplicate or with a very similar rationale, then you should conclude that we simply disagree with you, and that a patch or 3rd party plugin is the only avenue left open. While we try to be as reasonable as possible, we simply cannot please everyone. |
| | 27 | We get emails from every update on every ticket, both those closed and those still open. We try to read and consider all of these emails. If you disagree with the decision that has been made regarding your ticket, post a comment to that effect. Chances are we will read it, and consider reopening it. This is particularly true of your response is polite and well reasoned, instead of being a knee-jerk reaction or a flame. If you suspect that your post might have been missed, you can either post an email to the devel mailing list or open a new ticket. However, if the new ticket is shortly closed as duplicate or with a very similar rationale, then you should conclude that we simply disagree with you, and that a patch or 3rd party plugin is the only avenue left open. While we try to be as reasonable as possible, we simply cannot please everyone. |
