Skip to content
This repository was archived by the owner on Jan 4, 2023. It is now read-only.

Latest commit

 

History

History
executable file
·
40 lines (25 loc) · 4.76 KB

CONTRIBUTING.md

File metadata and controls

executable file
·
40 lines (25 loc) · 4.76 KB

Contributing

👍 Thanks for offering to contribute to this project. Every contribution is greatly appreciated.

Code of Conduct

Everyone contributing to this project must adhere to the Code of Conduct.

If you feel that someone is not upholding this code, please reach out via email to open a discussion.

Issues & Bounties

You can help by search for an existing issue or opening a new issue to help find bugs that need to be fixed. If you are interested in working on a specific issue, reach out via email to be added to the repo and have the issue assigned to you. You can still work on an issue on your own but letting us know first helps avoid multiple people working on fixing the same bug.

Do open issues for questions, feature requests, proposals, bug reports, etc. Please do not open an issue for typos or other simple fixes; open a pull request instead.

Finally, we offer bounties for specific issues we are unable to directly fix due to time or knowledge. Bounties have the following 3 rules:

1: All source code written is yours to keep. This is NOT a work for hire; you retain full copyright ownership of the code you write. All I am asking is that Pixel Vision 8 gets the right to use/publish that code under the license used by the project. For example, if you release your code under MIT, but Pixel Vision 8 uses MS-PL, the code you contribute goes into the main project under MS-PL with a credit to you as the original creator. The Pixel Vision 8 license may change in the future, so any contributed code adopts the new license where applicable. If you use open-source code with a different license, please make that clear so the correct license and contributor are included. In the end, you can do whatever you want with the code you create after it is accepted. Feel free to continue to work on it, release it under your license, or use it in proprietary projects.

2: You are free to work on the project however you like. If you do a lot of programming on Twitch, for example, you can stream the whole process, and you can publish anything about the project you want, including technical write-ups and example projects. You can also work in whatever environment you want, as long as the final product works on the expected platforms with the expected languages/dependencies. Note, however, that the bounties state a schedule/timeline/budget and those are unlikely to change without a very detailed assessment explaining, for example, why a project could take longer than expected. If you contribute, feel free to put that contribution down on your resume or what have you. If we end up establishing a regular working relationship I am also happy to act as a professional reference for job applications.

3: You are responsible for taxable income made from these bounties. This one's pretty obvious but for those who aren't familiar, this is effectively non-employee income, and you need to pay taxes (depending on where you live). In the United States, for example, this is simply "Other Income" on line 21 of Form 1040. The exception to this rule is if you live in the United States and make more than $600 from my projects, at which point I need a Form W-9 sent to me so I can send you a 1099-MISC next year.

If you have any further questions, feel free to email me.

Pull Requests

All fixes and bounties should be submitted via pull requests. Each pull request should follow a few simple rules listed below:

  • The title must clearly define the work.
    • This allows maintainers to prioritize pull requests at a high level
    • This saves time because maintainers don't need to traverse the list of pull requests to read descriptions of the work
    • Caveat Pull requests with vague titles may be closed without commit (e.g. Use Fix typo of 'excldue' rather than Fix typo)
  • The description should expand on the work if it is not clearly represented in the title.
    • Linking to related issues and providing inputs/outputs of new behaviors helps maintainers and future users understand the contribution
  • Commit messages must be clear and concise, but not too concise.
    • Writing good commit messages results in quality history in every repository
    • Explain why the commit was created, how it functions at a high level, and who/what this may affect
    • There are some times when a commit may be subject-only, but these are rare. Examples may include Bump version to 1.0 or Add X as contributor