If you find an issue with ROS or ROS-related software, or you wish to request a feature, please use the appropriate issue-tracking system to file a ticket:
On a wiki page for a package or stack there should be a link at the bottom pointing to where to file tickets.
Below is a list of common organizations on GitHub for ROS packages.
There are several GitHub organizations which host many of the core ROS packages. Below you will find a list of the most common ones with a quick description of their focus:
ROS Android - Android apps based on ROSJava. Also see ROS Android PR2 and Link to Play Store
ROS Core - Core ROS libraries and tools such as standard messages, the build system catkin, the ROS clients roscpp and rospy, actionlib, pluginlib, nodelet, etc
ROS Drivers - Drivers for sensors and other hardware
ROS Geographic Information - Packages for managing geographic information within ROS
ROS GitBuildPackage (GBP) - Git Build Package style repositories for the release pipeline.
ROS Infrastructure - Foundational tools for ROS ecosystem such as package release (bloom), build farm scripts, documentation generators. Most of these are backend, non-user facing repositories.
ROS Java - The Java ROS client library and tools
ROS Manipulation - Packages relating to manipulation and the manipulation pipeline.
ROS Interactive Manipulation - Packages relating to interactive manipulation and the manipulation pipeline.
ROS Perception - Tools for perception and vision
ROS Planning - Navigation and path planning related packages including navigation and moveit
ROS Robots - Packages to support robots which do not have their own organization (as listed below)
ROS Simulation - Simulators for use in ROS
ROS Visualization - Graphical tools to visualize data including rviz and rqt.
It is not required that if you are doing something related to one of these categories that your package be in one of the organization. And every choice of where to put a packages is always a judgement call for most packages could be multiply categorized. The goal of using these organizations is to facilitate maintenance so grouping software by developer communities is often the best way to decide where to host a package.






