A comprehensive documentation is a must!
If you fork a repository on GitHub, the standard way to get your contributions incorporated back into the parent repository is through a pull request. Here are the general steps:
- Fork the repository: Click the ‘Fork’ button at the top right of the parent repository’s main page. This will create a copy of the repository under your own GitHub account.
Clone the forked repository to your local machine: Open your terminal, navigate to the directory where you want the repository, and use the
git clonecommand with the URL of your forked repository.
Create a new branch: It’s generally a good practice to create a new branch for each set of changes you want to make. You can do this with the command
git checkout -b branch-name.
- Make changes: Make the changes to the code on your local machine.
Commit the changes: Once you’re satisfied with the changes, commit them using
git add .to stage all changes, then
git commit -m "Commit message"to commit the changes. Be sure to write a descriptive commit message.
Push the changes: Push the changes to your remote forked repository with the command
git push origin branch-name.
- Open a pull request: Go to your forked repository on GitHub and click on ‘Pull request’. Choose the branch you just pushed from the ‘compare’ dropdown. Review the changes, then click ‘Create pull request’. Write a descriptive title and comments to help the maintainers of the parent repository understand your changes.
At this point, the maintainers of the parent repository will be able to see your proposed changes. They can review them, discuss potential modifications, and ultimately decide whether to merge your changes into the parent repository.
If the parent repo’s maintainer wants to merge some specific contributions from a forked repo, they can do this manually by checking out the changes in the forked repo, applying them to their own codebase, and then committing that as their own changes. However, this method does not recognize the original contributor in the commit history. Thus, pull requests are a more favorable method as they maintain a clear history of contributions and contributors.
Will sign up for the waiting list.
good example of SDK docs from millerships
Lots of different solutions.
Another suggestion: fork this and rebrand.
Could be beneficial because:
- it’s proven documentation structure
- it appeals to bitcoiners and devs
If we don’t fork it, maybe we can strive for the same completeness.
@aliencoder @sumamu is this for the technical documentation? Intro - Network of Momentum Multi-chain Infrastructure
This is related only to the bridge, but yes, we can extract valuable info from it.
Cool are you planning to develop technical docs for other topics of the network?