Contribution guide

Introduction

Welcome to the project! We appreciate your interest and involvement. This guide will help you understand how to contribute while following the project’s core principles.

A small disclaimer:

• Some rules may seem strange or unnecessary — maybe they are! But I kindly ask you to stick to them. After you add a new feature or change something in the code, I will have to maintain it. Following these simple guidelines will make my job much easier. Thank you for understanding! 🫶🏻
• The project is in beta, which means the API may (and will) change.
• If you want to add a new feature or change the current implementation, please open an Issue first, describe your idea, get feedback, and only then start working on the code (this does not apply to already created tasks).
• I am always open to new ideas and suggestions; however, I reserve the right to decide what will be added to the project and what will not.

Any of the principles listed below can be revisited — people make mistakes, people change their minds, and that’s okay. You can always open an issue to discuss any aspects of this guide.

How can I help?

Are you a developer?

If so, take a look at our task board and pick a task. Please leave a comment in the corresponding issue to avoid duplicating work. If you have an idea for a new feature, create an issue and describe it so we can discuss it with you. The stack that might be useful:

• TypeScript
• Vue.js 3
• Quasar
• Golang
• Elisp

Design and User Experience:

We welcome ideas to improve the design, interface, or user experience. You can propose mockups for the application (Figma).

Can you create videos?

We need someone who can produce videos showcasing changes in the project.

Are you an active user?

We need your feedback on bugs and issues you encounter.

None of the above suit you?

You can support us by donating on Patreon or PayPal.

Contribute

• We adhere to the Contributor Covenant Code of Conduct
• We use Conventional Commits
• Each Pull Request should address only one task.

Architecture and Patterns

• Any code that can be implemented as an extension should be written as an extension. For further details read Read “How to write extension” section
• We write code following SOLID, DRY, KISS, and YAGNI principles.
• We prefer a functional approach whenever possible.
• A bit of duplication is better than complex abstractions.
• We are not big fans of inheritance; favor composition instead.
• Command-Query Separation: Methods should either be commands (do something) or queries (return something), but not both.
• We follow a “Local First” principle, meaning the application should work locally and be as functional as possible without constant internet connectivity. Data synchronization should be smooth and only occur when necessary.
• Unsure how to proceed? Check out existing examples or ask a question in our Discord — we have a dedicated developer channel.

Basic rules for writing good code

Follow these principles to keep your code simple and maintainable:

1. Use typed code. Avoid any, interface{}, and their equivalents.
2. Avoid else and switch/case statements.
3. Do not use goto or its equivalents (exception: defer in Golang).
4. Keep nesting levels to a maximum of two.
5. Use auto-formatters like Prettier for TypeScript or gofmt for Golang.
6. Variable and function names should be clear and descriptive. Avoid abbreviations, unclear or overly long names.
7. Avoid comments; write self-documenting code: Comments often become outdated and misleading. Instead, write code that clearly reflects its purpose through proper naming.
8. Strive to avoid side effects; write pure functions.
9. Prefer returning values over modifying arguments.
10. Minimize the number of arguments.

This section is actively being updated!