To encourage active collaboration, we strongly encourages pull requests, not just bug reports.
However, if you file a bug report, your issue should contain a title and a clear description of the issue. You should also include as much relevant information as possible and a code sample that demonstrates the issue. The goal of a bug report is to make it easy for yourself - and others - to replicate the bug and develop a fix.
Remember, bug reports are created in the hope that others with the same problem will be able to collaborate with you on solving it. Do not expect that the bug report will automatically see any activity or that others will jump to fix it. Creating a bug report serves to help yourself and others start on the path of fixing the problem.
The developersnepal source code is managed on Github.
Core Development Discussion
You may propose changes to the Developers Nepal Internals slack #request channel.
Informal discussion regarding bugs, new additions, and tweaking of existing parts takes place in the
#general channel of the DevelopersNepal Slack team. People are generally there and someone will response on it.
All features should always be sent to the
gh-pages branch, which contains latest stable codes.
Bug-fixes should be sent to the
If you are unsure if your changes qualifies as a major or minor, discuss it in DevelopersNepal
Pull Request Guideline
Always send PR based on the tweaks/additions, issues you are working on. If it’s new changes then send it against
- Label your PR as
ready-for-reviewand choose reviewers. These reviewers may not be immediately available to review the PR. Usually PR is reviewed in 1-2 hours however it may also take 2-3 days based on the availability of the contributors.
- Once PR has been discussed, it will be labeled as
review passedwhich means it can be merged to
gh-pagesbranch and will go live.
- In case something needs to be fixed in the PR before it can be merged, it will be labeled as
waiting for updates.
- Once PR comments are addressed, it should be labeled as
updatedso PR reviewer gets notified about it and will review the PR again.
- step 3-4 can repeat multiple throughout PR lifecycle. Once reviewer is convinced, PR will be labeled as
review passedand will be merged to
gh-pagesbranch. Merge will be done as
squash and merge.
PR Lifecycle State Diagram