(Bah, pine[1] is unable to properly quote gmail emails, have to manually insert those >>>.)
> > This last sentence is unproductive and doesn't help. Please take a few > > minutes and look at http://live.gnome.org/CodeOfConduct > That's why it's not really nice to go on DEMANDING for action and > accusing some undefined group of people (in this case "gtk devs" and > "gtk+ people") of being lazy and unfriendly. Furthermore, in OSS the > responsiveness can be pretty much determined by the amount of input from > the requester: > - enhancement idea (slow response, if at all) If anyone has gone to the effort of reading the request it is not difficult to provide a fairly generic "thanks for your feedback" reponse, which is almost always better than no response at all and not too much effort to provide. A developer can go further and without giving any commitment to fixing the bug they can do various things to manage expectations and reduce the chance of a user getting annoyed by explaining the likelyhood (or unlikelyhood) of an issue being dealt with and warning that progress might be slow and help would be very much appreciated be it more information, patches, or encouraging their distribution to dedicate resources to help with a fix. > This is something that people usually don't take into account when they > feel bad about their patches being ignored and it would be nice to have > a reminder of that in the Code. Your points are well taken but given that we only get feedback from a rare few and patches from an even smaller minority the frustration should be entirely understandable. Any patch requires a lot of effort up front. An excellent Gnome developer might not find it easy to provide a patch for the Linux kernel not because of any deficiency but simply due to a lack of familiarity with the codebase. Slow response to patches is tantamount to turning away contributors, exactly the kind of active contributors most developers will say they really want more of. In the past the better projects have identified problems and asked people to come on board to help with bug tracking or taken on co-maintainers. The bugsquad do a great job of providing feedback where they can but all too often a lot of project specific knowledge is required (in some cases a Project FAQ section could help a whole lot). Again these are all just thoughts on how to take big problems and make them into lots of smaller ones we can share out. > P.S. Sorry but the abbreviation is just too hilarious not to make fun > with... :P Another title for that document would be preferable (and I said as much right at the beginning). There is more than enough machismo going around without inviting rude jokes or plain awful punning which just looks unproffessional. [Resisting temptation to make rude jokes but only barely.] -- Alan [1] Please send essays on why your preferred mail client is the best to Dave Null. _______________________________________________ foundation-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/foundation-list
