Contact

Contact

If a tool breaks, misses an obvious feature, or there is a practical app you want added to South Fork Apps, use one of the channels below.

  • Best for bug reports, feature requests, and new app ideas.
  • Use public channels where possible so the request has context.
  • Field Notes is the easiest way to follow what changes next.

GitHub

The public repository lives at github.com/tchastain26/south-fork-apps. That is the best place for concrete bug reports and implementation-level feedback.

Field Notes

Project updates and writing around the library live at blog.southforkapps.com.

Reporting a problem with a tool

Bug reports are genuinely welcome, and a useful one is short. Say which tool, what you did, what you expected, and what happened instead. If the tool produced a wrong result, include the input you used, because almost every calculation bug is only reproducible with the specific values that triggered it.

Mentioning your browser and whether you were on a phone or a desktop helps as well. A fair share of reports turn out to be layout or input problems that only appear on one of the two.

Suggesting a new tool

The tools that get built are the ones solving a specific, repeatable job. A request like a better calculator is hard to act on; a request to work out how much a meeting costs while it is running, or to convert a chord sheet into a different key, describes something buildable.

The library deliberately favours small single-purpose tools over large ones, so a suggestion that splits into three separate jobs will usually turn into three separate pages rather than one page with tabs.

What to expect

This is an independent project maintained alongside other work, not a staffed support desk. Reports are read and acted on as time allows, and the public channels are preferred because a request with visible context is easier to answer well and useful to anyone hitting the same problem.

Nothing here collects your personal information, so please do not include account details, passwords, or anything sensitive in a report. If a tool needs a value to reproduce a problem, a made-up example that triggers the same behaviour is always better than a real one.

Broader web presence

For the person behind the project, visit tuckerchastain.com.