Contributing and Feedback
How to report issues, share feedback, and contribute improvements to AccessLayer.
AccessLayer is still moving quickly, so useful contributions are not limited to code. Good bug reports, sharp product feedback, docs fixes, connector examples, and focused pull requests all help.
Looking to contribute code?
For the full contributor workflow, repository conventions, and current contribution path, use the repository contributing guide.
Ways to contribute
Feedback
Product feedback is useful when it is concrete.
- Say what you were trying to do.
- Explain what felt confusing, slow, or missing.
- Include the workflow you expected instead.
- Add screenshots or example prompts if they help.
Bug reports
Good bug reports reduce back-and-forth.
- Include expected behavior and actual behavior.
- Provide clear repro steps.
- Include connector names, routes, prompts, or queries where relevant.
- Attach logs, stack traces, screenshots, or failing payloads.
Code changes
Code contributions work best when they stay focused.
- Keep changes scoped to one problem.
- Prefer incremental fixes over unrelated cleanup.
- Call out behavior changes and tradeoffs in the PR description.
- Run the relevant checks before asking for review.
Docs
Docs contributions are always useful.
- Fix wording that makes people pause.
- Add missing examples and edge cases.
- Improve troubleshooting and setup instructions.
- Keep docs aligned with actual repo structure and scripts.
Share your work
Not every useful contribution needs to look like a bug report or a pull request.
We also welcome:
- dashboards built with AccessLayer
- useful queries or prompt patterns
- blog posts, tutorials, or walkthroughs about how you use AccessLayer
- examples that show how AccessLayer fits into real team workflows
If you have something worth sharing, feel free to reach out. We are happy to help with questions, polish up examples, or point you in the right direction for anything AccessLayer-related.
Share prompts and rough fixes
If you have already used AI to explore a fix, that is still useful even if you do not want to open a full pull request.
Issues can include prompts, drafts, and partial fixes
If you have a prompt that reproduces the issue, explains the fix clearly, or gets most of the way to a working change, feel free to open an issue with that material. It is often faster for us to take over the remaining work than wait for a fully polished PR.
Useful things to include:
- the prompt you used
- the model output or patch it generated
- what you think is correct or still missing
- any context about why the change matters
That is especially helpful when the remaining work is mostly repo-specific cleanup such as tests, validation, or packaging the change for review.
Request a new connector
If the source you need is not supported yet, open a connector request instead of trying to force it into a generic feedback thread.
Use the connector request page
For missing integrations, go to Request a Connector. That page covers the information that helps evaluate new connector work quickly.
FAQ
Yes, if the change affects behavior, architecture, or multiple workspaces. Align on the problem first so the implementation work is not wasted.
Repro steps, expected behavior, actual behavior, and concrete evidence such as logs, screenshots, prompts, connector names, or failing queries.
A narrow scope, a clear explanation of the behavior change, and verification notes that show the patch was actually exercised.
Yes. Docs fixes, examples, troubleshooting improvements, and wording cleanup are all useful contributions.
Where to send feedback
Open an issue or pull request in the AccessLayer repository, and include enough context for someone else to understand the problem without guessing.