Hi Robert
I understand fully what you mean. I am aware of the exceptional work you
perform, and I thank you. But you misunderstood me.
Its not that they should write a tutorial or full documentation, but at least
spend 10-15 min writing 1-3 paragraphs on what the new class does and how its
used. 10-15 min. for a contribution that took days to code is minimal. Even
5min might do the job as well.
But when you dont ask for it you dont get even that. In the long run it saves
you and everyone else more time since many questions on the forums might be
avoided.
My proposal was not for development releases but for official releases.
Thank you for responding.
Dimi
On Wednesday, October 9, 2013 11:47 AM, Robert Osfield
<[email protected]> wrote:
Hi Dimi,
Features in development are features in development, documenting a moving
target simply isn't practical much of the time as the design and implementation
can both change. Once the features stabilise one can look more specifically at
testing and documentation, but in terms of code quality my focus will remain on
testing and debugging as it's code quality that is most critical in long term.
Personally I do try and write code that has clear naming, doxygen comments and
have examples that illustrate usage and test the actual feature, but rarely
have time to spend time creating dedicated documentation, such as extended
tutorials - my clients don't pay me to write extensive documentation, so
documentation has to vie with merging submissions, bug fixes, making releases,
website work that all comes from my own unpaid time. I also have family and
life outside the OSG so can't can't spend all my spare time documenting stuff
for others. Do you wish me to spend less of my time with my children for your
benefit?
I believe the same applies to others in the community. Writing tutorials and
books takes a great deal of time, it comes out from our spare time, demanding
others to do this as well as fix bugs/improve OSG features is possibly pushing
things. You want new features, new documentation all for free.
I think it's awesome when users write new examples and write tutorials.
however, I am not about to put a requirement on users to write full
documentation on new feature development that they donate to the community. To
put such an extra hurdle would result in less contributions.
Robert.
On 9 October 2013 08:34, dimi christop <[email protected]> wrote:
Hi,
>I wanted to say this for some time now. I am glad that we moved forward to new
>versions.
>What worries me is that there are a lot of changes going on but once again
>there is no documentation! So where does someone lookup what the new classes
>do? We should insist to the person who implemented a new feature, spend 15 min
>of his time and write a small document about it and provide an example,
>otherwise postpone the integration.
>The documentation through book,examples etc. had caught up to Osg3.0 by the
>end of 2012 but I see that there is building up a gap again. This might not be
>so obvious to you guys who run the changes but to me who do one upgrade every
>year for stability reasons these new features are puzzling, nowhere to find
>info. Referrals like read the source are not
valid anymore since OSG is not in its infancy, maybe its better to move a bit
more slowly but with better documentation.
>
>Dimi
>
>
>
>
>
>
>On Thursday, October 3, 2013 7:52 PM, Robert Osfield
><[email protected]> wrote:
>
>Hi All,
>
>
>I have just tagged svn/trunk for the latestest developer release 3.3.0. This
>marks the first developer release in the 3.3.x and our journey to final 3.4.0
>stable release.
>OpenSceneGraph-3.3.0, released on 3rd October 2013, key deliverables in this
>dev release are:
> * New osg::ScriptEnginer/osg::Script base classes for integrating
> scripting support
> * New Lua plugin that provides a LuaScriptEngine implementation that
> uses osgDB serializers via a new osgDB::PropertInterface class to
> passing/returning scene graph data to scripts
> * Preliminary V8 and Python script plugins, currently just run
> standalone scripts, no support for passing in/returning scene graph data
> * osgpresentation example provides a test bed for new
> PropertyInterface, scripting and osgPresentation work.
> * New osgUtil::RayIntersector class
> * Bug and build fixes
>source package : OpenSceneGraph-3.3.0.zip
>svn tag: svn co
>http://svn.openscenegraph.org/osg/OpenSceneGraph/tags/OpenSceneGraph-3.3.0
>OpenSceneGraph
>_______________________________________________
>osg-users mailing list
>[email protected]
>http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
>
>_______________________________________________
>osg-users mailing list
>[email protected]
>http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
