On Thu, 2011-09-29 at 20:15 -0700, jdow wrote:
> 1) Respect
>
> Writing software is not the slam dunk simple thing most people seem to
> think it to be based on their whining and carping. Please respect the
> effort. Dive in and try something simple yourself. A most interesting
> language is 2 year old child. Try to program one to make his room neat
> before he goes to bed. Discover you cannot leave out steps despite it
> being Such An Obvious Thing To Do "why do I have to spell it out?"
>
> 2) Accurate, clear, concise bug reports to help with debugging
>
> "It doesn't work!" "It's crap!" "It a piece of <stuff>!"
>
> Those do not help one bit.
>
> "If I do X followed by Y and Z the program throws a seg fault with this
> data set and this stack back trace." That can REALLY help. Even the first
> part helps without the stack back trace.
>
> "If I do A followed by B followed by C it seems to give me the wrong
> results, the file I was trying to copy appears in the wrong directory
> with a full path name of "/foo/bar/baz/brokenfile" instead of something
> like "/home/foo/bar/baz/brokenfile"." That can really help, too.
>
> Tell the developer what is wrong, how to create the problem, and any
> other symptoms noticed. And please do it without invective.
>
> Open Source developers work for less than peanuts, in most cases. Even
> when paid for it developers still need some ego stroking. Show your
> appreciation for their time taken by exercising item 1 on this list.
>
> 3) Clear and concise enhancement requests
>
> "ThwibblePwik is pretty good and would be better if you allowed the user
> to reorder, add to, and redefine its menu selection under the Farbling
> header." You're not telling the developer it's a piece of crap that
> could only be saved by a complete rewrite and by damnit it better be
> done tomorrow. You're suggesting an honest improvement, in an item 1
> respectful fashion.
>
> 4) Help
>
> "The documentation for Pwizzle sucks!" turns the developer off completely.
> Furthermore darned few developers can document for users at all well. (If
> you find one please let me know. {^_-}) That statement declares you have
> found at least one serious deficiency. You don't have to be a genius to
> look through, say the TigerVNC (what documentation?) support list, and
> collect the details that seem to leave users lost and write the fine
> manual rather than decry its absence. If you can't help write the manual
> at least try to be polite and probably less snarky than my sideways
> comment about TigerVNC above. Encourage somebody to take up the cause and
> produce the document. Help him find errors. Do some good.
>
> 5) When a problem you defined is fixed, offer up some thanks. Normally that
> would be the only coin you could offer the developers. That makes it really
> valuable. If you can care enough to contribute, I suspect you can find a
> way to drop a coin or two on the project to help finance the development or
> even a simple developer's party at a convention.
>
> 6) I am sure the Fedora developers could flesh this out with many more
> turn-offs that lead to poor enthusiasm and poorly developed programs.
> Listen to them, and other developers, when one of us decides, "I've
> listened to enough stinky stuff. I've had enough. I'm outa here."
>
> {^_^}
I wish I had any evidence that developers listen to the suggestions you
want to send them. I have seen no such evidence. I would assume most of
the people on this list are well aware of the difficulty of programming
secure and "foolproof" programs. Although "foolproof" programs don't
exist.
--
=======================================================================
RELATIVES!!
=======================================================================
Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@xxxxxxxxxxxxx
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
