I think you meant... (was Re: london.pm.org web site - facelifted (v2))
Jonathan Stowe wrote: I think you meant "I would submit patches" - strange how sometimes your keyboard goes wrong like that. No Jonathan, I don't mean that. At all. If I meant that I would have said it. Do you see? And I object to this attitude that one is not allowed to voice their opinion on a subject if the subject in question is some form of open/collaborative effort that one has not contributed to. There are plenty of things I'm good at. Web design isn't one of them. And at the same time that does not invalidate my opinion when it comes to usability of sites. I am, after all, a user. One who cares about ergonomics. People are, and should be allowed to say "I don't like it." as feedback to the people who are doing the work, otherwise, how do they know if the people they're making things for like the results? Since we all know there is more than one way to do it I would encourage you to remember that there is more than one way of helping to build something. And if you don't regard testing and feedback as worthwhile in that regard then I pity your customers and/or employer. This attitude is also, in my opinion, another reason the l.pm is sometimes a less-than-friendly place. Yours Sincerely, Nigel
Re: I think you meant... (was Re: london.pm.org web site - facelifted (v2))
Nigel Rantor wrote: And I object to this attitude that one is not allowed to voice their opinion on a subject if the subject in question is some form of open/collaborative effort that one has not contributed to. I have no objection to you voicing your objections. And at the same time that does not invalidate my opinion when it comes to usability of sites. I am, after all, a user. One who cares about ergonomics. I also care about usability and ergonimcs. But that's one of the reasons why I'm leaning more towards fixed width designs. Readability drops off quickly when columns get wider than 12-15 words. So a liquid design that expands to 1600+ pixels is neat from the "cramming content into every bit of available real estate" perspective, but it really sucks from the usability side of things. Of course, typographers have know these things for 100 years or so and we in the web world are only just figuring it out. And if you don't regard testing and feedback as worthwhile in that regard then I pity your customers and/or employer. I welcome testing, feedback and comments, both good and bad. But it is worth bearing in mind that this is voluntary work and any complaints that are *too* vociferous may fall on deaf ears. Or be met with directions to the subversion repository :-) My customers are, of course, encouraged to complain as loudly as they like, and demand any kind of colour scheme, layout, or any other feature that they care for. But then, that's what they're paying for. Business vs pleasure. A
be excellent to each other (was Re: I think you meant... (was Re: london.pm.org web site - facelifted (v2)))
On Sun, Dec 14, 2008 at 09:24:05PM +, Andy Wardley wrote: > I welcome testing, feedback and comments, both good and bad. But it is > worth bearing in mind that this is voluntary work and any complaints that > are > *too* vociferous may fall on deaf ears. Or be met with directions to the > subversion repository :-) > > My customers are, of course, encouraged to complain as loudly as they like, > and demand any kind of colour scheme, layout, or any other feature that they > care for. But then, that's what they're paying for. Business vs pleasure. In September, I went to the memorial service for the head of music from my school, who died from cancer earlier in the year. One of the things that stuck in my mind was another teacher saying that "one of the most important things Colin taught me was that you can never say 'thank-you' enough". In this context it was thank-you to the other teachers, for volunteering their spare time to help organise and participate in extra-curricular activities. Things that they didn't need to do; things that they got no payment for. But a choice that they made that benefited everyone greatly, and something you didn't want them to stop doing. The issue is that if the first contact you get from a complete stranger seems to be implying that "your software sucks", *and* that they want help for free, it doesn't really endear them to you. It doesn't help that e-mail is plain text, and doesn't have the emotions or nuances of tone of voice, let alone facial expressions or body language, so it's very hard to know how tongue-in- cheek someone's comments are. Smileys, love 'em or loathe 'em, are actually important. But so is phrasing things carefully, so that people can't misinterpret your intent. For example, here's a spectacularly bad way of doing it: http://rt.perl.org/rt3/Public/Bug/Display.html?id=38744 Perl 5.8.8 contains an incompatible and undetectable change to the public, documented POPpx macro--the macro no longer assigns the length of the popped value to n_a. This ChangeLog entry appears to be the relevant one: [ 25525] By: nicholas on 2005/09/21 09:32:33 Log: Integrate: [ 24748] Convert POPpx POPpconstx and POPpbytex to use nolen macros. Elminate a lot of Cs Our code was calling POPpx then using the value assigned to n_a to allocate a buffer into which the returned value was copied. After upgrading to Perl 5.8.8, the code still compiled, but due to the POPpx change then passed the now-uninitialized value of n_a to the allocation routine. Fortunately, the value that happened to be in that memory location caused the allocator to throw an exception, but it could just as well have allocated a short buffer. It was highly irresponsible for someone to make an incompatible change to a documented, public API without ensuring that code depending on the old API caused the compile to fail. The macros should have been renamed or they should have been changed to take a different number of arguments. There is no telling what third party code might now have buffer overflow security bugs due to this incompatible change. Then read my reply. It starts "Thanks for reporting this bug." This was not the first phrase that sprang to mind on reading it. But it's important to remember that we're in this for the long term, and that you may have misinterpreted the sentiment of the tone of the message. Now, most people are not that inconsiderate (including the individual responsible for that report in all his other bug reports), but the cumulative effect of a lot of people turning up with reports that are 100% bug and 0% thanks wears you down. It's one thing if they come from someone you recognise as giving something back to the community, be it software, organisation [eg Kake brings us pubs, MDK brought us the LPW], or just donations [Venda and AntibodyMX brought us beer*]. But most seem to just be "take", and you start to wonder why you're doing it, and why instead you shouldn't go any do something else that might be more fun, but less altruistic. Hence partly why 5.8.9 [now wending its way to CPAN - you read it here second] brings you a brand new utility - perlthanks. It lets you send bug report antidotes as easily as bug reports, if you are so inclined. If people want to use it send thank-you message to perl-tha...@perl.org that's great. If people want to say thank-you to me for 5.8.9 by buying me beer, that's great too** (although I can't drink that much, and actually I'd prefer sashimi - mackerel sashimi - I'm a cheap date). But if you like Perl, and want to say "thanks", probably the most useful way to say it is to do something no-one else can do. Write about your own Perl Success Story. Counter the "Perl is specialist biologist word for stable" zombie-meme that wants to eat everyone's BRANES***. It doesn't matter if it's an informal chat to some colleagues, a lightning talk a
Re: be excellent to each other (was Re: I think you meant... (was Re: london.pm.org web site - facelifted (v2)))
2008/12/14 Nicholas Clark : > And if I know that you contribute back it's far more likely that I'll > investigate your bug reports straight away, rather than putting them off. > For example, that's why Andy got a very full initial answer very quickly. Mind you, some people will still ignore you. Case in point: the previous company I was working at, someone had made a design decision at some time in the past to use a particular library for XML handling. It was not a bad library, the interface for building XML was particularly elegant - somethings that needed careful work with others were straightforward -but as our usage of it got heavier, cracks started to appear. It performed badly under load, and while you could improve this, the method was a little arcane and was passed around the dev team almost as a secret. Then, I found an area where it was just plain buggy. Talking to the Senior Dev about this he said, yes, they'd been trying to contact the developer involved to try and fix it, with no response. The company involved had too much code to change libraries, too much testing and arbitrary changes would have been needed. I took a pragmatic approach, and submitted not only a bug report for it, but an actual diff to fix the bug (it really was a trivial change, but shared fixes are in the community interest). Since that time, not only is the list of bugs in the cpan tracker still growing (a check says 11 - some 5 years old!), but a new version came out early this year - with that bug still in place! Said library has an average review on 2 stars - that's 1 review of 4, and two of one Bottom line: Just because you play nice, doesn't mean anyone else will do likewise. Ignore them, continue on your own path, if you're doing what you feel is right. ($diety help me, I'm paraphrasing Walden. Oh, that it came to this) -- No train here, but still: The sign says: "Ready to Leave" Normal service, yes?
