Initial commit

CODE_OF_CONDUCT.md

@@ -0,0 +1,86 @@
+## Contributor Covenant Code of Conduct
+
+
+### Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project
+and our community a harassment-free experience for everyone, regardless of
+age, body size, disability, ethnicity, sex characteristics, gender identity
+and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, religion, or sexual identity and
+orientation.
+
+
+### Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+- Gracefully accepting constructive criticism
+- Being respectful of differing viewpoints and experiences
+- Focusing on what is best for the community
+- Using welcoming and inclusive language
+- Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+- Trolling, insulting/derogatory comments, and personal or political
+  attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+- The use of sexualized language or imagery and unwelcome sexual attention
+  or advances
+
+
+### Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of
+acceptable behavior and are expected to take appropriate and fair
+corrective action in response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem
+inappropriate, threatening, offensive, or harmful.
+
+
+### Scope
+
+This Code of Conduct applies both within project spaces and in public
+spaces when an individual is expressly representing the project or its
+community.  Examples of representing a project or community include using
+an official project e-mail address, posting via an official project social
+media account, or acting as an appointed representative at an online or
+offline event.  Association with a project does not in itself imply
+representation of the project.  Representation may be further defined and
+clarified by project maintainers.
+
+
+### Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at <sgtsnepi@cs.duke.edu>.  All
+complaints will be reviewed and investigated and will result in a response
+that is deemed necessary and appropriate to the circumstances.  The project
+team is obligated to maintain confidentiality with regard to the reporter
+of an incident.  Further details of specific enforcement policies may be
+posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in
+good faith may face temporary or permanent repercussions as determined by
+other members of the project's leadership.
+
+
+### Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 1.4, available at
+<https://www.contributor-covenant.org/version/1/4/code-of-conduct.html>.
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see
+<https://www.contributor-covenant.org/faq>.

CONTRIBUTING.md

@@ -0,0 +1,127 @@
+## Contributing to SG-t-SNE-Π
+
+
+We welcome contributions that help improve the SG-t-SNE-Π project!  Please read
+through the guidelines in this document before reporting an issue or
+submitting a request.  We will do our best to respond to all issues and
+requests, but please bear in mind that it may take us a while.
+
+
+
+<a name="toc"></a>
+
+### Contents
+
+
+- [Types of contributions](#contrib-types)
+- [Bug reports](#bug-reports)
+- [Pull requests](#pull-requests)
+- [Code and documentation style](#style)
+
+
+
+<a name="contrib-types"></a>
+
+### Types of contributions
+
+
+-   Bug reports.
+-   Compatibility patches (support for different `C++` compilers).
+-   Minor patches (documentation clarification and typos;
+    code/documentation formatting; naming convention amendments).
+-   Functionality updates.
+-   Testing (testing or demo scripts for existing functionality).
+-   Re-implementations (performance improvements; system/language support
+    extensions).
+-   Anything else, as long as its utility and functionality is described.
+
+
+
+<a name="bug-reports"></a>
+
+### Bug reports
+
+
+Please [open a new issue][github-new-issue] for each unreported bug.
+Specify "[BUG] *1-sentence-description-of-bug*" as the issue title, and
+list the following information in the issue body:
+
+-   Brief summary and background.
+-   Bug description: what should happen, and what happens instead.
+-   Version of compiler, operating system, and relevant libraries.
+-   Code for a concise script that reproduces and illustrates the
+    bug.
+-   Any other relevant notes (e.g., what you think causes the bug, any
+    steps you may have taken to identify or resolve it, etc).
+
+
+[github-new-issue]: https://help.github.com/articles/creating-an-issue/
+
+
+
+<a name="pull-requests"></a>
+
+### Pull requests
+
+
+Please submit a [pull request][github-pull-request] for each code or
+documentation contribution to SG-t-SNE-Π.  When submitting a pull request, please
+adhere to the following.
+
+-   Clearly identify the [type of your contribution](#contrib-types) in the
+    title and body of your pull request.
+    -   If your contributions span multiple types, please separate them
+        into individual pull requests.  Minor patches should be lumped into
+        a single pull request.
+-   Include a brief description of the rationale, functionality, and
+    implementation of your contribution.
+-   Include a testing or demo script (named `test_xxx` or
+    `demo_xxx`) that can be used to illustrate and validate your
+    contribution.  Include a brief description of the script in the pull
+    request body.
+-   [Squash partial commits][github-squash-commit].
+-   If applicable, draft some relevant text to be added to or amended in
+    the README.  Please include the text in the pull request comments,
+    *not* as part of the commit.
+
+We encourage you to open a new issue to discuss any intended contributions
+prior to developing or submitting a pull request.
+
+
+[github-pull-request]:  https://help.github.com/articles/about-pull-requests/
+
+[github-squash-commit]: https://help.github.com/articles/about-pull-request-merges/
+
+
+
+<a name="style"></a>
+
+### Code and documentation style
+
+
+Please try to follow the style conventions in the SG-t-SNE-Π repository when submitting pull requests.  Use [Doxygen][doxygen-documentation] to document functions and scripts.  We generally try to observe the following rules:
+
+-   The code should be clear, stable, and efficient.  Clarity and stability
+    take precedence over efficiency and performance.  The code should be
+    self-documented if possible (avoid referring to descriptions in
+    existing issues or pull requests).
+-   Function interface documentation should be comprehensive and follow the
+    format of existing functions (e.g., `sgtsnepi`).
+-   Function and variable names are in `camelCase`; script names are in
+    `snake_case`.  Typically, matrix/array names start with an uppercase
+    letter, while scalar/vector/function names start with a lowercase
+    letter.
+-   All code blocks should be briefly documented.
+-   We prefer 2-space indentation (no tabs), operator/operand alignment
+    across multiple lines, and 80-column line width.
+
+[doxygen-documentation]:  http://www.doxygen.nl
+
+<!-- <a name="feature-requests"></a> -->
+
+<!-- ### Feature requests -->
+
+
+<!-- It is unlikely that we will do much development for new features, unless -->
+<!-- they are essential or supported by theoretical advances.  We do, however, -->
+<!-- encourage the development and submission of new features via pull requests. -->