The ethos of Radashi

[aleclarson]

edit: Our ethos is now tracked on the "Our Ethos" page of our website!

See the old ethos

First and foremost, Radashi's vision is to carry on the vision of Radash.

The creator of Radash gave us all the following advice in his writings in .github/contributing.md:

• When coding, try not to create internal APIs (any function or module that is not exported to be used by the client).
• Also, try not to use functions from other Radashi modules. This is a softer rule but we want to make it easy for readers to understand a function without having to navigate the codebase. As a utility library users should ideally be able to copy/paste a function from Radashi into their project. Most Radashi functions should be easy to write in isolation.
• If an implementation needs more than ~20 lines of code it might be better suited for another package or library. This is another softer rule.

Alongside those guidelines, I'll add the following:

• Tests are good: When contributing a fix or feature, always include tests! We're aiming for 100% line coverage (no line of code left untested), but even that doesn't guarantee all edge cases are accounted for. Take care to think of these edge cases, so it's easier for us to trust your contribution!

• Documentation is good: We can't merge your contribution until it's been documented. If you're not proficient in English, let us know and we can help! Consider using ChatGPT to ensure the docs are clear and grammatically correct.

• Abstraction over sugar: Can something already be done simply with vanilla JS? Then it's not a good fit for Radashi. Our functions exist to enable common use cases that are awkward to do alone.

• Is there a common use case? Radashi functions aim to strike a balance between simplicity and utility. No one wants their application to contain a bunch of code that never gets used, so we err on the side of caution and keep it simple. Worse comes to worst, you can always copy-paste the implementation and customize it to suit your application's esoteric needs.

• Performant vs readable: Radashi functions also try to balance between performance and brevity. Our functions need to be easily understood. This keeps the contribution barrier on the lower end, and it makes forking a single function less intimidating. On the other hand, we don't want Radashi functions to disrespect the end user by slowing down your application.

Okay, that's all for now. Let me know if any other guidelines come to mind!

[MarlonPassos-git]

@aleclarson a question about the motivation for this fork: did sodiray mention anywhere that they would no longer continue with the radash repository?

[aleclarson]

I haven't heard back from @sodiray since I tried reaching out to him, and his recent lack of activity has been disconcerting. I obviously appreciate all the work he's done, and he's welcome to join the core team of Radashi. If he reappears to work on Radash, we'll likely be pulling his changes into Radashi. Overall, we want to foster a more collaborative approach in terms of stewardship.