Collaborative development - thoughts wanted!

General Discussion
1

Hi everyone,

I’ve been having some discussions recently around how we can improve the alignment between our products and our users, and better enable the community (yes, you :eyes:) to be involved in collaborative development and testing processes.

I wanted to share some thoughts and ideas, and hopefully get some of yours in return :slight_smile:

Some Context

Blue Robotics as a company is designed around providing components for others to integrate, and platforms for others to work with, modify, and expand. By nature that allows our relatively small team to have an outsized impact, but it also means the community we’re supporting is filled with use-cases that we can’t possibly know everything about, so we’re reliant on (often quite limited) user feedback to determine whether we’re moving in the right directions, and what we should focus on next.

We already try to capture feedback in various ways[1], but some of those mechanisms are not very transparent about our engagement or progress on requests, it’s often hard to estimate/aggregate levels of interest on popular ideas, and they fail to capture much around what we’re doing right, minor issues that arise during operations, and which features are critical vs just nice to have.

Some Thoughts and Ideas

  • Transparency invites collaborative efforts, which help to foster community
    • Changes and revisions are currently tracked to a limited extent, but not consistently provided via notifications
      • Our recently introduced PCN system and our GitHub issues/pull requests provide this to some extent, but there are also longstanding issues around our software and firmware not announcing when new versions are available, or what has changed since the currently installed version
    • It could be useful to provide an aggregated list of feedback submissions that can be voted on for prioritisation
      • A virtual budget system could help to communicate and reflect resource constraints, while also encouraging genuine prioritisation
      • As an extension, it may make sense to have some kind of bounty system for community members to encourage others to contribute particular features and fixes
    • Feedback ideas should be trackable, ideally for general progress, but at least on completion (preferably with notifications of some kind, for people who want them)
  • Short term direction adjustments and prioritisation are easiest from actionable insights
    • How feedback is collected/requested likely has a significant impact on which feedback gets implemented (first / at all)
  • Feedback should be easy to submit, but not requested in annoying ways
    • Long forms and regular repetitions of similar questions are best avoided where possible
    • Feedback submission is often easiest when and where ideas and problems occur
      • Vehicle operation may be in remote locations, so being able to submit feedback to a local system (e.g. within Cockpit) which then gets shared during the next internet connection could be helpful
  • Consistency of information formats makes aggregation (and ideally submission) easier
    • Checklists and polls trade nuance for ease of input
    • Open-ended space for notes and/or discussion has the opposite tradeoff
    • Both can be valuable, but they’re useful for different things

What Next?

If you’re still here, and have thoughts or feedback on these ideas, please feel free to share and discuss in this thread!

In the meantime, I’m actively looking into some ways we can better facilitate beta testing of upcoming software features. That seems like low-hanging fruit to pick first, and if done well could inspire some improved development practices and community engagement, while also serving to increase confidence that our software is well-tested for and suited to the applications you are actually trying to use it for. Stay tuned! :slight_smile:

  1. e.g. passively through our product/feature request form, this forum, GitHub Issues, and sales/support emails; and more actively through occasional community polls and surveys ↩︎

4 Likes
Cockpit Beta Testing
2

Hi @EliotBR ,
I applaud you guys going out for feedback on this.
I think it would be useful to have a bit of a roadmap and a method of giving input and up/down voting features. This may already exists and I don’t know about it. I guess Github has this on the individual s/w component repos - so maybe some kind of overarching, big picture hardware/software roadmap and feedback tool. Tricky I know because of commercial sensitivities around disclosing product direction…
The BR forums seems active and BR is doing a good job of providing support and listening (even in situations I’d deem to be way out of scope for a product/component supplier!). How requests then feeds into product direction and priortisation could be made more transparent.
The Reef market place is a good move as is the BlueOS plugin marketplace. There’s a gap I see in providing a Cockpit plugin marketplace. I’m sure you guys have thought about that.
Anyway, that’s my initial thoughts - to hopefully kick-off the conversation.
Keep up the great work BlueRobotics!

1 Like
3

Yeah, that’s definitely a direction I’d like to explore. Given the fragmented information we already share about upcoming products I’d like to think there’s at least some scope for a consolidated space to share (and interact with) such information, assuming it can be done with room for ambiguity and limited information for things we’re unsure about and/or not fully ready to share.

I’m more inclined to a resource allocation approach. Thinking along the lines of category-based ranked choice voting, with multiple top selections. I.e. people can rank ideas by their preferences, and the collectively top ranked ideas are most likely to be worked on. Categories could be split along BR team boundaries, to reflect which things are likely able to be worked on independently, but also may not be required (e.g. rankings could be absolute, and just filterable by categories and/or tags). The idea then being that as things get completed (or have their status updated?) any rankers/voters get notified of that, and their preferences get re-allocated as relevant.

I’m not sure down-votes make sense, because a collective majority of fragmented interests probably shouldn’t be able to de-allocate resources/votes from a feature that is collectively important to several aligned people. That could be used to indicate some kind of moral or ethical disagreement with a feature being developed, but hopefully that won’t ever be necessary, and I feel like there are several other ways of sharing that feedback (so it doesn’t need to be baked into a prioritisation system).

Thanks! We definitely try to keep this as a community-fostering education space rather than just a visible product-support tracker. It’s much more interesting that way, and hopefully helps to welcome people into a supportive congregation of the marine robotics community (which we love to be a part of!) :slight_smile:

Yep - outside of areas with high enough demand that they make themselves known, I think we’re still figuring out how to collect fragmented feedback into consistent data that can more directly contribute to our product direction and prioritisation.

I think standardising some more of the feedback input (e.g. through some kind of feedback tool that we can use as a source of truth) will hopefully help us establish that pipeline more clearly, and ideally then share more about how different things contribute to it (and what people are asking for).

We agree! :smiley:

Every system has its limitations (e.g. I’m aware there’s some interest in ways to offer paid Extensions for BlueOS, which we’re still evaluating and thinking about how best to approach), but it’s great to have mechanisms that can facilitate easier and more scalable integrations, and it’s exciting that we can simultaneously help our users and support more of the marine robotics industry and development community by funnelling relevant components and software through our distribution channels.

Indeed. My preferred approach is expanding the BlueOS Extensions system with a file-based add-ons system that Cockpit (and all other BlueOS-Extension-like software) can then make use of, but we’ll see what we end up with.

There are already some related efforts that have gone into features like Cockpit’s automatic external iframes, but they’re not as fully-featured as integrated widgets, and things like DIY widgets and custom joystick SVGs don’t yet have a hosted space for easy sharing.

Thanks for the thoughts, suggestions, and encouragement!

Much as we have an excellent team, we work best with access to diverse perspectives from the widely varied community that we’re trying to empower :smiley:

4

If users don’t mind data being shared automatically, there are ways, both manual and automatic, to find out things. For example, an integrated fault report. This could be automatically captured where possible/applicable or entered by the user. Blue Robotics would get data when the ROV is connected to the internet. The user would probably have to authorise the data.

Using configurations can also be an indicator to show popular/effective settings or help when asking for support. The ability to capture thruster data is great. A simple thruster map where you enter a date/time the thruster was installed. Some software then does math. This provides thruster hours and is valuable to both the user and BR.

I’m sure there are other ways. I built a robot with lots of feedback sensors. We gathered the data and used it to faultfind. I could tell what was defective without bringing it tothe surface. We added a switch so we could isolate in water and carry on working.

1 Like
5

A post was split to a new topic: Change tether deck cable colour

6

We’ve been thinking about this kind of thing recently in the context of Cockpit, whereby a user should ideally be able to submit various kinds of feedback (including product and software issues) while operating/offline, which then gets sent the next time the control station computer connects to the internet. To a limited extent brief feedback can already be submitted offline through the BlueOS simple report functionality, but that’s one-way (so doesn’t allow for discussion or progress/fix updates), and the BlueOS interface is ideally something users only need to interact with when adjusting configurations or setting up new hardware, and may not be available if there’s a major vehicle problem.

Fair point that some “submissions” could potentially be automatic, once fault detection mechanisms get more advanced. It makes sense that would need to be considered in terms of data privacy and corresponding user controls, like the existing aspects.

In Cockpit we’ve gone to efforts to make user configurations exportable/shareable, but less so in BlueOS and our other software. BlueOS does allow downloading system logs to help with making higher quality support requests, but uploading and investigating them is not a particularly streamlined process. There’s work going into improving that, but the support side of things is worth some extra thought.

Providing a space to share settings and other files is something we’ve considered before with discussion around an add-ons system for BlueOS / Extensions, although at this stage not much has gone into that besides thoughts. Popularity as a sorting/filtering metric we have also considered to some extent for the Extensions store, but it requires reasonable metrics for ratings and/or relative installation/usage stats. Some interesting spaces to explore further :slight_smile:

More generally, fault detection/reporting, usage tracking, and maintenance tracking/scheduling are things we’ve been discussing for a while, and definitely some areas that could do with a fair amount of improvement / consolidation - good points :slight_smile:

There’s some thinking that needs doing in terms of how those development loads are best distributed (e.g. between BlueOS, Extensions, Cockpit, and future cloud offerings):

  • It’s likely useful for a vehicle to keep track of its own maintenance history, but also have that backed up externally/online, and/or integrated into broader fleet management tools
  • Such tools should ideally allow integrations from things like BlueOS Extensions and product manufacturers/integrators, to enable non-BR components to still be tracked and managed
  • Online servers open up opportunities for post-mission analysis and fault detection, and more convenient sharing of data, but add management complexities around data usage rates and data privacy
    • Local, offline functionality is a hard requirement for some users, which shouldn’t needlessly reduce their capabilities
    • Things like advanced fault detection models may be possible to develop/train, but doing so is likely dependent on compiling (potentially large amounts of) data into an accessible resource, that people would need to consent to contributing to for it to be viable