-
-
Notifications
You must be signed in to change notification settings - Fork 159
Where To Send Feedback
We're looking for feedback on Oils! This includes:
- The compatible OSH language.
- Does it run your shell and bash scripts?
- How can we make debugging eaiser?
- Are the error messages helpful?
- The new YSH language.
- Do you like the syntax?
- Does it work the way you expect?
- What documentation do you need that is missing?
- The interactive shell (lower priority, but still welcome)
and more. You can:
- Open an issue on Github. You can also search for existing, related issues.
- Start a new topic on
#oil-help
or#oil-discuss
on oilshell.zulipchat.com (requires login with Github or Google).- The "new topic" button is usually at the bottom of the page. For a quick overview of Zulip, see this picture and this blog post.
- Or chat with me directly. However basically anything is on topic for
#oil-discuss
. Don't be shy about asking! Many things are not documented, and your questions will help me fill that gap.
That is, if disclosing the bug would lead to real systems being hacked, use e-mail rather than Github or Zulip.
Thank you!
Examples:
-
https://github.com/oilshell/oil/issues/1864#issue-2188861648 - crash in
ctx
- https://github.com/oilshell/oil/issues/1822#issuecomment-1969880870 - bug running starship
This is valid and useful feedback -- questions are always welcome.
You may be pointed to a FAQ, but that's ok!
Please post as much real code as you can, along with:
- the output you expect
- what actually happened.
Even if you don't know exactly what you want to do, asking on #oil-help
is valid! The language is still evolving, so we like to hear what problems people have using it.
Again, posting real code helps.
The docs are still in progress, so this is unfortunately somewhat expected. Posting on #oil-help
should give you a quick answer - either a link to existing docs, or an explanation that can be copied into docs.
This is great feedback, and worth posting even if you don't need a response! I enjoy reading success stories.
It's often better to start by clearly stating the problem, and only then then the solution you have in mind. There are always multiple solutions to any given problem.
Every person has a different background, so what's "intuitive" to one person may not be inuitive to another.
See Language Design Principles for some core axioms -- e.g. YSH is for Python and JavaScript users that avoid shell.