These days lots of software emerging in the ROS ecosystem, but really hard to be notified when they become available. I’ve found some nice packages by accident in the last year, but wished I’d found them a year or more earlier when they were first released. Traditionally some folk used to use ros users for announcements but that is not oft being used any longer and is non-ideal since it gets lost in the history and I expect some people are reluctant to notify to an entire list.
I’d like to see a category here for that effect. Would be great for notifications and for scanning backwards to see what has hitherto been released. There is the Projects category already, but I would prefer to leave that one as a long running discussion forum on interesting projects while this new category would be strictly about announcements and not have them crowding each other.
Futhermore, I would like to see it set up so that when a package is announced, the author makes a new thread for it. Then when new releases are made, they make a reply to the thread. No one else is allowed to make a post in the thread (in other words, it’s not for support). This structure would make it easy to find new packages release recently (scan the thread titles) and also easy to find the details of the latest release or some previous release of a package (scan messages in the thread).
+1, I was just thinking of suggesting this the other day.
I would allow discussion in the announcement threads though. Not for support obviously (if that becomes a problem, the thread could be locked after a couple of days if necessary), but for discussion and feedback following the announcement.
BTW, this category shouldn’t be restricted to new binary releases, right? IMO a package should also qualify if it’s only available as a source package.
I feel the biggest challenge is to actually get people to post in the first place
True, but I think people have been actively discouraged to post too many messages to ros-users in the past. I’m in the same boat as @Daniel_Stonier: I found out about amazing packages (or amazing new functionalities, like topic statistics) only a year or more after they were initially released. Since there weren’t even announcements to ros-users for those great things, it made me reluctant to announce stupid little driver packages to ros-users, because they are not relevant for 99% of all people (unless you happen to own such a device, in which the information that a driver for it is now available becomes very relevant).
Perhaps the switch to Discourse will encourage people again to post more announcements, even for small packages.
+1 to have a place to announce release of small packages. I also accidentally found some nice packages to use last year.
Also how about having a +1 or like counts for each package? Then it should be easy to generate statistics like most viewed package in a month, or top-grossing package. This will help to understand that what packages are being loved by developers. It also may encourage the maintainers to continue the package development.
Yes, I guess so. My reply shouldn’t really have started with a “but”, sorry about the confusion. I think what I was trying to say is that perhaps the biggest hurdle in getting people to post their announcements has already been removed by dropping the “do not post unless your message is vital” policy when switching to Discourse. But I could be wrong.
Ok, seems like there are enough people surfing the same wavelength, so I’ll draft a starting point for some more concrete guidelines that I feel would be useful here. Feel free to discuss.
Announcements can be for a new release or a major update to an existing release. The point here is to notify people when there is something significantly new and both count towards this.
One thread per software release (or major update)
Some initial banter to guide people in the right direction for the release is fine. Technical questions, especially later, should be directed towards ROS Answers. Design questions/feature requests should be directed to the issue trackers or if large enough, open a separate category here on discourse.
Expressing emoticons or brief opinions about the release is fine.
Binary releases only
I’m not strong on 5) but releasing binaries on the OSRF build farm isn’t a difficult process, and it’s a small step that goes a long way to making things easy for users. We should encourage that!
Statistics/thread monitoring - I’d leave this to later. Just get things rolling first and see what pans out.
“5. Binary releases only” … “releasing binaries on the OSRF build farm isn’t a difficult process”
Just and FYI on that one. The build farm is totally foreign to people like myself who have not done it before. The requisite tutorials / documentation is not sufficient to get many package developers over the fear of messing something up.
Back to the OP, I like the idea - with two points:
Very quickly it will fall apart if it is not well organized and easily searchable. This may mean having some type of recommended template to what should be included in an announcement. e.g. package name, short description, availability, where is can be found, any prerequisites, hardware dependencies, etc.
I’m sure there are users like myself who did an internet search and found “ROS Answers” and never knew of “discourse”. These two entities are very independent - to the point they have separate registrations - and yet they are very symbiotic.
This is a good idea, and I think it’d be a nice way for people to get the word out about software they’re working on.
However, I agree that such a list should encourage posts about software that isn’t released in binary form as well. If someone stumbles across a source package and is interested enough in the project to want a binary release, they can work with the upstream developers to make it happen (especially if the downstream user already versed in the packaging process.) Packaging isn’t difficult, but it is a different skill set, and not everyone is interested in learning it or taking on the additional package maintenance burden. ROS could take a page from Linux distributions here, where the packagers are mostly independent of the software projects, but work with upstream to make the software available.
On a related note, to discuss improving the ROS’ already-amazing infrastructure that has helped us (semi-)automate non-coding tasks, I opened some tickets. Ideas behind is that package indexing and package’s wiki page are the keys that help us to find, reach existing packages.
I understand the points about packaging and they are well made.
Putting that to the side for the moment - I am concerned what may happen if there is no barrier to posting. In their excitement, it may become inundated by posts from devs who may have no serious inclination towards maintenance nor raising it to a reasonable level of usability/quality. Nothing wrong with such exuberance, I like to see that in an open source dev, but it could make it unusable for various groups who need the category. I’ve been running a team for the last three years working on next-gen products, and I would not have had the time to delegate on testing N ‘promising’ releases to find the one that is actually at a point where we’d jump in and contribute/use. As such, my perspective is somewhere in the middle. I imagine the bar would be different for a product team (high) and again for a research lab (low).
For me, packaging was a sign that this is usually maintained, has activity on the issue trackers, has dealt with the small problems like install rules and such. Of course, doesn’t make much sense if packages and source maintainers are separate.
Perhaps we can make use of tags to assist here, e.g. ‘binary-release’, ‘source-release’, ‘developed’, ‘<1.0’, ‘1.x’, and worst case scenario, put a human(s) in the loop to help check tags/veto low-level or plain noisy announcements.
As you said, there’s a lot of metrics that can contribute to deciding which packages are well supported and can be relied upon, and which were dumped on github by a grad student 3 months before graduation and will never be touched again. The availability of binary packages is certainly one metric, and may be a reasonably strong one. You outlined some other ones as well.
Part of curation is conversation - sharing with the community which packages people rely on for their projects, which have been tried and should be avoided, etc. That kind of information is hard to glean from github issues, and threads on ROS answers are hit and miss in this regard (has anyone ever asked, did someone who knows the answer see the thread, is a 5 year old answer still valid, etc.)
I think a software release announcement list would help with the curation problem. If software releases are being announced fairly regularly, that’s a positive indicator that the software is being looked after. Release announcement threads also give a venue for other users to make public comments on the releases, which lets us know that other people are using the package successfully. Tagging and enforcing some kind of experimental/developmental/stable spectrum and source/binary indication would go a long way towards satisfying your concerns of only being interested in high quality software.
For what it’s worth, that information could also be enforced through REP, by e.g. mandating the use of semantic versioning or adding stability and supported rosdistro metadata to package.xml files. I think that’s a separate conversation though.
I think I agree with all of @Daniel_Stonier’s points. However, perhaps we should first get people to post here at all before taking measures to deal with an expected flood of posts.
Also, having a binary release is only one sign that the package is high quality. This rule would exclude such projects as Google Cartographer, which are high quality, have a good test coverage + documentation, but no binary ROS release.
Anyway, I don’t care too much one way or another. We can still change the rule later if it doesn’t work.
I think tagging is better than restricting to binary releases at this stage. I do not think that we will have such a huge quantity of announcements that it will be a flood control problem. When it gets to that point, the policy can be revisited.
Part of the goal of moving to this forum has been to increase the communication within the community and I’m glad to say it has gone noteably up. As an aside there’s some rough stats here
But if you have suggestions about how to incentivise more posting and announcements that would be great. But I think that one of the biggest things is to just generate more content. Content draws people, people who are here post new things, which draws more people.
Just a point to the Off-Topic binary releases: After spending many hours trying to grasp all required aspects of releasing an existing ROS package as binary release, Matthias, a student of mine, has been working on http://wiki.ros.org/ROS/ReleasingAPackage
This is still WIP, but contributions, comments and “documentation testing” is highly welcome.
Then it should be easy to generate statistics like most viewed package in a month, or top-grossing package. This will help to understand that what packages are being loved by developers. It also may encourage the maintainers to continue the package development.