Re: Addition to Code of Conduct (Was: Re: Integer pixel operations for gtk+?)

[Alan Horkan <horkana maths tcd ie>]

(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.