I think it is a fair question - what is the purpose of the Roon forum?

To ask what is the purpose of the Roon forum. I assume there are multiple purposes — tech support, marketing, creating a community around the product, collection of feedback, etc. But one of them may not be open expression. And that I think threatens the feeling of community.

I refer specifically to the closing of the Folder Browsing thread. I’ll repeat what I have said many times, being that I would not benefit much personally from the implementation of folder browsing. People may differ on opinions as to the desirability of this as a feature, and clearly do. My point in participating in the thread was that I felt as a matter of principle that many on the anti-side were stifling useful dialog and I also do feel that Roon should as a general matter be more of an open standards application as regards work done in curating one’s collection.

I was shocked and saddened to see that the thread was locked. Feels like a method of suppressing the conversation, and, being marked with “[Not on the Roadmap”] as a kind of victory lap.

In addition to this feeling like a bit of a gag order, there were continuing legitimate uses for this thread, including the trading of ideas regarding work-arounds, etc. Locking the thread guarantees another will open anyway, since someone unaware of the continuing debate will post the request anyway.

Maybe there is a legitimate purpose and policy behind this action. But I would ask the moderators and the Roon team to be careful with such decisions, as they can send unintended messages. Unless that message was intended?

I think the reason why they closed the “folder browsing” thread was the fact that it contained so many extremely lengthy repetitions and that the discussion kept going round in circles. I read most of the thread and found that pretty frustrating and tiresome. Just MY opinion, of course.

5 Likes

All of those characterizations may be correct. Indeed, my last post indicated that it was just a lot of repeat. But that said, I don’t think that is a justification for closing it down. I guess I assumed the job of moderating was to keep things civil and not allow profanity, personal attacks, and such, and to clarify points, nudge conversations in certain directions if it would add value, and the like. This feels a bit more like censorship of the idea.

As a feature request, that thread has run its course after recent statements / explanation by Roon themselves. The ‘Not on roadmap’ marking was added in the same spirit threads in the support section are closed once solved: an indication before opening the thread, nothing else.

This community is very open to hosting all kinds of opinions about Roon and will remain that way. Roon staff reads feature requests (all of them) and have proven to be very accommodating to requests where and when they fit the product they envision, so by all means – keep them coming.

8 Likes

@James_I, I have to say I am very sympathetic to that observation but my two cents is that I often see a confusion on this forum that it is in any way an “open” forum that many are used to participating in.

Computer audio came out of the standards and open forums so many attracted to this way of playing music are “culturally” wedded to that mindset. But this is a “vendor” forum in that it is being used for vendor concerns such as support and market research. The conflict of interest is that it is also being used for many “community” concerns not shared by the vendor. Folder browsing is only one of them. DLNA support comes to mind. But there are many other equally contentious debates. Are those to be shut down as well? That is quite a slippery slope.

Just a thought. It would be a shame to damage the community vibe here. On “open” forums the community often starts the process of building or experimenting with workarounds not supported by the standards. Maybe it would be better to re-direct the roon equivalent of those sorts of debates to an “unsupported” thread rather than shutting them down. Some of it maybe could find a home in the “tinkering” or API threads. Otherwise there is going to be lot of equally contentious threads roon will need to shut down. The alternative of a new community forum unaffiliated to roon is not realistic.

I personally thought the ROON team had the Last word on this and it’s pointless the thread going on. Roon have stated there thoughts and reasons on the subject at this time, in detail.

To be clear: Roon Labs didn’t close the thread, didn’t prompt anyone to close it and wasn’t involved in the decision. I’m not saying that to distance ourselves from the moderators–I agree with the call that they made. I’m just making clear that this kind of stuff rarely comes “from the top”.

We do not censor critical opinions of our product or shy away from difficult discussion. We prefer to engage instead, as I did with you last week on this topic.

Moderators made the call to close it because it was a feature request thread for a feature who’s fate was sealed. They also close feature request threads when features are delivered. This seems reasonable to me, and is in line with the purpose of the feature requests section.

A closed thread with “Not on Roadmap” in a section devoted to feature requests is good expectation setting. It’s not very common for us to answer a feature request with a “hard no”, but this is one of those cases.

There aren’t many “never gonna happen” feature requests. For every one of them there are 100+ others that are in some version of “this seems alright, but we don’t know what is going to happen with this yet”, and they of course remain open, sometimes for long periods.

I’m sure the moderators would have no problem with a continued discussion of workarounds or solutions related to folder browsing/interoperability outside of the feature requests area. We certainly don’t have a problem with it.

I also do feel that Roon should as a general matter be more of an open standards application as regards work done in curating one’s collection.

This is a fine topic for discussion, and possibly even a feature request, but it’s distinct from the folder browser discussion.

Just because the opportunity for us to abuse the situation exists doesn’t mean that abuse is taking place. We manage this site with a very light touch compared to the non-commercial communities I’ve been involved with.

I don’t think there is much confusion over the fact that Support is an official support area. #roon:feature-requests also serves some official purposes of informing people about roadmap status or completed/never-gonna-happen features. They require a little bit more moderation than other areas in order to serve their purpose.

If you think we are crossing the line, we would of course like to hear about it and have a chance to discuss our actions or the actions of the moderators–as we’re doing here. It is our intent for this place to remain as open as possible.

9 Likes

Thanks @brian for clarifying that. Personally I don’t see the point of keeping that thread on life support either. I can think of a lot of examples,very hotly debated, concerning the relative merits of open/proprietary protocols. One of the things that is interesting about roon is that it takes that debate all the way into the presentation layer. I used to work in the telecoms sector and that was always a hot topic at a device level and ultimately resulted in the iPhone and a siesmic change in an entire industry. It is interesting with roon to see this debate now transposed to an application level

I hope the mods can find a home for this type of discussion but something as specific as a vendor feature request at right angles to repeated statements on the vendor roadmap, is not the best place.

Damn clickbait thread titles.

Edit: Thx for making it more descriptive :+1:

1 Like

The thread was useful but had run it’s course as a Feature Request. Brian’s answer was getting masked by continuing circular argument and new readers may have been left with the impression that folder browsing was a possibility.

A number of interesting useful things came out of the discussion. The best, in my opinion, was the Feature Request by @evand for Users to define Roon tags in the file tags. That’s the kind of powerful approach that potentially answers a lot of library import issues in one hit that I hope could be adopted.

1 Like

I agree I think this would work to solve many import challenges.

3 posts were merged into an existing topic: Existing path browser enhancements & availability from composition screen

This is more on the theme of what the forum is for, and less on the topic of the tags thread. My take on a forum from a product company is:

The company is paying for the forum. They get to decide the purpose(s) of the forum, and which threads serve that/those purposes. Full stop.

Agreed, I’ve split out the discussion of tagging into the existing topic … let’s keep this on topic.

There seems to be some interest, I don’t know how much, in more general “futures” topics, that do not really have a category. Examples are:

Convergence on meta-data standards
Transport protocol integration (RAAT<–>DNLA)
Presentation layer standards (aka the folder/meta-data debate)

I think these are separate debates that could inform more practical categories concerning feature requests, support, extensions, work-arounds, best-practice etc.

Is it time to find a home for these types of discussions in a new category?

One thing I have noticed about the moderation on the forum is that it is particularly averse to any bit of cut and thrust.

It may well be that this is due to the vitriol which CA can contain and I would hate the Roon forum to go in this direction.

The odd bit of irony to bring someone down off their high horse should be more accepted I feel. I’ve been moderated a few times on the Roon forum and generally don’t get moderated on my other 2 fora of choice (Naim and PFM).

And while I’m on a roll I do perceive a fall off in speed of reaction to the (@) support tag. As it is the method of Roon giving support I feel there should be no support call that doesn’t get answered at all. I realise we all want an answer yesterday but there should be log of all support calls and all should be answered. It strikes me that you get support much quicker if you shout you have a yearly that you are not going to renew than the polite request for help from the guy with 2 lifetime subscriptions. (Any Resemblance to Actual Persons, Living or Dead, is Purely Coincidental)

Don’t get me wrong this is a grand place and I feel I’ve made a few friends here, well there are certainly some if they said they were in Dublin and would I like to meet them for a pint, I wouldn’t run a mile.

I think more of a blog presence from the Roon team would be of great benefit. we tend to only see you fire fighting and supporting. There is a depth of knowledge of music making and music that if shared more would generate an even stronger community feel.

All in all on a public forum in the Trumpian dystopia we are living in, a fine job is being done.

.sjb

2 Likes

The Roon Software section would be the current home for those topics, but it’s getting unwieldy. Any suggestions for sub-sections within it ?

Standards & Inter-operability.

Several of the existing topics could be rolled up into Interoperability and a few added. A topic of interest to me is RAAT<–>DNLA interoperability for example.

Standards would cover much higher level general topics that ultimately are going to be needed to make roon work as we would like it. The obvious topics are metadata convergence and UX convergence. Others will have other priorities.

This is another thing that is a solid “no”. We will never do generic UPnP support for arbitrary devices. You can discuss it all you want, but people will keep bringing up the fact that we have stated that this is a solid “never gonna happen”.

In my opinion, as long as you can keep the talk civil, go for it… but you’ve heard our answer.

Here is an existing feature request that is boring enough that no one has ever closed it out:

@danny the purpose of the proposal was to find a way of taking these solid no’s out of the feature requests, not perpetuate them. For whatever reason, several topics keep on coming up and some may still want to discuss, maybe exchange work-arounds and experiences. I wholeheartedly agree that these types of feature requests are pointless. It would require a little more intervention from the mods to ensure that the discussions didn’t drift into feature requests.