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."
{^_^}
--
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
