You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

46 lines
1.9 KiB

  1. ## Contributing to xorm
  2. `xorm` has a backlog of [pull requests](https://help.github.com/articles/using-pull-requests), but contributions are still very
  3. much welcome. You can help with patch review, submitting bug reports,
  4. or adding new functionality. There is no formal style guide, but
  5. please conform to the style of existing code and general Go formatting
  6. conventions when submitting patches.
  7. * [fork a repo](https://help.github.com/articles/fork-a-repo)
  8. * [creating a pull request ](https://help.github.com/articles/creating-a-pull-request)
  9. ### Language
  10. Since `xorm` is a world-wide open source project, please describe your issues or code changes in English as soon as possible.
  11. ### Sign your codes with comments
  12. ```
  13. // !<you github id>! your comments
  14. e.g.,
  15. // !lunny! this is comments made by lunny
  16. ```
  17. ### Patch review
  18. Help review existing open [pull requests](https://help.github.com/articles/using-pull-requests) by commenting on the code or
  19. proposed functionality.
  20. ### Bug reports
  21. We appreciate any bug reports, but especially ones with self-contained
  22. (doesn't depend on code outside of xorm), minimal (can't be simplified
  23. further) test cases. It's especially helpful if you can submit a pull
  24. request with just the failing test case(you can find some example test file like [session_get_test.go](https://gitea.com/xorm/xorm/src/branch/master/session_get_test.go)).
  25. If you implements a new database interface, you maybe need to add a test_<databasename>.sh file.
  26. For example, [mysql_test.go](https://gitea.com/xorm/xorm/src/branch/master/test_mysql.sh)
  27. ### New functionality
  28. There are a number of pending patches for new functionality, so
  29. additional feature patches will take a while to merge. Still, patches
  30. are generally reviewed based on usefulness and complexity in addition
  31. to time-in-queue, so if you have a knockout idea, take a shot. Feel
  32. free to open an issue discussion your proposed patch beforehand.