+1 for using wiki categories. A quick check makes it look like that's
either not supported or enabled, but I think it would be a very useful
feature. One of the strengths of ROS is how easy it is to mix and match
components, but there's currently no easy way of finding functionally
equivalent components.

-Dan

On Fri, Jul 20, 2012 at 2:17 PM, David Lu!! <davidvlu@gmail.com> wrote:

> Thanks everyone for your feedback to my idea. There's a lot of good
> conversation here.
>
> The conversation has strayed a little bit from my original idea of
> ways to find common holes in the ROS package coverage. My experience
> with Uservoice was on a much smaller project, and I agree it probably
> won't scale well. However, in response to Thomas's comment, I think
> you and I have both have had experience with spending time on a
> personal need for a package (pr2_python), only to discover that other
> people needed it and were working on it. I'd love to see a solution to
> that problem that got people developing for ROS at different sites
> communicating more and theoretically collaborating more.
>
> As for the bigger problem of maintaining the wild ROS packages: I echo
> Jonathan's sentiment about contributing to others' stacks being
> painful at times. The fact is, for better and for worse, the ROS.org
> wiki hierarchy is very flat. This means on the plus side that everyone
> is able to contribute on equal standing. The downside is that, beyond
> self-created stacks, there is no categorization of packages. That
> means
> A) There is no central repository for all arm_navigation packages (for
> example) (other than search, which isn't wonderfully functional)
> B) There is no way to rate packages/stacks (as has been discussed above)
>
> I think there might be a suitable underused feature from the wiki in
> the category feature. Wikipedia allows for easier browsing by looking
> up categories of articles
> (http://en.wikipedia.org/wiki/Category:Robotics_companies). This could
> be tied to the answers.ros.org tagging feature in some way as well. It
> would be nice to do a search for MappingAlgorithms and Stable.
>
> I also approve of using statistics to differentiate the various
> stacks. I was actually thinking about this previous to this
> discussion, resulting in my work with manifest_cleaner
> (http://ros.org/wiki/manifest_cleaner) and my recent question about
> the ROS.org indexer
> (http://answers.ros.org/question/39049/ros-wiki-indexer/)
>
> -David!!
>
> On Fri, Jul 20, 2012 at 11:09 AM, Bill Morris
> <bill@iheartengineering.com> wrote:
> > On Fri, 2012-07-20 at 09:05 +0200, Jonathan Bohren wrote:
> >> On Fri, Jul 20, 2012 at 2:00 AM, Geoffrey
> >> Biggs <geoffrey.biggs@aist.go.jp> wrote:
> >
> > ...
> >
> >> ROS is old enough now that there are a lot of packages, even
> >> wg-spawned packages, whose owners have moved on to other things. I'm
> >> talking from experience on this, since I recently tried to fix what I
> >> considered a serious flaw in a wg-hosted package, only to find that
> >> the names listed in the package manifest are no longer the maintainers
> >> and the person listed in the stack manifest is (understandably) too
> >> busy to deal with my  patch. I find myself blocked, and I could fork
> >> it, but this package is currently distributed with the debian packages
> >> and I think creating a new package with a new name will just lead to
> >> confusion and fragmentation.
> >
> > I have had similar experiences waiting for patches to land.
> >
> > For part of this, I think there needs to be a clearer process for
> > gaining commit access or forking for "core" ros packages.
> >
> > While it doesn't solve the documentation issue, Debian has an
> > interesting approach with the idea of a "Request for adoption"
> > http://www.debian.org/devel/wnpp/
> > http://wnpp.debian.net/
> >
> > Perhaps another approach would be for maintainers to avoid/remove
> > namespace conflicts for unmaintained packages. ie. linefollower ->
> > mylab_linefollower
> > --
> > Bill Morris <bill@iheartengineering.com>
> > I Heart Engineering
> > http://www.iheartengineering.com
> > <3
> >
> > _______________________________________________
> > ros-users mailing list
> > ros-users@code.ros.org
> > https://code.ros.org/mailman/listinfo/ros-users
> >
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>