Merge pull request #93 from TACC-Cloud/develop

Merge develop for v3.0.0 release

Author: alejandrox1

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,28 @@
+---
+name: Bug report
+about: Create a report to help us improve
+
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**To Reproduce**
+Steps to reproduce the behavior:
+1. Go to '...'
+2. Click on '....'
+3. Scroll down to '....'
+4. See error
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Screenshots**
+If applicable, add screenshots to help explain your problem.
+
+**Desktop (please complete the following information):**
+ - OS: [e.g. iOS]
+ - Version [e.g. 22]
+
+**Additional context**
+Add any other context about the problem here.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,17 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+
+---
+
+**Is your feature request related to a problem? Please describe.**
+A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+
+**Describe the solution you'd like**
+A clear and concise description of what you want to happen.
+
+**Describe alternatives you've considered**
+A clear and concise description of any alternative solutions or features you've considered.
+
+**Additional context**
+Add any other context or screenshots about the feature request here.

.travis.yml

@@ -0,0 +1,293 @@
+# Contribute to Agave-CLI
+
+Want to contribute? Awesome! We have a contributor's guide that explains
+[setting up a development environment and the contribution process](docs/contributing/). 
+
+This page contains information about reporting issues as well as some tips and
+guidelines useful to experienced open source contributors.
+Finally, make sure
+you read our [community guidelines](#community-guidelines) before you
+start participating.
+
+## Topics
+
+* [Reporting Security Issues](#reporting-security-issues)
+* [Design and Cleanup Proposals](#design-and-cleanup-proposals)
+* [Reporting Issues](#reporting-other-issues)
+* [Quick Contribution Tips and Guidelines](#quick-contribution-tips-and-guidelines)
+* [Comunity Guidelines](#community-guidelines)
+
+## Reporting security issues
+
+The Maintainers take security seriously. If you discover a security
+issue, please bring it to their attention right away!
+
+Please **DO NOT** file a public issue, instead send your report privately to
+[jochoa@tacc.utexas.edu](mailto:jochoa@tacc.utexas.edu).
+
+Security reports are greatly appreciated and we will publicly thank you for it.
+
+
+## Reporting other issues
+
+A great way to contribute to the project is to send a detailed report when you
+encounter an issue. We always appreciate a well-written, thorough bug report,
+and will thank you for it!
+
+Check that [our issue database](https://github.com/TACC-Cloud/agave-cli/issues)
+doesn't already include that problem or suggestion before submitting an issue.
+If you find a match, you can use the "subscribe" button to get notified on
+updates. Do *not* leave random "+1" or "I have this too" comments, as they
+only clutter the discussion, and don't help resolving it. However, if you
+have ways to reproduce the issue or have additional information that may help
+resolving the issue, please leave a comment.
+
+When reporting issues, always include:
+
+* The version of the operating system you are using.
+
+Also include the steps required to reproduce the problem if possible and
+applicable. This information will help us review and fix your issue faster.
+When sending lengthy log-files, consider posting them as a gist (https://gist.github.com).
+Don't forget to remove sensitive data from your logfiles before posting (you can
+replace those parts with "REDACTED").
+
+## Quick contribution tips and guidelines
+
+This section gives the experienced contributor some tips and guidelines.
+
+### Pull requests are always welcome
+
+Not sure if that typo is worth a pull request? Found a bug and know how to fix
+it? Do it! We will appreciate it. Any significant improvement should be
+documented as [a GitHub issue](https://github.com/TACC-Cloud/agave-cli/issues) before
+anybody starts working on it.
+
+We are always thrilled to receive pull requests. We do our best to process them
+quickly. If your pull request is not accepted on the first try,
+don't get discouraged!
+
+
+### Design and cleanup proposals
+
+You can propose new designs for existing features. You can also design
+entirely new features. We really appreciate contributors who want to refactor or
+otherwise cleanup our project. 
+
+
+### Conventions
+
+Fork the repository and make changes on your fork in a feature branch:
+
+- If it's a bug fix branch, name it XXXX-something where XXXX is the number of
+	the issue. 
+- If it's a feature branch, create an enhancement issue to announce
+	your intentions, and name it XXXX-something where XXXX is the number of the
+	issue.
+
+Submit tests for your changes. See [TESTING.md](./TESTING.md) for details.
+
+Update the documentation when creating or modifying features. Test your
+documentation changes for clarity, concision, and correctness, as well as a
+clean documentation build. 
+
+Write clean code. Universally formatted code promotes ease of writing, reading,
+and maintenance.
+We follow the [Google Python Style Guide](https://github.com/google/styleguide/blob/gh-pages/pyguide.md).
+
+Pull request descriptions should be as clear as possible and include a reference
+to all the issues that they address.
+
+### Successful Changes
+
+Before contributing large or high impact changes, make the effort to coordinate
+with the maintainers of the project before submitting a pull request. This
+prevents you from doing extra work that may or may not be merged.
+
+Large PRs that are just submitted without any prior communication are unlikely
+to be successful.
+
+While pull requests are the methodology for submitting changes to code, changes
+are much more likely to be accepted if they are accompanied by additional
+engineering work. While we don't define this explicitly, most of these goals
+are accomplished through communication of the design goals and subsequent
+solutions. Often times, it helps to first state the problem before presenting
+solutions.
+
+Typically, the best methods of accomplishing this are to submit an issue,
+stating the problem. This issue can include a problem statement and a
+checklist with requirements. If solutions are proposed, alternatives should be
+listed and eliminated. Even if the criteria for elimination of a solution is
+frivolous, say so.
+
+Larger changes typically work best with design documents. These are focused on
+providing context to the design at the time the feature was conceived and can
+inform future documentation contributions.
+
+### Commit Messages
+
+Commit messages must start with a capitalized and short summary (max. 50 chars)
+written in the imperative, followed by an optional, more detailed explanatory
+text which is separated from the summary by an empty line.
+
+Commit messages should follow best practices, including explaining the context
+of the problem and how it was solved, including in caveats or follow up changes
+required. They should tell the story of the change and provide readers
+understanding of what led to it.
+
+If you're lost about what this even means, please see [How to Write a Git
+Commit Message](http://chris.beams.io/posts/git-commit/) for a start.
+
+In practice, the best approach to maintaining a nice commit message is to
+leverage a `git add -p` and `git commit --amend` to formulate a solid
+changeset. This allows one to piece together a change, as information becomes
+available.
+
+If you squash a series of commits, don't just submit that. Re-write the commit
+message, as if the series of commits was a single stroke of brilliance.
+
+That said, there is no requirement to have a single commit for a PR, as long as
+each commit tells the story. For example, if there is a feature that requires a
+package, it might make sense to have the package in a separate commit then have
+a subsequent commit that uses it.
+
+Remember, you're telling part of the story with the commit message. Don't make
+your chapter weird.
+
+### Review
+
+Code review comments may be added to your pull request. Discuss, then make the
+suggested modifications and push additional commits to your feature branch. Post
+a comment after pushing. New commits show up in the pull request automatically,
+but the reviewers are notified only when you comment.
+
+Pull requests must be cleanly rebased on top of master without multiple branches
+mixed into the PR.
+
+**Git tip**: If your PR no longer merges cleanly, use `rebase master` in your
+feature branch to update your pull request rather than `merge master`.
+
+Before you make a pull request, squash your commits into logical units of work
+using `git rebase -i` and `git push -f`. A logical unit of work is a consistent
+set of patches that should be reviewed together: for example, upgrading the
+version of a vendored dependency and taking advantage of its now available new
+feature constitute two separate units of work. Implementing a new function and
+calling it in another file constitute a single logical unit of work. The very
+high majority of submissions should have a single commit, so if in doubt: squash
+down to one.
+
+After every commit, [make sure the test suite passes](./TESTING.md). Include
+documentation changes in the same pull request so that a revert would remove
+all traces of the feature or fix.
+
+Include an issue reference like `Closes #XXXX` or `Fixes #XXXX` in commits that
+close an issue. Including references automatically closes the issue on a merge.
+
+Please do not add yourself to the `AUTHORS` file, as it is regenerated regularly
+from the Git history.
+
+Please see the [Coding Style](#coding-style) for further guidelines.
+
+### Merge approval
+
+Maintainers use LGTM (Looks Good To Me) in comments on the code review to
+indicate acceptance, or use the Github review approval feature.
+
+
+### Sign your work
+
+The sign-off is a simple line at the end of the explanation for the patch. Your
+signature certifies that you wrote the patch or otherwise have the right to pass
+it on as an open-source patch. The rules are pretty simple: if you can certify
+the below (from [developercertificate.org](http://developercertificate.org/)):
+
+```
+Developer Certificate of Origin
+Version 1.1
+
+Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
+1 Letterman Drive
+Suite D4700
+San Francisco, CA, 94129
+
+Everyone is permitted to copy and distribute verbatim copies of this
+license document, but changing it is not allowed.
+
+Developer's Certificate of Origin 1.1
+
+By making a contribution to this project, I certify that:
+
+(a) The contribution was created in whole or in part by me and I
+    have the right to submit it under the open source license
+    indicated in the file; or
+
+(b) The contribution is based upon previous work that, to the best
+    of my knowledge, is covered under an appropriate open source
+    license and I have the right under that license to submit that
+    work with modifications, whether created in whole or in part
+    by me, under the same open source license (unless I am
+    permitted to submit under a different license), as indicated
+    in the file; or
+
+(c) The contribution was provided directly to me by some other
+    person who certified (a), (b) or (c) and I have not modified
+    it.
+
+(d) I understand and agree that this project and the contribution
+    are public and that a record of the contribution (including all
+    personal information I submit with it, including my sign-off) is
+    maintained indefinitely and may be redistributed consistent with
+    this project or the open source license(s) involved.
+```
+
+Then you just add a line to every git commit message:
+
+    Signed-off-by: Joe Smith <joe.smith@email.com>
+
+Use your real name (sorry, no pseudonyms or anonymous contributions.)
+
+If you set your `user.name` and `user.email` git configs, you can sign your
+commit automatically with `git commit -s`.
+
+## community guidelines
+The guidelines are simple: be courteous to others, write readable code, and
+remeber that the repo is the source of all truth (any discussion pertaiing this
+project will be held in issues and PRs).
+
+## Coding Style
+
+Unless explicitly stated, we follow all coding guidelines from the Go
+community. While some of these standards may seem arbitrary, they somehow seem
+to result in a solid, consistent codebase.
+
+It is possible that the code base does not currently comply with these
+guidelines. We are not looking for a massive PR that fixes this, since that
+goes against the spirit of the guidelines. All new contributions should make a
+best effort to clean up and make the code base better than they left it.
+Obviously, apply your best judgement. Remember, the goal here is to make the
+code base easier for humans to navigate and understand. Always keep that in
+mind when nudging others to comply.
+
+The rules:
+
+1. Recommended: Format code using [`yapf`](https://github.com/google/yapf/) 
+   (`yapf -i --style=google src.py`).
+2. All code should pass the default levels of
+   [`pylint`](https://www.pylint.org/).
+3. Comment the code. Tell us the why, the history and the context.
+4. Document _all_ declarations and methods, even private ones. Declare
+   expectations, caveats and anything else that may be important.
+5. Variable name length should be proportional to its context and no longer.
+   `noCommaALongVariableNameLikeThisIsNotMoreClearWhenASimpleCommentWouldDo`.
+   In practice, short methods will have short variable names and globals will
+   have longer names.
+6. No underscores in package names. If you need a compound name, step back,
+   and re-examine why you need a compound name. If you still think you need a
+   compound name, lose the underscore.
+7. No utils or helpers packages. If a function is not general enough to
+   warrant its own package, it has not been written generally enough to be a
+   part of a util package. Just leave it unexported and well-documented.
+8. Even though we call these "rules" above, they are actually just
+    guidelines. Since you've read all the rules, you now know that.
+
+For more information read [PEP 8 - Style Guide for Python Code](https://www.python.org/dev/peps/pep-0008/?#package-and-module-names).