| > i believe well meaning suggestions come from two types of people, those who don't know how to do it, and those who are to busy to do it themselves. That is true, but there are also other issues, such as: - Knowing most of what to write, but possibly missing some part of the code that you might not know of, which is needed to implement this feature. They might not accept the change, leading to further things below: - Possibility of breaking the interface and making it not compatible, especially with future versions of the official program if there are bit fields, structures, enumerations, etc that need to be extended. - Needing to maintain your own fork of the project. - If making multiple patches, making them to not interfere with each other. I had made a repository of unofficial patches of SQLite; currently only contains my own patch for non-Unicode, and list of links to a few others. However, later I should perhaps add also such things as documents about enumerations, etc. Depending what needs to be done, possibly forking it and breaking the interface might have some advantages (can avoid some problems with the existing interface), but also disadvantages (more complicated to maintain). > most of the time when i drop a suggestion then it's because it's a good idea but not a priority and i don't have the time to implement it, or rather it's not important enough for me to make the time and produce a patch. I had considered this, and I think that you can specify reasons for dropping a suggestion, as well as details of what might be needed even if it is accepted but not implemented yet. As an example, I had made this list: 0. It already has this feature, or this capability can be easily done by the existing features. 1. Yes, I will likely add it soon (and may be working on it already). 2. Yes, but it is not a high priority; it may be added later. 3. Yes, but more work will be needed before it is added. 4. Probably; more work will be needed, and/or design decisions must be made, before it is added. 5. Maybe, but I am unlikely to implement it by myself; if you provide a patch then it will likely be added. 6. Unlikely, but possible. More work will be needed, and I probably will not add it by myself but a patch may be acceptable. 7. No, I consider it to be a bad idea. You may make your own fork of the project if you want it, though. 8. No, it is out of the scope of the intended project. You may make your own fork of the project if you want it. 9. No, it is probably too complicated and not very helpful anyways. 10. No, it is probably impossible. Forking it probably won't help. 11. The request is completely impossible; in addition to being impossible, it might also be incoherent, incomprehensible, unethical, etc. In the case of bug fixes, it is a bit different, e.g. if you cannot figure out what is wrong, or if you do know what is wrong but you do not know how to fix it, etc. |