Merge pull request #52 from tripal/docs

Added Tripal Daemon and contribution docs.

docs/dev_guide.rst

@@ -9,4 +9,5 @@ A guide for module developers on how to customize and/or extend Tripal BLAST UI.
    :caption: Contents:
 
    dev_guide/custom_linkouts
-   dev_guide/custom_styling.rst
+   dev_guide/custom_styling
+   dev_guide/contribution

docs/dev_guide/contribution.rst

@@ -0,0 +1,71 @@
+Contribution Guidelines
+========================
+
+The following guidelines are meant to encourage contribution to Tripal BLAST UI source-code on GitHub by making the process open, transparent and collaborative.
+
+Github Communication Tips
+---------------------------
+- 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!*
+- Likewise, don't be shy about bumping an issue if no one responds after a few days. *Balancing responsibilities is hard.*
+- 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.
+- Everyone is encouraged/welcome to comment on the issue queue! Tell us if you
+
+    - are experiencing the same problem
+    - have tried a suggested fix
+    - know of a potential solution or work-around
+    - have an opinion, idea or feedback of any kind!
+
+- Be kind when interacting with others on Github! (see Code of Conduct below for further guidelines). We want to foster a welcoming, inclusive community!
+
+    - 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.
+
+Bugs
+-----
+- Every bug **should** be reported as a Github issue.
+
+    - 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.
+
+- Please follow the issue templates as best you can.  This information makes discussion easier and helps us resolve the problem faster.
+
+    - Also provide as much information as possible :-)  Screenshots or links to the issue on a development site can go a long way!
+
+Feature Requests
+------------------
+- Every feature request should start as an issue so that discussion is encouraged :-)
+- Please provide the following information (bold is required; underlined strengthens your argument):
+
+    - **Use Case:** fully describe why you need/want this feature
+    - Generally Applicable: Why do you feel this is generally applicable? Suggest other use cases if possible. Mention (@) others that might want/need this feature.
+    - Implementation: Describe a possible implementation. Bonus points for configuration, use of ontologies, ease of use, permission control, security considerations
+
+- All features **should** be optional so that site admin can choose to make it available to their users.
+
+    - When applicable, new features should be designed such that site admin can disable them.
+    - Bonus points: for making new features configurable and easily themed.
+
+Pull Request (PR) Guideline
+----------------------------
+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.
+- PRs that address a specific issue **must** link to the related issue page.
+
+    - 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 :).
+
+- Each PR **must** be tested/approved by at least one "trusted committer."
+
+    - Testers **should** describe how the testing was performed if applicable (allows others to replicate the test).
+    - 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!
+    - The pull request branch should be deleted after merging (if not from a forked repository) by the person who performs the merge.
+
+- PRs **should** pass all Travis-CI tests before they are merged.
+- Branches **should** follow the following format: [issue\_number]-[short\_description]
+- **Must** follow `Drupal code standards: <https://www.drupal.org/docs/develop/standardshttps://www.drupal.org/docs/develop/standards>`_
+- PRs for new feature should remain open until adequately discussed (see guidelines below).
+
+.. note::
+
+  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)>`_
+
+Code of Conduct
+----------------
+
+- Be nice!  If that's insufficient, Tripal community defers to https://www.contributor-covenant.org/

docs/user_guide.rst

@@ -15,5 +15,6 @@ The BLAST results page is an expandable summary table with each hit being listed
 
    user_guide/features
    user_guide/install
+   user_guide/tripal_daemon
    user_guide/targetdbs
    user_guide/cvitjs

docs/user_guide/tripal_daemon.rst

@@ -0,0 +1,18 @@
+
+Running Jobs Automatically
+===========================
+
+BLAST submissions result in the creation of Tripal jobs which then need to run from the command-line. This ensures that long running BLASTs will not cause page time-outs but does add some management overhead and might result in longer waits for users depending on how often you have cron set to run Tripal jobs. You can alternatively use the Tripal Jobs Daemon to automate running of Tripal Jobs reducing user wait time and your own workload.
+
+.. note::
+
+  `Tripal Daemon Documentation <https://tripal.readthedocs.io/en/latest/user_guide/job_management.html>`_
+
+.. warning::
+
+  If you find jobs are not running automatically, you may need to restart the Tripal Daemon. This is also necessary after a server restart. Navigate to your drupal root (e.g. ``/var/www/html``) on the command-line and run:
+
+  .. code:: bash
+
+    drush trpjob-daemon stop
+    drush trpjob-daemon start