WIP

Signed-off-by: Andrew Stein <steinlink@gmail.com>

.github/ISSUE_TEMPLATE/Bug_report.md

@@ -1,24 +1,126 @@
 ---
-name: 🐛 Bug Report
-about: If something isn't working as expected 🤔.
-
+name: Bug Report
+about: If something isn't working as expected.
 ---
 
 ## Bug Report
 
 ### Steps to Reproduce:
- 1. ...step 1 description...
- 2. ...step 2 description...
- 3. ...step 3 description...
+
+Please provide a full reproduction of the issue. There are three ways we accept
+repros:
+
+1.  If the issue you are reporting is a UX/UI issue which can be recreated by
+    visiting a Perspective demo _hosted by the project itself_, and any dataset
+    required to reproduce the error can be included in the report. In this case,
+    please provide detailed step-by-step instructions on how to reproduce,
+    including any screenshots which help illustrate, as well as including any
+    fully-encoded test data we may need.
+
+2.  If you are reporting a build or installation issue with the library itself,
+    which can be recreated from a shell. In this case, please provided detailed
+    code blocks describing how you tried to install, which commands were issued,
+    including and dependencies you needed to install and hwo you installed them.
+
+3.  If you are reporting a _anything else_, including but not limited to:
+
+    -   Build issues which require _any_ metadata files e.g. a `package.json`,
+        `Cargo.toml`, etc
+    -   Bundler or packaging errors with JavaScript
+    -   Library functions which return the wrong results or error
+    -   CPU or memory usage performance regressions, or regressions in thread
+        utilization
+
+    In this case, we require a _complete reproduction_ of the issue in the form
+    of a repository. Quoting this exceptional definition from
+    [@Rich-Harris's micro-essay on Repros](https://gist.github.com/Rich-Harris/88c5fc2ac6dc941b22e7996af05d70ff),
+    please follow these guidelines:
+
+    > 1.  Create a sample repo on GitHub (or wherever)
+    > 2.  Demonstrate the problem, and nothing but the problem. If the app where
+    >     you're experiencing the issue happens to use Gulp, I don't care,
+    >     unless the problem involves Gulp. Remove that stuff. Whittle it down
+    >     to the _bare minimum_ of code that reliably demonstrates the issue.
+    >     Get rid of any dependencies that aren't _directly_ related to the
+    >     problem.
+    > 3.  Install all your dependencies to `package.json`. If I can't clone the
+    >     repo and do `npm install && npm run build` (or similar – see point 4)
+    >     to see the problem, because I need some globally installed CLI tool or
+    >     whatever, then you've made it harder to get to the bottom of the
+    >     issue.
+    > 4.  Include instructions in the repo, along with a description of the
+    >     expected and actual behaviour. Obviously the issue should include
+    >     information about the bug as well, but it's really helpful if
+    >     `README.md` includes that information, plus a link back to the issue.
+    >     If there are any instructions beyond `npm install && npm run build`,
+    >     they should go here.
+
+    Some examples which _do not_ qualify as _complete_ and are mostly useless to
+    us for debugging:
+
+    -   Instructions which ask us to visit a website or download an application,
+        even if it is _completely_ open source (and expecially if it is not)
+    -   Instructions which just describe how to create a project, e.g. with a
+        specific build tool or template
+    -   Screenshots of exceptions
+    -   Screenshots of code
+    -   Code snippets copied from a larger application context
 
 ### Expected Result:
-...description of what you expected to see...
+
+Describe what you expected to see. If you are reporting a UX/UI error, this may
+include screenshots with annotations.
 
 ### Actual Result:
-...what actually happened, including full exceptions (please include the entire stack trace, including "caused by" entries), log entries, screen shots etc. where appropriate...
+
+Describe what actually happened, with special attention to the errant behavior.
+Always include:
+
+-   OS and version
+-   Platform/language + version
+
+If you are reporting a UX/UI error:
+
+-   (if websocket) Platform/language + version of remote perspective server.
+-   Full exception/error message if applicable.
+-   Any potentially relevent JavaScript developer console error logs.
+-   Screenshots of the UI in an obviously broken state. (but please try to avoid
+    screenshots of your code, see below)
+
+If you are reporting a library error:
+
+-   (if websocket) Platform/language + version of remote perspective server.
+-   Full exception error capture (please include the entire stack trace,
+    including "caused by" entries), log entries, etc. where appropriate. Please
+    avoid posting screenshots of code (which we may need to debug).
+
+If you are reporting a build or install error:
+
+-   Full error output from running your repro, formatted as a code block (please
+    _do not_ include screenshots of build logs).
 
 ### Environment:
-...version and build of the project, OS and runtime versions, virtualised environment (if any), etc. ...
+
+For JavaScript (browser):
+
+-   `@finos/perspective` version
+-   Browser and version
+-   OS
+-   (if websocket) Language/version/OS of perspective server
+
+For Node.js:
+
+-   `node` version
+-   OS
+
+For Python
+
+-   `python` interpreter version (Only CPython).
+-   package manager and version (conda/pip/\*)
+    -   Are you compiling from an sdist of wheel?
+-   Platform and version (Jupyter/tornado/lib/\*)
+-   OS
 
 ### Additional Context:
-...add any other context about the problem here. If applicable, add screenshots to help explain...
+
+Add any other context about the problem here.

.github/ISSUE_TEMPLATE/Feature_request.md

@@ -1,17 +1,22 @@
 ---
-name: 🚀 Feature Request
-about: I have a suggestion (and may want to implement it 🙂)!
-
+name: Feature Request
+about: I have a suggestion.
 ---
 
 ## Feature Request
 
 ### Description of Problem:
-...what *problem* are you trying to solve that the project doesn't currently solve?
 
-...please resist the temptation to describe your request in terms of a solution.  Job Story form ("When [triggering condition], I want to [motivation/goal], so I can [outcome].") can help ensure you're expressing a problem statement.
+...what _problem_ are you trying to solve that the project doesn't currently
+solve?
+
+...please resist the temptation to describe your request in terms of a solution.
+Job Story form ("When [triggering condition], I want to [motivation/goal], so I
+can [outcome].") can help ensure you're expressing a problem statement.
 
 ### Potential Solutions:
-...clearly and concisely describe what you want to happen. Add any considered drawbacks.
+
+...clearly and concisely describe what you want to happen. Add any considered
+drawbacks.
 
 ... if you've considered alternatives, clearly and concisely describe those too.

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,10 @@
+### Pull Request Checklist
+
+-   [ ] Description which clearly states what problems the PR solves.
+-   [ ] Description contains a link to the Github Issue, and any relevent
+        Discussions, this PR applies to.
+-   [ ] Include new tests that fail without this PR but passes with it.
+-   [ ] Include any relevent Documentation changes related to this change.
+-   [ ] Verify all commits have been _signed_ in accordance with the DCO policy.
+-   [ ] Reviewed PR commit history to remove unnecessary changes.
+-   [ ] Make sure your PR passes _build_, _test_ and _lint_ steps _completely_.

.github/workflows/build.yaml

@@ -154,7 +154,6 @@ jobs:
                   PACKAGE: "perspective-cpp,perspective,perspective-viewer,perspective-viewer-datagrid,perspective-viewer-d3fc,perspective-viewer-openlayers,perspective-workspace,perspective-cli"
                   # PSP_USE_CCACHE: 1
 
-
             # - name: Docs Build
             #   run: pnpm run docs
 
@@ -591,7 +590,7 @@ jobs:
             - name: Run Tests
               run: pnpm run test
               env:
-                  PACKAGE: "!perspective-python,!perspective-jupyterlab"
+                  PACKAGE: "perspective-cpp,perspective,perspective-viewer,perspective-viewer-datagrid,perspective-viewer-d3fc,perspective-viewer-openlayers,perspective-workspace,perspective-cli"
                   # PSP_USE_CCACHE: 1
 
     # ,--,--'      .   .-,--.     .  .

CONTRIBUTING.md

@@ -14,30 +14,45 @@ When submitting or commenting on an Issue, please respect the following
 guidelines. Github Issues are Perspective's project record of bugs and feature
 development, e.g. for publishing a release's Changelog, and as such it is
 important to keep them informative and on-topic. As such, please understand that
-we may remove or reclassify comments or Issues which violate the guidelines.
+we may remove or reclassify comments, Issues or PRs which violate the
+guidelines.
+
+Please note that due to the we may close your Issue or Pull Request for one of
+the reasons listed here or in the associated contribution template. If you find
+your contribution closed with a link to this document or a contribution
+template, please make sure you've followed the instructions closely before
+re-submitting.
 
 -   Be respectful and civil!
--   Use the provided Issue templates. If the templates don't fit your need,
-    please open a [discussion](https://github.com/finos/perspective/discussions)
-    instead.
+-   Use the provided Issue and Pull Request templates. If the templates don't
+    fit your need, please open a
+    [discussion](https://github.com/finos/perspective/discussions) instead.
 -   Don't ask for issues to be assigned to you if you're a first-time
     contributor. If you need help picking an issue to work on, please open a
     [discussion](https://github.com/finos/perspective/discussions).
 -   Don't add comments asking when a feature will be delivered or a reported
     issue fixed. The Issue will link any in-progress draft PRs or Milestones (if
     known).
 
-When submitting Pull Request (PR), please respect the following coding
+When submitting a Pull Request (PR), please respect the following coding
 guidelines:
 
+-   Don't open a PR without an associated
+    [Open Issue](https://github.com/finos/perspective/issues) which has been
+    tagged by a project maintainer.
+-   Make sure your PR passes _build_, _test_ and _lint_ steps _completely_
+    before opening a PR. Make _sure_ you've run these locally, even if you think
+    your change will not impact this step!
+-   Don't open a PR for auto-generated, AI-assisted or otherwise inauthentic
+    contributions.
 -   Sign commits (e.g. with `-s`) in accordance with the DCO policy detailed
     below, _before_ opening a PR.
--   Please make sure PRs include:
+-   Please make sure PRs include the following _not optional_ components:
 
     -   Tests asserting behavior of any new or modified features.
     -   Docs for any new or modified public APIs.
     -   [Benchmarks](https://perspective.finos.org/docs/development/#benchmark)
-        for any C++ changes.
+        for any performance-critical changes.
 
 -   Keep PRs clean, simple and to-the-point:
     -   Squash "WIP", "Reverting ..", etc., commits.
@@ -46,9 +61,6 @@ guidelines:
     -   Try to organize commits as functional components (as opposed to
         timeline-of-development).
 
-Please note that non substantive changes, large changes without prior
-discussion, etc, are not accepted and pull requests may be closed.
-
 ## DCO
 
 The Perspective project requires contributors to affirm their contributions via