Feedback on the video:

• It uses quite a lot of terms the viewer has to grasp.
• Not always clear which actions/concepts are internal to Ara vs. have a "reality" on GitHub...
• Does Ara interface to GitHub Issues, or does it have its own?
• In particular, "create a version" is that a Git tag or something? Or is it a new Ara concept?
• And "release it" does it just mark it released on Ara or did something external happen (e.g. new GitHub release created)?

I started from the video, and felt it has little to do with how I think about open-source "community". Is this monetization? Karma? Assigning issues is something I mainly saw on corporate repos; a maintainer != a manager... 😕 Only at the very end I started to get a glimpse of the goals.

But then I read the web page — that clicked much better 👍 I don't feel I need it (or expect any funding) for my projects, but I can see how the "2 rules" resonate with things maintainers complain about.

FOSS long had concerns that coupling compensation <-> participation could (A) distract people to "game the metrics" rather than focusing on project health (B) unfair attribution risks creating bad emotions.

In particular, in healthy projects multiple people can contribute to an issue. Triage, debugging, discussion wrt. other issues, fix brainstorming, possibly multiple PRs, review, testing etc... Frequently also unfinished work by one contributor gets abandoned, and is later picked up by others. Will Ara allow splitting the credit for an issue to many participants? Is assignment post-work (better I think), or from the start (risks discouraging others from chiming it)?

@Beni Cherniavsky-Paskin Thanks for feedback about the video. Its really helpful. I'll consider it with the future updates.

As for the projects, its goal is to make projects sustainable. For maintainer it means funding, but also attract contributors.

By turning into a community project. And for the contributors target the junior programmers, who just learn programming and can't find work or real experience. But here, get the guide such as discussions and help.

Here, issue being attached by tokens, the more people join, the better issue gets. 🙂 Its encouraged. Although right now as a solo-dev, couldn't add yet.

Yes, issue is split to everyone who ever get involved in the issue. At least to the issue's author and its maintainer. For now, splits 1/3 to user, and 2/3 to maintainer. But with other options, I will add the mechanism so that maintainer could set the splitting ranges.

Pfffffff ugh. Ugh.

so true though

This reminds me of a spreadsheet on my old NeXT computer. I found this video of a Lotus Improv Demo. The feature I'm referring to is shown starting at 4:19.

Interesting exploration, reminds me of Ultorg

this is thought provoking; I’m struggling to understand the oppositional relationship set up, though -- why LEGO vs. FP/Types (also noting that FP and Types seem to be kinda conflated into each other)

the reason I found this so thought provoking is that when I’ve taught types to folks in the past, my central analogy to do so was LEGO. From my perch, LEGO’s are highly composable because they’re also strictly typed.

Each LEGO defines a strict, immutable type which we can type-check through its physical constraints, whereas if LEGO has no types, it’d be play-doh, still powerful and expressive, but composable in a very different way.

Unlike many type systems, though, LEGO are simple and don’t require you to create adapters or complicated translating chains -- which isn’t true for all type systems, but, I think maybe LEGO can suggest a simpler, deeply expressive way of creating a type system…maybe rather than merely a point of friction types could enable the LEGO dream (which I defo share) that you express in your piece?

For a more grounded example of what I mean, I love JS -- by default, JS has no types, and is very very Play Doh in vibe.

Wanting a more LEGO experience, though, over the last few years I’ve built up this functional programming library for JS that, I think, helps to increase JS’ composability. It does this by enforcing some strict function signatures, and introducing 1 type.

This document does a better job highlighting how b.js is different from normal JS.

LEGO vs. play-doh is not a good metaphor for static vs. dynamic types, in my opinion. LEGO constraints are more like placing things on a grid rather than freely. It's discretization rather than categorization. You don't define your own types in LEGO.

As for composability, typed FP gives you composability in the small but is a barrier to composability in the large. If you need to assemble parts that express the same concept in differently named or structured types, you need to start a serious fight against the type checker.