To make a change on either Wiki, you need to use the link below to become an Open Source Editor on cheqd's GitBook:
Once you have made your account using the link above, you will be classified as a Editor on cheqd's GitBook. This will give you the ability to make edits and submit them to be reviewed by a Reviewer. Reviewers are able to merge submitted changes.
You should follow these instructions to make a edit to any cheqd GitBook content.
Make your edits in the text directly or use comments
Via the link above, you will gain permissions to to read, edit and comment directly to the text.
If you are confident with your edits, you can write and amend the text directly. If you are less confident, you can leave comments in the text, which admins will review and make changes from accordingly.
Save your changes as a draft
You can save your changes as a draft and return to your draft later. If you want to remind yourself with the changes you made previously, you should click the Diff view button:
You should keep your changes in drafts until you are happy with them.
Following this as best practice, avoids the Wiki being misused or flooded with changes from one person.
3. Submit your changes
Once you are happy with your changes in your draft you should click Submit. This will send your changes to one of our Reviewers to be moderated before being pushed onto the documentation.
There will be a pop-up asking you to explain the changes you made. Make sure to write a clear sentence summarising your main changes to make it easier for the cheqd reviewers to go through your work.
You may also use GitHub to make changes and amendments to both the source code and the written content in this documentation.
We have multiple GitHub repositories which can all be accessed here.
For instructions about making edits to GitHub repositories, we suggest you follow the instructions here.
Please use clean, concise titles for your pull requests. Assume that the person reading the pull request title is not a programmer, but instead a cheqd Network user or lay-person, and try to describe your change or fix from in plain English. We use commit squashing, so the final commit in the main branch will carry the title of the pull request, and commits from the main branch are fed into the changelog. The changelog is separated into keepachangelog.com categories, and while that spec does not prescribe how the entries ought to be named, for easier sorting, start your pull request titles using one of the verbs "Add", "Change", "Deprecate", "Remove", or "Fix" (present tense).
Fixed NoMethodError in RemovalWorker
Fix nil error when removing statuses caused by race condition
It is not always possible to phrase every change in such a manner, but it is desired.
The smaller the set of changes in the pull request is, the quicker it can be reviewed and merged. Splitting tasks into multiple smaller pull requests is often preferable.
Pull requests that do not pass automated checks may not be reviewed.
During the course of cheqd's lifecycle, it is likely that bugs will arise. Reporting these bugs effectively and resolving them promptly will be very important for the smooth running of the Network.