First off, thank you for considering contributing to Doggoscript. It's people like you that make Doggoscript such a great language.
Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project. In return, they should reciprocate that respect in addressing your issue, assessing changes, and helping you finalize your pull requests.
Doggoscript is an open source project and we love to receive contributions from our community — you! There are many ways to contribute, from writing tutorials or blog posts, improving the documentation, submitting bug reports and feature requests or writing code which can be incorporated into Doggoscript itself.
Responsibilities
- Create issues for any major changes and enhancements that you wish to make. Discuss things transparently and get community feedback.
- Be welcoming to newcomers and encourage diverse new contributors from all backgrounds..
Help people who are new to your project understand where they can be most helpful. This is also a good time to let people know if you follow a label convention for flagging beginner issues.
Unsure where to begin contributing to Atom? You can start here:
Issues - you can look though our issues and try to help some people out!
Help wanted issues - issues where some people really need help with something
Comments - add comments to some code that will help more people understand the code
Working on your first Pull Request? You can learn how from this free series, How to Contribute to an Open Source Project on GitHub.
Or you can use http://makeapullrequest.com/ or http://www.firsttimersonly.com/ to get started!
At this point, you're ready to make your changes! Feel free to ask for help; everyone is a beginner at first 😸
If a maintainer asks you to "rebase" your PR, they're saying that a lot of code has changed, and that you need to update your branch so it's easier to merge.
For something that is bigger than a one or two line fix:
- Create your own fork of the code
- Do the changes in your fork
- Make a pull request!
Small contributions such as fixing spelling errors can be submitted through our discord server or a issue
As a rule of thumb, changes are obvious fixes if they do not introduce any new functionality or creative thinking. As long as the change does not affect functionality, some likely examples include the following:
- Spelling / grammar fixes
- Typo correction, white space and formatting changes
- Bug fixes that change default return values or error codes stored in constants
- Adding logging messages or debugging output
- Changes to ‘metadata’ files like .gitignore, build scripts, etc.
- Moving source files from one directory or package to another
If you find a security vulnerability, do NOT open an issue. Please review the security document.
In order to determine whether you are dealing with a security issue, ask yourself these two questions:
- Can I access something that's not mine, or something I shouldn't have access to?
- Can I disable something for other people?
If the answer to either of those two questions are "yes", then you're probably dealing with a security issue. Note that even if you answer "no" to both questions, you may still be dealing with a security issue. When filing a bug report, please use our bug template.
- Make a issue and use our feature request template
Who reviews it? Who needs to sign off before it’s accepted? When should a contributor expect to hear from you? How can contributors get commit access, if at all?
These are the things im looking at when I'm reviewing code:
- Changes
- Security Flaws
- Bugs
After feedback has been given by the community, I will merge the pull request or add it and push it.
You can chat with us and the community in our discord server.
You can also chat with the community in the discussions
Thanks for reading. Happy coding!