On UserVoice: ~~~~~~~~~~~~ -1 The problem is not the lack of tools. ROS already has too much different websites and publishes too much information. Also, is this really how we work? I mean I am working on my research topic and when this is possible, I am contributing to ROS. Who seriously could answer to a suggestion such as "I would like PR-2 to do XYZ". The other case is a stack-specific, technical, suggestion, in this case, one should refer to the maintainer directly. On the ROS software organization: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Please remind yourself one thing: we are *researchers*, not engineers. We are not paid to maintain code. Keeping a package up-to-date in ROS is something which is extremely time consuming and need high proficiency in a lot of technical domains. Maintaining packages in ROS is usually considered, if you're lucky, as strong self-devotion to science, and in the other cases as a questionable activity which prevents you from doing "real" research. To sum up, don't try to make people maintaing their softs on the long term, you'll be disappointed :) What we *should* do is cope with it by the following means: - identify valuable piece of code, - identify /currently/ well-maintained and well-engineered packages, - promote a core set of packages which are really crucial This is like the "main" vs "universe" repositories of Ubuntu. We can't just put everything on the same level like this is the case currently. What we should *NOT* do: - remove obsolete packages from the wiki or make it hard to register software in it. I mean, we won't stop google bots, if there is deprecated (or bad!) software, and there will be, we also need to idenfify them and _tag_ them: "*This* is not maintained anymore, you *should not* use it." Then, we can provide alternative packages to ROS users and keep things clear. As for the repository rights, we don't need them. Open source packages have been forked for 30 years of *NIX history, IMHO this is the only practical solution. Especially now, with Git and GitHub, it has become so easy! In practive, my advice would be: - close as much pages as possible to help people find reliable information. - consolidate the current websites into one coherent entity. - find a way to aggregate tickets from other systems such as GitHub - encourage people to add their stack to the wiki: we need to keep a trace of all the developments to avoid duplicating efforts - create different stack "quality levels": -- -1: deprecated -- 0: experimental / work in progress -- 1: released -- 2: core The information is already here, in the manifest file, but we need to motivate people to make releases and go through the Q&A process. I think the best way to do that: link the stack "quality level" to its visibility in the wiki. Experimental code should come with a big red warning saying: "maybe it'll work, but probably it won't" ;) ...and should not be listed by default when you browse the package list. - we really need more entry points in the ROS wiki to help people finding the "good" packages and realize what they can achieve by using ROS. I.e. the well-maintained software should be listed on a specific page. We should put a lot of efforts on this page design as this /is/ what will make people want to use ROS. Each time I send someone on the wiki to learn ROS, he comes back to me after finishing the tutorials and tell me "ok and now what? when will I begin doing real robotics?" The documentation has been designed for people using the PR2, if this is not the case, finding relevant data to design its own architecture is extremely difficult. PS: Even though there is a lot to do, the WG team has been incredibly helpful since I started working with ROS. Kudos particularly to Ken and Vincent who found time to help me. -- Thomas Moulard