Compare commits

..
4 Commits
9 changed files with 259 additions and 2 deletions

No files matched your search

+18
View File
@@ -0,0 +1,18 @@
root = true
[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
indent_style = space
indent_size = 2
trim_trailing_whitespace = true
[*.md]
trim_trailing_whitespace = false
[*.py]
indent_size = 4
[Makefile]
indent_style = tab
+31
View File
@@ -0,0 +1,31 @@
---
name: Bug report
about: Report a reproducible problem in an existing experiment
title: ""
---
## Experiment and version
Link the affected directory and identify the commit or version.
## What happened?
Describe the observed result and what you expected.
## Reproduce it
1.
2.
3.
## Environment
Operating system, browser or runtime version, and relevant configuration. Use placeholder values for private configuration.
## Evidence
Include a minimal example or redacted screenshot/log. Do not post credentials, tokens, personal records, or private URLs.
## Checks already tried
State what you tried and what happened.
+25
View File
@@ -0,0 +1,25 @@
---
name: Experiment idea
about: Propose a small experiment or improvement
title: ""
---
## The idea
What would you like to explore or improve?
## Who would use it?
Explain the problem or question in concrete terms.
## Smallest useful version
Describe a bounded first version and what is outside its scope.
## How would we check it?
What result would show it works? What assumptions need testing?
## Sources and constraints
Link relevant public references. Note data, license, accessibility, or dependency constraints without sharing private material.
+24
View File
@@ -0,0 +1,24 @@
## Purpose
Explain the problem or question this change addresses. Link a related issue if one exists.
## Changes
-
## Verification
List exact commands or manual checks and their results. State what was not tested. Add screenshots for visual changes where useful.
## Review checklist
- [ ] The change is focused and documented.
- [ ] Setup and usage instructions match the actual files.
- [ ] New experiments are listed in docs/experiments.md.
- [ ] Sources and required license notices are included.
- [ ] Files, screenshots, and staged changes contain no secrets or private material.
- [ ] Limitations and unrun checks are stated clearly.
## Risks or follow-up
Describe remaining gaps, compatibility concerns, or rollback steps. Mark checklist items not applicable with an explanation.
+28
View File
@@ -0,0 +1,28 @@
# Local configuration and credentials: review content before every commit.
.env
.env.*
!.env.example
!.env.sample
*.pem
*.key
# OS and editor noise
.DS_Store
Thumbs.db
*.swp
*.swo
*~
# Common local dependencies and caches
node_modules/
.venv/
venv/
__pycache__/
*.py[cod]
.pytest_cache/
.mypy_cache/
.ruff_cache/
coverage/
.cache/
# Add experiment-specific generated files in that experiment's .gitignore.
+41
View File
@@ -0,0 +1,41 @@
# Contributing
Stash is a collection of small, self-contained public experiments. Keep each change focused and easy to try.
## Before you start
Search existing issues and pull requests. For a larger idea, explain the problem, intended audience, smallest useful version, and how you would know it works before building it.
## Add an experiment
1. Create a descriptive directory under experiments/.
2. Use [the README template](docs/experiment-template.md) to document it.
3. Add it to [the experiment index](docs/experiments.md).
4. Include dependency versions, exact run commands, sample input, and expected output where applicable.
5. Keep generated output and local dependencies out of Git unless they are intentional deliverables.
6. Identify third-party sources and retain their license notices.
## Open a pull request
Work on a branch and target main. Explain the purpose, list the changes, and include the commands and results of checks you actually ran. For visual work, include a screenshot and check narrow screens, keyboard navigation, and readable contrast where relevant. If a check was not run, say so. Do not claim CI has passed unless an actual run did.
Review the staged diff before publishing:
```sh
git diff --cached --check
git diff --cached
```
These commands check whitespace and show content; they do not detect all secrets or prove software works.
## Public-data checklist
- Use synthetic data or material explicitly approved for public release.
- Remove credentials, session tokens, private correspondence, and personal records from files and screenshots.
- Check nested files and Git history before importing a project.
- Preserve copyright and license notices. Ask before importing material whose license or publication permission is unclear.
- Treat .gitignore as a convenience, not protection for already tracked files.
## Collaboration
Be specific, respectful, and practical in reviews. Discuss the work, give reproduction steps, and explain trade-offs. Keep speculative features separate from verified behavior. A maintainer reviews and merges changes; opening a PR does not publish a release.
+43 -2
View File
@@ -1,3 +1,44 @@
# stash # Stash
Playground for testing and ideas. A public playground for small experiments, useful tools, and ideas worth keeping. Maintained by [Joe Amditis](https://git.inference.coop/jamditis) on the Inference Cooperative's Gitea.
Stash gives unfinished ideas room to become useful. Each experiment should explain what it does, how to try it, and what remains uncertain. This repository starts with the project scaffolding; no applications or hosted demos are included yet.
## Start here
- Browse the [experiment index](docs/experiments.md).
- Read the [contribution guide](CONTRIBUTING.md) before adding something.
- Use [issues](https://git.inference.coop/jamditis/stash/issues) for ideas and reproducible problems.
- Submit changes through a [pull request](https://git.inference.coop/jamditis/stash/pulls).
## Get a local copy
```sh
git clone https://git.inference.coop/jamditis/stash.git
cd stash
git switch -c experiment/your-idea
```
There is no repository-wide install or build step. Each future experiment should document its own dependencies and commands. Browser sign-in does not configure terminal Git authentication.
## Keep experiments self-contained
Use a short, descriptive directory name under experiments/ when adding a project. Include a README with its purpose, status, setup, usage, checks, limitations, and sources or license notices. Add an entry to the experiment index so people can find it. Keep dependencies and generated output scoped to that project.
Suggested statuses: idea, prototype, usable, or archived. Label examples and mock data clearly. A successful demo is not evidence of production readiness.
## Working together
Small, focused changes are easier to review. Describe what changed and why, include screenshots for visual work, and record the checks you actually ran. Draft pull requests are welcome for unfinished work. See [CONTRIBUTING.md](CONTRIBUTING.md) for the checklist.
## Public by design
Everything committed here is public. Use synthetic or explicitly approved public data. Keep credentials, personal archives, private correspondence, and internal work files out of commits and issues. The ignore rules are a convenience, not a security boundary. Review the staged diff before pushing.
## Checks and automation
This starter has no runtime dependencies and no automated CI configured. Issue and pull-request templates help document verification. Add CI alongside a real experiment once its commands and the co-op's runner availability are confirmed.
## License
Original contributions to this repository use [Apache-2.0](LICENSE). Retain notices and applicable licenses for any third-party material; do not assume this license covers imported content.
+31
View File
@@ -0,0 +1,31 @@
# Experiment name
Replace this template with concrete details before publishing an experiment.
## Purpose
What question does this explore or what problem does it solve? Who is it for?
## Status
Idea / prototype / usable / archived. State the main limitation and what works today.
## Try it
List prerequisites and exact dependency, setup, and run commands. Include synthetic sample input and expected output. Explain how to stop it and remove any temporary data. If there is no executable code, say how to inspect or use the artifact.
## Checks
Record reproducible checks and actual results. Separate automated tests, manual checks, and checks not yet run. For visual work, document relevant screen sizes and accessibility checks.
## Data and privacy
Explain where sample data comes from and whether anything leaves the local machine. Never include credentials or private records. Document configuration using placeholder values only.
## Limitations and next steps
List known gaps and the smallest useful next step. Avoid implying production readiness.
## Sources and license
Credit reused code, data, images, and other material with source links and applicable licenses. Retain required notices.
+18
View File
@@ -0,0 +1,18 @@
# Experiment index
No experiments have been published in this repository yet. This index tracks actual project directories rather than planned features.
When adding a project, include a relative link, a one-sentence purpose, status, and a quick way to run it. Start with [the experiment README template](experiment-template.md).
## Status guide
- **Idea:** a written question or proposal; no working implementation claimed.
- **Prototype:** something runs, with known limitations.
- **Usable:** documented setup and checks support its stated purpose.
- **Archived:** retained for reference; active maintenance is not implied.
## Entry format
`[Project name](../experiments/project-name/README.md) — What it does. Status: prototype. Try it: see its README.`
Replace the example path with a real project before adding an entry.