LinuxCon: Some advice from Uncle Dirk

LinuxCon: Some advice from Uncle Dirk

Posted Sep 24, 2009 4:42 UTC (Thu) by JesseW (guest, #41816)
In reply to: LinuxCon: Some advice from Uncle Dirk by Baylink
Parent article: LinuxCon: Some advice from Uncle Dirk

Thank you. I appreciate you taking the time to explain this; I've also noticed similar issues.

Let me expand on my understanding of the alternative to to this problem, i.e. the process followed by projects that do pay attention to RFEs (Requests For Enhancements, for those following along at home). The maintainers of such projects consider their jobs to be designers/systems analysts, although with the job of selecting the good from what they are given, rather than being able to directly demand it of subordinates, as is done in traditional cathedral-style projects. The projects attract a number of coders who are willing and able to recognise itches when they read RFEs, even if they themselves hadn't felt the itch before. And finally, such projects have users who are aware, able and willing to send in their observations of the problems and rough-edges they encounter and receive courteous appreciation for doing so. Is this impossible? Hardly. Are there many, many projects that arn't like this? Certainly.

While I agree that many FOSS projects don't recognise the value of suggestions without code, I'm still uncertain why you consider that having a badly structured interface doesn't screw up "the base function[ality]". I would be surprised to hear of a project that refused a patch fixing a interface wart on the grounds that "interfaces don't matter". There certainly can be really big and long arguments over whether a particular aspect of an interface is a wart or not, but that's quite different than refusing to fix a wart that everyone agrees is there.

As for the examples you mention with Knetworkmanager -- those certainly sound like irritations that most folks using it would like to see gone -- likely including some developers. It is frustrating that the response to filing a description of the problem, or even a specification of how the problem could be resolved, implies that no-one but you is responsible for coding it -- it would be much better (and I've seen this) if the response was, "Thanks for clarifying the solution to this apparent problem; that will make it easier for whoever has the skill and time to implement it." But asking for a patch (from the original submitter or someone else) is a reasonable request -- the code needs to come from somewhere.

Does this match up with what you've been trying to express?

---

(Log in to post comments)