Jamulus
Replies: 6 comments 27 replies
-
|
Personally, I don't have time to follow everything. I gave up on SourceForge a long time ago and I've not really used it much since then (very occasionally when something needed my attention). So I'd certainly back moving off SourceForge. I think a Facebook presence is expected. We can be firmer about guiding people elsewhere, if appropriate. But it still needs to be somewhere people can find. Note that it's a closed group - so it's not great for search engines. There shouldn't be any "useful content" hosted there - just social discussions, really, plus simple support requests. Anything that "Have you read jamulus.io/something?" doesn't fix may need to be thought handled elsewhere -- I don't think Facebook is a great place for "customer support". I think Github issues should be very clear cut: it's either a bug or a new feature / enhancement. Otherwise it's something else and not an issue. Because we have two git repos, we should have two trains of bugs and features, so that changes can be properly tracked - pull requests should reference the issue they relate to. I'd suggest the Discussions might be in the wrong place. But I'm also saying there are "customer support queries". These are things where we're going to ask someone who's raised something on either Github as an issue or Facebook as a social post to post somewhere else - or take it upon ourselves to redirect the post somehow. I don't know of a good service to provide this, though. I've never been the client to one I've liked and I've never provided support using one I've liked. Whatever tool we use, we want it to support search engine access so people can find solutions for themselves using Google. So, despite having said I'd be happy moving off SourceForge, I have to admit I've preferred it over Github for the type of "customer support" that I'm talking about. Finally, I think there's demand - similar as for Facebook - for a "Jamulus Official" Discord. Given that Discord allows setting up roles with those then allowing access to be granted to particular channels, I'd suggest most discussion activity could be hosted there. The channels (or rooms or whatever they call them) could be created on demand for the most part and archived (I presume) if they've run their course. |
Beta Was this translation helpful? Give feedback.
-
I'd agree. It's just too much of an overlap. It means I hardly spend any time looking at the Facebook group in fact.
Agree. Also agree with the fact that it's not good for "customer support". But for better or worse it's a general "social" area.
The trouble is that they are used as discussion forums for feature requests. So it's very hard to work out what in fact is being decided once you have more than about 10 comments. We occasionally edit the titles of things to reflect the state of play, but I'd suggest it would better to have initial discussions of everything that isn't a bug somewhere else, and only allow solidified feature requests to be posted once they've been firmed up so we can tag and bag them properly into phases and whatnot. Right now it's all pretty chaotic with tickets that look like one thing but in fact have turned into another. We could use GitHub Discussions for the "triage and fermentation" of feature requests (if only because it's easy to convert an issue into a discussion I think)? Might these Discussions also handle "customer support queries" in the form of a support topic? Otherwise, regarding these "customer support / discussion" things, we could use Discord, but if we did, I'd vote to shut down GitHub discussions as that would overlap too much. However, a Discourse site on jamulus.io would give us Google juice. And it supports federated login from Facebook, Github, etc. (but not SF I don't think). Downside being we'd have to host it, but I have the capacity to do that for free. So in summary I think we two (at least!) seem broadly in agreement about:
What we may need to discuss further is whether we go for GitHub Discussions, Discord, Discourse or possibly something else. So the above would mean three clearly delineated places for the three clear needs: community (Facebook), project management (GitHub), "customer service" / "discussion" (TBD). In an ideal world, I'd nuke Facebook and just have two spaces, but it's not an ideal world. Maybe it'll wither away in time. |
Beta Was this translation helpful? Give feedback.
-
|
Some thoughts on the issue of "customer support / discussion" platforms: Ultimately, these discussions would be for the purpose of managing the Jamulus project. So hooks into GitHub would be very useful. We have Facebook for "social" stuff, after all. The most pragmatic choice would be GitHub Discussions I think. They mimic Discourse in function (topics, answers, voting, locking, pinning and things), and you can easily migrate Issues to a Discussion (we can't prevent people from opening up discussion-style topics in issues unless GH change that). And Discussions are beta so likely we'll see more of this sort of coupling. However, we'd miss out on the opportunity of Google keyword fodder. I don't know how significant that would be though (I'm not an SEO expert). Also, everyone would have to have a GitHub account to use it. Discord not being part of the GitHub universe is a bit of a problem although it does have some (3rd party managed - might need to pay) GitHub integration that might be OK. Also suffers from the same absence of SEO. But you can use other accounts to log in. Discourse would give us the benefit of SEO goodness, loosely coupled with GitHub (and other things), social login and a vanity glow perhaps. Also has a discussion "expiry" convention, which makes it good for admin. We'd have to host it too, but there's pros and cons in that of course. |
Beta Was this translation helpful? Give feedback.
-
|
@gilgongo thanks for opening this discussion. I'd like to ping @dcorson-ticino-com here since he's very active on SourceForge. General ideas:
So the new structure would look like this: Forum on a sourceforge webhosting with GitHub & Facebook integration; shutdown of GH Discussions and SF forum (it would be great if we could migrate threads). |
Beta Was this translation helpful? Give feedback.
-
|
Slack's quite nice because it's easy to turn a private chat into a channel, which can become public (from that point on), if needed. I don't know Discord really. It's just I do see demand for somewhere to have chats about Jamulus topics, mostly for socialisation, rather than raising specific issues. So someone might say, in a chat, "I can't get on to server foo on list bar, anyone else having problems?" and get a quick bit of help on a specific thing. We've also used Slack for brainstorming, cut-n-paste images in whilst chatting about what we're discussing, until something that can be "written up" takes shape, so I was thinking maybe Discord could be used similarly. |
Beta Was this translation helpful? Give feedback.
-
|
OK so that would be a fourth place, for "chat". Fair enough (particularly if it weans people off Facebook IMO). I have no preference either way for Slack or Discord really. Slack can get complicated on the logins front though and Discord seems less so perhaps? |
Beta Was this translation helpful? Give feedback.
-
|
Looking at SF for hosting MySQL/PHP, I feel a bit worried that offering a totally free service like this is a little too good to be true, but I'll try installing https://bbpress.org/ on discuss.jamulus.io and see what that feels like. |
Beta Was this translation helpful? Give feedback.
-
|
They sell ad space, don't they? They were putting "Please read this whilst watching the count down timer before we let you have your download" notices up at one point. (My ad blocker mostly protects me... but only from the ad content.) |
Beta Was this translation helpful? Give feedback.
-
|
AFAIK we're not paying for it! |
Beta Was this translation helpful? Give feedback.
-
|
Actually I didn't know that there is more than SF and the issues here. |
Beta Was this translation helpful? Give feedback.
-
|
So having investigated SourceForge hosting some more, and thought about hosting our own forums, I don't think it's a good idea. I'm not convinced something on jamulus.io would do that much for our SEO, and while GH Discussions don't have social login, using them would mean we'd not need to worry about them getting hacked, running out of disk space, PHP versions or whatever... like we would if we owned our own. And they're nicely integrated (or will be) into GH overall, so good for the project management / "customer support" thing. Talking to @softins on Discord just now he doesn't seem to have any objection to GH Discussions, nor I don't think does @pljones (and @dcorson-ticino-com doesn't see above). @ann0see would you agree? If so, then I propose we do the following:
|
Beta Was this translation helpful? Give feedback.
-
Hmm. Not really happy about this: |
Beta Was this translation helpful? Give feedback.
-
|
Well, they're pretty closely linked, as @pljones points out (and if we weren't using GH Pages for the website, we'd have them all in one place no doubt!). But even if they weren't, having to check in two places for things is just more work unless you're literally not interested in one or the other. But I guess now that we're sticking with GH Discussions we can defer this question until later. We can simply move issues between repos anyway. EDIT: LOL this just came up on my phone: https://dl.acm.org/doi/abs/10.5555/2819009.2819042?download=true |
Beta Was this translation helpful? Give feedback.
-
|
I'm going to put a sticky on the the SF Dev forum now as a test to see what happens when we set it to only being visible to developers. It gets about one post a month. EDIT: I think I can in fact make the forums read only (I think...). So will attempt that. |
Beta Was this translation helpful? Give feedback.
-
This would be great! I think it would be a pity to lose all the SourceForge forum content. Even if we were to archive it, the links would still break. There are even links from official documentation to specific SourceForge discussions, e.g. here: https://github.com/jamulussoftware/jamuluswebsite/blob/67d6949d10b48d12e948255355e40839a23f2686/wiki/en/en-Client-Troubleshooting.md |
Beta Was this translation helpful? Give feedback.
-
|
Ah yes good point about those links. I'll see if I can quickly update them now seeing as we've yet to start translating. |
Beta Was this translation helpful? Give feedback.
-
|
On a separate but related note, there is are in fact 12 discussion platforms that I'm following as part my involvement in Jamulus:
Consequently, I have to rely mostly on my email inbox as a single source information about what's going on. So far, I'm seeing a low amount duplication of topics across discussions, which is good. But at any point things could get chaotic very fast :-) |
Beta Was this translation helpful? Give feedback.
-
|
@gilgongo You're missing out! https://github.com/orgs/jamulussoftware/teams also has autobuild (so that's 5) :) I've been heavily ignoring everything I can afford to ignore - I simply don't have enough time. |
Beta Was this translation helpful? Give feedback.
-
|
Autobuild was just a small Team with nefarius and me since we work(ed) together on some stuff with the automatic build process. No need to follow this. |
Beta Was this translation helpful? Give feedback.
-
|
Of course, reducing the number of messaging platforms isn't necessarily going to reduce the volume of messages, but it should make things easier to manage and possibly have other benefits in terms of re-duplication (if it makes it easier to see that a topic has already been covered). To that end, I think discussion on the website repo may well be something we can shut off (threads can be moved if needed - I'll have a look). I have also suggested we merge the two issues lists into one, because documentation and code are inextricably linked. We have to have a separate repo to do GH Pages, but that's not necessarily a reason to duplicate other things. I know @ann0see is opposed to that idea though. One thing a merge would mean is that we wouldn't be able to link website-related tickets to PRs in the website repo. But I think that linking is only useful for Project automation (I think...) and does nothing much otherwise. I'll investigate a bit more on that. We also need to sort out the Teams, which seem pretty complex too (with nested ones and permissions), and since each of these can spark a Discussion as well that's a worry... |
Beta Was this translation helpful? Give feedback.
-
I think so, too.
I don't have a strong opinion there. For documentation updates which are tied to new features or code enhancements, it would be beneficial to track them right in the code-side issue for that feature and avoid having a seperate issue in a different repo. For docs-only changed there may be the downside of "Fixes #abc" in a commit not triggering the closing of the issue. Still to be confirmed, I guess?
I'd keep the Teams discussions, but I'd also keep them to a minimum. If there's things which should not be shared publicly, let's keep them there, but the vast majority should be public issue or discussion, in my opinion. This would help both for transparency and for focusing on as few platforms as possible. |
Beta Was this translation helpful? Give feedback.
-
|
OK I'll look at closing the website discussions.
BTW I expect the documentation work to reduce to being a lot less than it is now (it better do or the translators will give up!) so perhaps once that's down to just the occasional feature update we can close down the Issues there eventually. But in terms of the pros/cons of issues in one place, I'm a bit vague on the way GH does workflow. If we link an Issue to a PR (using the "Linked pull requests" function on the right hand bar), and that PR is merged/closed, does that also close the Issue that's linked to it? If so then if the PR was code and the Issue link to it was documentation, then that would be a problem, certainly. As to Teams, I think find their discussions the most confusing since they are visually similar to the main Discussions (hard for me to recall where I saw something being discussed) and so far have been on topics that range across the same sort of areas as the main Discussions. Luckily, they've not been high traffic. I guess they are good for "announcements" since they only go to specific people. Perhaps over time they'll just go to Discord in most cases I hope. Fundamentally though, I think my Gmail inbox will be the first port of call for everything anyway, so it's not as if I'm powerless over the chaos. |
Beta Was this translation helpful? Give feedback.
-
|
Ok. Just moved this to the main repo. I think having it here makes it more visible. In long term, I'd suggest to close the discussions on the website. |
Beta Was this translation helpful? Give feedback.
-
Well, the longer we leave it the harder it gets of course. I was thinking of moving the threads that didn't look obviously dead over to the main repo maybe in the next day or so really... |
Beta Was this translation helpful? Give feedback.
-
|
Ok. Yeah. Just do it then. Concerning the close down of the forum: I'd allow every type of discussion which was part of the forum also here on GitHub or at least not necessarily force people to go to Facebook (Facebook doesn't seem to be an open forum and doesn't give any benefit if you e.g. google a problem you have.) Getting as much as possible from SF and moving it over to GitHub would be great (since the musician and developer forum is not active, I'd remove/make it read only it as soon as possible) |
Beta Was this translation helpful? Give feedback.
-
As I've said on the SF forums: while of course some people don't like Facebook for various reasons, it is for better or worse the main social platform we have. An attempt 10 months ago to create "musician" sections on SourceForge only attracted about 30 threads in total over that time compared to hundreds on FB. But even if it had done better, deliberate attempts to fragment the community is also not good in the long term. To be clear, this fragmentation implies fewer people able to answer questions or just talk to in general; the appearance of lack of activity; the ability of a few vocal people to exert large influences, and having more places for admins to monitor. That said, if the strength of feeling against Facebook is such that it's seen acceptable to bring about those dis-benefits, then I won't stand against that. As long as we are clear about what we are doing. And for all I know, a miracle will happen and everyone will flock to GH Discussions and we can shut own the Facebook group. But I give the chances of that as very close to zero. |
Beta Was this translation helpful? Give feedback.
-
|
OK I've migrated all the relevant website discussions (there were only a handful) to the main repo and closed them. I'll make the SF forums read only on the 1st March for no better reason than it's the start of the month. |
Beta Was this translation helpful? Give feedback.
-
(Ironically, I wasn't sure where to post this...)
There are pretty much six places you can post anything, and they all pretty much overlap to some extent:
That's a lot :-) The overall traffic isn't that high, but it’s hard to know what level of usage Jamulus will get in the future. We might suppose it could roughly double from what it is today once Google starts listing us properly in next 24 months or so for terms like “jamming” and “online rehearsals” (which is just starting now since we launched the website).
If that happens, to what extent is having discussions in all these places a problem?
For one thing, people capable of seeing and answering any one question will be spread six times thinner than if there was a single platform (and readers will always vastly outnumber writers). This fragments and duplicates information and risks "ghost towning" if respondents are spread too thinly.
One thing to note is that none of our discussions are on the jamulus.io domain. We miss out on a good potential source of Google juice there I think.
If we think it's a problem, then possible courses of action (singly or in combination)?
Sunset SourceForge forums because these directly duplicate Facebook, GitHub issues and (in future?) Discussions.
Be more decisive in moving non-bug and non-feature tickets from GitHub issues into Discussions until they have an agreed spec.
Combine GitHub issues into one, using tags/topics for software and documentation (and we need to implement Epics and Stories but that's a different topic).
Do the same for GitHub Discussions.
Set up a Discourse server on community.jamulus.io to replace some or all of the above (probably not Facebook, and maybe just leaving GitHub Issues exclusively for admin stuff). Thereby putting all that content to work promoting Jamulus to Google.
🔥 🔥 🔥
Thoughts?
Beta Was this translation helpful? Give feedback.
All reactions