Contact
Two ways in, and one thing to keep out of the first.
Anything about the software belongs in the public tracker, where the answer helps the next person who hits it. Anything you would not want indexed belongs in email. A security report is always the second one.
Where to send what
-
A bug, a feature request, or a question about how it works
The issue tracker on GitHub. It is public, which is the point: a question asked there is answered once and stays answered. Bugs, missing features, unclear documentation and "is this supposed to do that" all belong here.
-
A security problem
Please do not open a public issue. Filing a vulnerability in a public tracker publishes it to everyone running Lyraflow before there is anything for them to upgrade to. Email it instead, with
securityin the subject line, and include the version and enough detail to reproduce it.There is no bug bounty and no formal disclosure timetable — one person reads that inbox, and inventing a service-level promise here would be the kind of claim this site tries not to make. You will get a reply.
-
Anything else
The same address. Licensing questions, whether Lyraflow fits what you are building, consulting, press, or anything that names your company and should not be in a public thread.
It is also the address in the project's code of conduct.
What to expect
Lyraflow is built by one person. A reply usually takes a few days, and the tracker is faster than email for anything about the software because it is the place the work actually happens. There is no support rota behind either channel, and this page is not going to imply one.
Before you write: the documentation is the complete product surface, every screen in it ends with what that screen does not do yet, and every limit has a number attached. A good number of questions are answered on Operations or Getting started.
Contributing code
Code contributions need a signed CLA, and it is not in force yet — the text is drafted and the check is committed, but both are switched off until it has had a legal review. Asking anyone to sign a document that says it is a draft would be worse than asking nothing. Until then, open an issue to discuss a change rather than sending a pull request. Documentation fixes, bug reports and issues need no agreement at all.
Or just hear when something ships
What shipped, what changed, and what is still missing. Only when there is a release — which, at this stage, is not often.
One address, kept for release notes and nothing else. Unsubscribe from any of them.