Domů Procházet Nápověda
Přihlásit se
zhxd2
/
tripal_blast
1
0
Rozštěpit 0
Soubory Úkoly 0 Pull Requesty 0 Wiki
Strom: 9a44f8ee2d
Větve Značky
tripal_blast
/
docs
/
dev_guide
/
contribution.rst

contribution.rst 4.6 KB
Historie Surový

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071 
  1. Contribution Guidelines
    2. 

  2. ========================
    3. 

  3. 

  4. The following guidelines are meant to encourage contribution to Tripal BLAST UI source-code on GitHub by making the process open, transparent and collaborative.
    5. 

  5. 

  6. Github Communication Tips
    7. 

  7. ---------------------------
    8. 

  8. - Don't be afraid to mention people (@username) who are knowledgeable on the topic or invested.  *We are academics and overcommitted, it's too easy for issues to go unanswered: don't give up on us!*
    9. 

  9. - Likewise, don't be shy about bumping an issue if no one responds after a few days. *Balancing responsibilities is hard.*
    10. 

  10. - Want to get more involved? Issues marked with "Good beginner issue" are a good place to start if you want to try your hand at submitting a PR.
    11. 

  11. - Everyone is encouraged/welcome to comment on the issue queue! Tell us if you
    12. 

  12. 

  13.     - are experiencing the same problem
    14. 

  14.     - have tried a suggested fix
    15. 

  15.     - know of a potential solution or work-around
    16. 

  16.     - have an opinion, idea or feedback of any kind!
    17. 

  17. 

  18. - Be kind when interacting with others on Github! (see Code of Conduct below for further guidelines). We want to foster a welcoming, inclusive community!
    19. 

  19. 

  20.     - Constructive criticism is welcome and encouraged but should be worded such that it is helpful :-) Direct criticism towards the idea or solution rather than the person and focus on alternatives or improvements.
    21. 

  21. 

  22. Bugs
    23. 

  23. -----
    24. 

  24. - Every bug **should** be reported as a Github issue.
    25. 

  25. 

  26.     - Even if a bug is found by a committer who intends to fix it themselves immediately, they **should** create an issue and assign it to themselves to show their intent.
    27. 

  27. 

  28. - Please follow the issue templates as best you can.  This information makes discussion easier and helps us resolve the problem faster.
    29. 

  29. 

  30.     - Also provide as much information as possible :-)  Screenshots or links to the issue on a development site can go a long way!
    31. 

  31. 

  32. Feature Requests
    33. 

  33. ------------------
    34. 

  34. - Every feature request should start as an issue so that discussion is encouraged :-)
    35. 

  35. - Please provide the following information (bold is required; underlined strengthens your argument):
    36. 

  36. 

  37.     - **Use Case:** fully describe why you need/want this feature
    38. 

  38.     - Generally Applicable: Why do you feel this is generally applicable? Suggest other use cases if possible. Mention (@) others that might want/need this feature.
    39. 

  39.     - Implementation: Describe a possible implementation. Bonus points for configuration, use of ontologies, ease of use, permission control, security considerations
    40. 

  40. 

  41. - All features **should** be optional so that site admin can choose to make it available to their users.
    42. 

  42. 

  43.     - When applicable, new features should be designed such that site admin can disable them.
    44. 

  44.     - Bonus points: for making new features configurable and easily themed.
    45. 

  45. 

  46. Pull Request (PR) Guideline
    47. 

  47. ----------------------------
    48. 

  48. The goal of this document is to make it easy for **A)** contributors to make pull requests that will be accepted, and **B)** Tripal committers to determine if a pull request should be accepted.
    49. 

  49. - PRs that address a specific issue **must** link to the related issue page.
    50. 

  50. 

  51.     - Really in almost every case, there should be an issue for a PR.  This allows feedback and discussion before the coding happens.  Not grounds to reject, but encourage users to create issues at start of their PR.  Better late than never :).
    52. 

  52. 

  53. - Each PR **must** be tested/approved by at least one "trusted committer."
    54. 

  54. 

  55.     - Testers **should** describe how the testing was performed if applicable (allows others to replicate the test).
    56. 

  56.     - Our guiding philosophy is to encourage open contribution.  With this in mind, committers should **work with contributors** to resolve issues in their PRs.  PRs that will not be merged should be closed, **transparently citing** the reason for closure.  In an ideal world, features that would be closed are discouraged at the **issue phase** before the code is written!
    57. 

  57.     - The pull request branch should be deleted after merging (if not from a forked repository) by the person who performs the merge.
    58. 

  58. 

  59. - PRs **should** pass all Travis-CI tests before they are merged.
    60. 

  60. - Branches **should** follow the following format: [issue\_number]-[short\_description]
    61. 

  61. - **Must** follow `Drupal code standards: <https://www.drupal.org/docs/develop/standardshttps://www.drupal.org/docs/develop/standards>`_
    62. 

  62. - PRs for new feature should remain open until adequately discussed (see guidelines below).
    63. 

  63. 

  64. .. note::
    65. 

  65. 

  66.   If you need more instructions creating a pull request, see for example the `KnowPulse workflow <https://github.com/UofS-Pulse-Binfo/KnowPulse/blob/master/Workflow.md)>`_
    67. 

  67. 

  68. Code of Conduct
    69. 

  69. ----------------
    70. 

  70. 

  71. - Be nice!  If that's insufficient, Tripal community defers to https://www.contributor-covenant.org/
    72.