<div>Hi Everyone, </div><div><br></div><div>In reviewing the state of ROS one of the things that is commonly sought in the community is better visibility into the status of packages.  Whether packages are stable released software designed to be built on top of, or if the software is a one time release designed for a single experiment is sometimes very hard to tell.   Also as people consider deploying ROS outside of research experiments reliability becomes much more important.  </div>

<div><br></div><div>To be able to make this happen we'd like to review/rewrite the ROS QA process.[1]  And also while doing this we'd like to setup some verifiable tests to pass to achieve levels of certification, which can then be made visible on the wiki and/or in indexers to allow people to be able to have confidence in software that is downloaded.  </div>


<div><br></div><div>I'd like to kick off this process shortly after the groovy freeze, with a goal of having a working draft of the process and certification requirements by the end of October.  The process will likely include a couple workshops, virtual or in person depending on the distribution of participants.  </div>

<div><br></div><div><div>To address this issue, I'd like to put out a call for participation in this working group.  If you'd like to participate please contact me.  </div></div><div><br></div><div>Tully</div><div>

<br></div><div>[1] <a href="http://www.ros.org/wiki/QAProcess">http://www.ros.org/wiki/QAProcess</a></div><div><br></div>