The ethos of Radashi #20
Closed
aleclarson
started this conversation in
Ideas
Replies: 1 comment 1 reply
-
|
@aleclarson a question about the motivation for this fork: did sodiray mention anywhere that they would no longer continue with the radash repository? |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
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. |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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: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!
Beta Was this translation helpful? Give feedback.
All reactions