On 15/03/2013 3:48 AM, Anders Hammar wrote:
Well, actually I think that people being new to a tool could be the
best contributors. Those being experts (at least engineers) very often
forget to explain some of the basics, which rookies really need
explained. So if you don't understand, figure it out (ask questions
etc) and then look at the text/docs again and add what's missing. If
you don't do it, who will?
I don't mind contributing by editing stuff or writing wildly inaccurate
impressions about what something does but I will only do it in
conjunction with the author or someone who is working on the code and
will correct my errors and provide explanations where the function is
obscure or the arguments have mysterious names or are missing.
I am not going to reverse engineer something.
I simply do not have the time to read code in a chunk of software that,
for me, is only a tool.
I am also usually passing through.
Once I get it working for me, I may never return to the project.
We use hundreds of open source libraries and utilities.
Ron
So, file those improvement tickets with patches (could be as simple as
stating the additional text in the ticket, it doesn't have to be a
patch file). Anyone can contribute!
/Anders
On Fri, Mar 15, 2013 at 2:44 AM, Ron Wheeler
<[email protected]
<mailto:[email protected]>> wrote:
How do you write documentation for something that you have never
used and have no idea what the options are?
I have worked on documentation for some projects but I can only go
so far without the active involvement of the author.
The biggest thing that I can bring is my ignorance which makes me
read what is there and ask good questions about WTF does it mean
and what needs to be said so that someone who did not write it can
use it.
It does require access to someone who can answer those questions.
Ron
On 14/03/2013 9:16 PM, Barrie Treloar wrote:
On 7 March 2013 23:24, Joachim Durchholz <[email protected]
<mailto:[email protected]>> wrote:
It's never a bad idea to improve the docs, but the real
problem is the
plugin docs. Many options are "documented" along the lines
of "frob: frobs
the build", which isn't very helpful. Few if any plugins
clearly document
the use cases they are built for, or (almost more
importantly) the use cases
that will not work. Of course, lifting the restrictions
would be even more
helpful than documenting them :-)
Have you considered enhancing the documentation?
If you are stuck with the tool you might as well help yourself
in the
future when you get frustrated, a side benefit is that this
also helps
others.
You are also welcome to file jira's with patches and unit tests to
remove those restrictions.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
<mailto:[email protected]>
For additional commands, e-mail: [email protected]
<mailto:[email protected]>
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
<mailto:[email protected]>
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
<mailto:[email protected]>
For additional commands, e-mail: [email protected]
<mailto:[email protected]>
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
