Do we need this?

[rhl-bthr]

I'm not sure what value does it add. Another version of music blocks will imply more maintenance with no significant end user difference. My suggestion is to archive / delete the repository.

@walterbender @quozl

[pikurasa]

I can add more thoughts later, but I imagine it would be a plus. For one, performance and sound in browsers are not great. The option to access C sound libraries could be nice. Also, the nature of browsers and their security mean a certain level of uncertainty.

[quozl]

We have a seemingly endless supply of repositories with broken activities that draw attention of contributors, so one more is no problem. Like the failure to release problem, it's not something that can be solved by deleting everything broken, because that makes work later recreating it. 😁

Music Blocks could be targeted for execution by electronjs, gjs or sugar-web, and sugar-web could be fixed to clear up any lingering problems we're yet to raise as issues. These options may reduce the problems experienced with security and sound on browsers.

[rhl-bthr]

Thanks, I agree that deleting repositories can be a bad option

But should we archive the repositories which,

• Have no active maintainer AND,
• Are in a broken state AND,
• haven't been updated for a long time AND,
• most importantly, are not being used (statistically)

This will help new contributors to focus on the repositories which are used (ASLO stats) and useful. We can make a list of to be archived activities for anyone to look up, in case they want to contribute to them

[pikurasa]

FWIW, the developer in Japan has made an electron version. The performance is pretty much the same for this version.

[walterbender]

Sorry to have abandoned this repo. I got stuck with the fact that tone.js wouldn't run in the Sugar browser. I suspect that newer versions of Browse would work and maybe this approach could be revisited.

[rhl-bthr]

@walterbender @quozl, please give your suggestions over #3 (comment)

[quozl]

@pro-panda, in reply to your idea to help new contributors to focus by hiding inactive repositories ...

Helping new contributors to focus their attention isn't solved by removing distractions. New contributors need to develop the skill of assessing opportunities for value, and we should guide them only lightly. We're not in the business of selling involvement opportunities.

There are plenty of opportunities to contribute, and many of these opportunities are not necessarily found in the master branch of repositories in the GitHub organisation sugarlabs; there's also;

• other branches,
• other forks,
• orphaned or disconnected repositories with the same bundle_id value, found using GitHub or Google Search,
• repositories at git.sugarlabs.org,
• bundles in activities.sugarlabs.org that have no repository,
• bundles available for download from education departments across the world.

Also, many problems yet to be solved are not in GitHub issues, and nor should we expect them to be, instead they are in;

• mailing list posts, especially those test summaries by Tony and Thomas,
• bugs.sugarlabs.org, which is still used, see recent history there,
• wiki.sugarlabs.org, see RecentChanges.

Don't try to use GitHub as a way to constrain or guide new contributors. Don't provide lists of how to contribute. Expect contributors to be able to make their own mistakes on what to work on. They will learn quickly.

@walterbender, test again with later WebKit, as WebKit has changed and Browse relies on it heavily. Where a user media request is made though, e.g. for microphone or camera, Browse does not handle properly, see sugarlabs/browse-activity#85

[rhl-bthr]

I'll have to brush up on my language skills 😅. My primary concern was that developers shouldn't be working on something that is not being used at all.

I agree that this might constrain contributors, thanks

[quozl]

Indeed working on something that is not being used at all can be unfortunate, but it is also a learning opportunity for the developer. When responding to new contributors, I'm obliged to consider if their contribution is needed, based on whether the source code is working, is popular, is maintained, and has a future. It draws focus momentarily, and is helpful, even if the patch is not accepted.