crypto-worker
Thank you so much for considering to contribute to Notesnook! If you have no idea where to start, what to do, what you can do then you are in the right place. There are plenty of ways you can contribute to Notesnook; many don't even require coding skills.
Ugh! Bugs!
A bug is when software behaves in a way you didn't expect, which the developer didn't intend.
To help us understand what's happening, we first want to make sure you're using the latest version of Notesnook.
Once you've confirmed that the bug still exists in the latest version, you'll want to check to make sure it's not something we already know about in the opened GitHub issues.
If you've upgraded to the latest version, and you can't find it in our open issues list, it's time to open a new issue. It is recommended that you fill out all the fields in the GitHub issue form with as much detail as possible. This includes:
The easier it is for us to recreate your problem, the faster it will be fixed.
If you've thought of a way that Notesnook could be better, we want to hear about it. We track feature requests using GitHub Issues, so feel free to open an issue which describes the feature you would like to see, why you need it, and how it should work.
Before you open a new feature request, please make sure it's not a duplicate. Duplicate feature requests & bug reports are closed immediately.
New issues are always opened that need to be triaged, sorted & organized, so the developers can easily find the most critical and/or relevant bugs to fix. Any help in this regard is appreciated.
In addition to this, you can help out in the following ways:
Before you start contributing code, make sure to read the commit guidelines, git branch organization & style guidelines.
As with other types of contributions, the first step is to open an issue on GitHub. Opening an issue before you make changes ensures that someone else isn't already working on that particular problem. It also lets us all work together to find the right approach before you spend a bunch of time on a PR. So again, when in doubt, open an issue.
Each subproject in the monorepo contains its own set of documentation which you should refer to get started. This includes:
Once you are done, open a new pull request.
Before submitting a pull request, please make sure the following is done:
master
(you can name your branch anything).npm run bootstrap
in the repository root.npm run test
).npm run prettier
).npm run lint
). Tip: npm run linc
to only check changed files.To keep Notesnook 100% open source we use DCO (Developer Certificate of Origin) instead of CLA. We respect intellectual property rights of others, and a Developer Certificate of Origin (DCO) is a lightweight mechanism to make sure all incoming contributions are correctly attributed and licensed.
The DCO is a declaration attached to every contribution made by every developer in the message of every commit. The developer simply adds a Signed-off-by
statement and thereby agrees to the DCO, which can be viewed at DeveloperCertificate.org.
We require that every contribution to Notesnook is signed with a Developer Certificate of Origin. Additionally, please use your real name. We do not accept anonymous contributors nor those utilizing pseudonyms.
Each commit must include a DCO which looks like this:
Signed-off-by: Jane Smith <jane.smith@email.com>
On VSCode, it looks like this:
You may type this line on your own when writing your commit messages. However, if your user.name and user.email are set in your git configs, you can use -s
or --signoff
to add the Signed-off-by
line to the end of the commit message automatically.
<scope>:
in your commit messageAll commits must include valid scopes in the commit message. Valid commit scopes include:
Apps:
mobile
: changes related to mobile clientsweb
: changes related to the web clientdesktop
: changes related to the desktop clientPackages:
crypto
: changes related to the cryptographic coreeditor
: changes related to the editor (including @notesnook/editor-mobile
)logger
: changes related to the loggertheme
: changes related to the themeRepo maintenance:
config
: changes related to config of installed tools in the repo (e.g. eslint rules)ci
: changes related to CIsetup
: setting up something new in the repo (e.g. eslint, commitlint)docs
: changes related to documentation (README etc.)misc
: miscellaneous changes like package-lock.json updatesglobal
: changes related to the whole repoSome example commits would look like this:
docs: list all valid scopes in commit guidelines
web: impl xyz feature
crypto: update libsodium version
We use an automatic code formatter called Prettier. Run npm run prettier
after making any changes to the code.
Then, our linter will catch most issues that may exist in your code. You can check the status of your code styling by simply running npm run lint
.
However, there are still some styles that the linter cannot pick up. If you are unsure about something, looking at Airbnb's Style Guide will guide you in the right direction.
Submit all changes directly to the master branch
. We don't use separate branches for development or for upcoming releases. This requires us to always keep the master
branch in a deployable state which means:
We deeply appreciate everyone who takes the time to make a contribution. We will review all contributions as quickly as possible. As a reminder, opening an issue and discussing your change before you make it, is the best way to smooth the PR process. This will prevent a rejection because someone else is already working on the problem, or because the solution is incompatible with the architectural direction.
During the PR process, expect that there will be some back-and-forth. Please try to respond to comments in a timely fashion, and:
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。