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.

49 lines
2.0 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'll probably want to
  25. pattern it after the tests in
  26. [base.go](https://github.com/go-xorm/tests/blob/master/base.go) AND
  27. [benchmark.go](https://github.com/go-xorm/tests/blob/master/benchmark.go).
  28. If you implements a new database interface, you maybe need to add a <databasename>_test.go file.
  29. For example, [mysql_test.go](https://github.com/go-xorm/tests/blob/master/mysql/mysql_test.go)
  30. ### New functionality
  31. There are a number of pending patches for new functionality, so
  32. additional feature patches will take a while to merge. Still, patches
  33. are generally reviewed based on usefulness and complexity in addition
  34. to time-in-queue, so if you have a knockout idea, take a shot. Feel
  35. free to open an issue discussion your proposed patch beforehand.