Raising money for Orocos.org remake

Better late than never!, answers inline...

On Tue, Nov 8, 2011 at 10:43 PM, Peter Soetens <peter [..] ...>wrote:

> To all,
>
> We are looking into contracting a Drupal design firm for re-theming and
> extending our sometimes loved/sometimes hated Orocos.org site.
>

Great idea!.

>
> We envision a site open to all users and component builders and which
> allows
> to find/create tutorials, documentation and Orocos software in general. For
> this to happen, we have some ideas, but we need your input too. I'd like to
> let the dust settle on the dev list before doing a broader announcement on
> the
> other mailing lists.
>
> This would be the plan:
>
> 1. Re-theme Orocos.org such that the basic navigation is solid. An
> inspiration
> is the ros.org site, which might be boring from a marketing point of
> view, but
> very effective for a software engineer.
>
> 2. Give libraries and components a place to live. We'd have a home for the
> Orocos libraries (the toolchain libs, kdl, bfl, typekits etc), the tools
> (lua,
> ros and orogen based) and the Orocos components.
>
> 3. Give tutorials a place to live. They are now scattered around the wiki,
> while they should be tied to a 'task' (logging) or a 'library/component'
> (log4cpp+OCL)
>
> 4. Generate content. Let users add a VCS URL and a build server tries to
> build
> the software and documentation on that url and pushes it back to the
> website.
> For each such generated page, there would also be an 'online content'
> section
> such that users can complement the generated docs with wiki-style texts.
> This
> 'hand written' section would then survive automated updates of the
> generated
> content.
> An example of such a generator is the lua script Markus wrote which
> generates
> mediawiki-style API descriptions of an Orocos component (properties,
> operations etc).
>
> The system would use tags and version numbers to tie the correct versions
> of
> documents to each other. The ROS wiki is again an inspiration, since it
> allows
> to edit pages for different versions of the same package[1].
>
> 5. Find a solution for the 'searchability' of Orocos.org. Due to the
> mailing
> list integration in the fora, searching something becomes hard, since
> you're
> overwhelmed with 'old' content. answers.orocos.org is a solution, but I
> wonder
> if we shouldn't jump into answers.ros.org . Maybe there are other options
> too.
>
> I'm also definately looking into making the rock packages part of the
> system,
> ie, integrate them into the index. Related to Rock, I'm also wondering what
> the apps/bundle system is about...
>
> The input we need now is:
> - what do you think are the priorities ?
>

1. Newcomers should have it easy to take the first steps: Installation
alternatives, basic tutorials, manuals. There should be little room for
ambiguity or confusion (eg. the distinction between the toolchain, what
Rock provides, the ROS integration).

2. Finding contents should be easy. Contents being manuals, tutorials,
existing components, etc. (eg. search components related to EtherCAT, or
trajectory generation).

3. Creating/modifying contents should be easy. Templates for the most
common usecases should exist and have high visibility. This will encourage
uniformity and consistency.

As you mention above, the ros wiki should provide some good inspiration, as
it complies with the above requirements.

You mention trying to not be "boring from a marketing perspective". What
are the goals from a marketing perspective?. Most Orocos users are
developers, so a fancy business-friendly site does not seem necessary. I'd
like the site to have a visually pleasing theme, but the marketing stuff
should probably live elsewhere, maybe on the sourceworks webpage?,
emphasizing clients and not developers.

> - what would you require from orocos.org to use it to put your own
> documetation/tutorials/... on ?
>

Priority 3. above answers this one.

> - which workflow would you prefer ?
>

A wiki is what first comes to my mind, otherwise any collaborative workflow
where people can add and manage content themselves.

> - do you know any online fundraising scheme besides paypall ?
>

Not until Peter mentioned indiegogo
[1]<http://www.indiegogo.com/projects?filter_category=Technology>.
They even have a nice feature called 'Fixed Funding' where you only keep
your money if your campaign reaches its goal, otherwise "all the money
raised will be refunded to the contributors and no fees will be incurred".

> - would you donate (even a small amount) and would you be glad to receive
> some
> gadget ?
>

Yes, if there is critical mass, which is why a 'Fixed funding' scheme
sounds appealing.

My 2 cents (maybe more in the future :).

Adolfo.

[1] http://www.indiegogo.com/projects?filter_category=Technology

> Peter
>
> [1] http://www.ros.org/wiki/rtt_ros_integration
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>

Raising money for Orocos.org remake

Also missed that mail ...

On 11/08/2011 10:43 PM, Peter Soetens wrote:
> We are looking into contracting a Drupal design firm for re-theming and
> extending our sometimes loved/sometimes hated Orocos.org site.
>
> We envision a site open to all users and component builders and which allows
> to find/create tutorials, documentation and Orocos software in general. For
> this to happen, we have some ideas, but we need your input too. I'd like to
> let the dust settle on the dev list before doing a broader announcement on the
> other mailing lists.
>
> This would be the plan:
>
> 1. Re-theme Orocos.org such that the basic navigation is solid. An inspiration
> is the ros.org site, which might be boring from a marketing point of view, but
> very effective for a software engineer.
Each time I'm looking for "how does ros does X ?" I have a hard time
finding anything. Maybe that's just me, but ...

> 2. Give libraries and components a place to live. We'd have a home for the
> Orocos libraries (the toolchain libs, kdl, bfl, typekits etc), the tools (lua,
> ros and orogen based) and the Orocos components.
>
> 3. Give tutorials a place to live. They are now scattered around the wiki,
> while they should be tied to a 'task' (logging) or a 'library/component'
> (log4cpp+OCL)
>
> 4. Generate content. Let users add a VCS URL and a build server tries to build
> the software and documentation on that url and pushes it back to the website.
> For each such generated page, there would also be an 'online content' section
> such that users can complement the generated docs with wiki-style texts. This
> 'hand written' section would then survive automated updates of the generated
> content.
> An example of such a generator is the lua script Markus wrote which generates
> mediawiki-style API descriptions of an Orocos component (properties,
> operations etc).
This mix of package-generated and wiki content sounds good. I don't want
a pure wiki-based system since we're often have to work without internet
connections

> The system would use tags and version numbers to tie the correct versions of
> documents to each other. The ROS wiki is again an inspiration, since it allows
> to edit pages for different versions of the same package[1].
That's provided that you have a versioning system. Rock does not, we
only have flavor (i.e. "in stable since XXX" would be a "version" for
rock). Or is it more flexible than that ?

> 5. Find a solution for the 'searchability' of Orocos.org. Due to the mailing
> list integration in the fora, searching something becomes hard, since you're
> overwhelmed with 'old' content. answers.orocos.org is a solution, but I wonder
> if we shouldn't jump into answers.ros.org . Maybe there are other options too.
If you consider "juming into answers.ros.org", why not going straight to
stackoverflow ? I was thinking about that for Rock.

> I'm also definately looking into making the rock packages part of the system,
> ie, integrate them into the index.
I honestly have mixed feelings about that. Rock is not Orocos, as
comments from e.g. Herman (and the feeling I have about the reception of
rock from the Orocos/KUL people on the ML) pointed out. I'm very open
for discussion about that point, and would not take the decision by
myself anyways. Also: I would be happy to be wrong ;-)

> Related to Rock, I'm also wondering what
> the apps/bundle system is about...
I still have to do a post on them. In general, they're meant to offer
system view(s) of the components, and in particular share system models,
in a way that is orthogonal to the package system.

> The input we need now is:
> - what do you think are the priorities ?
> - what would you require from orocos.org to use it to put your own
> documetation/tutorials/... on ?
> - which workflow would you prefer ?
> - do you know any online fundraising scheme besides paypall ?
> - would you donate (even a small amount) and would you be glad to receive some
> gadget ?
I'll be thinking about these questions in the next days.