Skip to main content

Contact

Slight Future is a one-person operation, and the inbox reflects that — messages are read by the same person who writes the guides, runs the packet captures, and maintains the server configuration. That means response times are honest rather than instant, but it also means your message lands in front of someone who actually understands the technical context.

The best way to reach the editor is by email at hello@slightfuture.com. Plain text is preferred. If you are referencing a specific page, including the URL in your message saves a round trip.

What kinds of messages are welcome​

Corrections and errata​

This is the most valuable category. Technical writing ages, platforms change, and sometimes a command that worked perfectly when a page was written now produces different output or fails entirely. If you spot an error — a wrong flag, a deprecated configuration directive, a behaviour change in a recent distribution release — sending a correction directly improves the site for everyone who reads that page next.

Be as specific as you can. "The iptables rule in the Debian DNS guide does not work on bookworm" is immediately actionable. "Something seems wrong" requires a longer conversation. Both are still welcome, but specificity accelerates fixes.

Corrections do not need to be limited to factual errors. If an explanation is confusing, a step is ambiguous, or the order of instructions leads to a problem that the page does not mention, that feedback is equally useful. The goal is for every guide to actually work when someone follows it, and that standard is hard to maintain without readers pointing out the gaps.

Suggestions and improvements​

If you have dealt with a topic that the site covers and you know of a better approach, a useful edge case, or an important caveat that the current page misses, that input is welcome. The best suggestions tend to come from people who ran into the same problem the page addresses but encountered it in a slightly different environment or at a later software version.

There is no formal contribution process. Just describe what you think should change and why. If the suggestion makes the page more accurate or more useful, it gets incorporated. Credit is given when appropriate, though many people prefer to stay anonymous and that is completely fine.

Topic requests​

The site covers what comes up in real work, and sometimes the best signal for what to write next is someone explaining the problem they just spent three hours on and could not find a decent reference for. If you have a topic that fits the site's scope — browser internals, Linux administration, WSL oddities, web server configuration, privacy tooling, security analysis, or similar — and you think it deserves a proper writeup, describe what you are looking for and why existing references fell short.

Not every topic request turns into a page. Some fall outside the site's scope, some require access to hardware or software that is not available, and some are better served by existing documentation elsewhere. But every request is read and considered, and many of the pages on the site exist because someone asked a good question.

General feedback​

If you find the site useful, or if you think a whole section misses the mark, or if you have thoughts on how the material is organised, that feedback matters too. Running an independent publication means there is no product team doing user research — reader feedback is the primary signal for what is working and what is not.

What is not a good fit​

Slight Future does not accept guest posts, sponsored content, or link placement requests. Those emails are deleted without reply. The editorial independence of the site is non-negotiable, and there is no price at which that changes.

Requests for SEO partnerships, reciprocal linking arrangements, or "collaboration opportunities" that are thinly disguised marketing pitches also fall into this category. The inbox sees a lot of these, and none of them have ever resulted in a productive conversation.

The site does not provide consulting, technical support, or one-on-one troubleshooting. The pages are written to be self-contained references. If a guide does not answer your question, a correction or suggestion for improving the guide is more useful to everyone than a private support thread.

Response expectations​

Emails are typically read within a few days. Responses take longer — sometimes a few days, sometimes a couple of weeks, depending on whether the message requires testing, investigation, or just finding the right time to write a thoughtful reply.

Corrections that affect the accuracy of a live page get prioritised. If you report that a command in a how-to guide produces an error on a current distribution, that gets attention quickly because someone else is probably hitting the same problem right now.

Topic requests and general feedback are read and noted but may not receive an individual reply if the acknowledgement would just be "thanks, noted." The absence of a reply does not mean the message was ignored — it means the best response is a better page rather than a polite email.

If you send something time-sensitive, say so in the subject line. There is no SLA, but flagging urgency helps with triage.

Privacy of correspondence​

Messages sent to hello@slightfuture.com are treated as private correspondence. Content from reader emails is never published, quoted, or shared without explicit permission. If a correction leads to a page update, the changelog may note that a reader reported the issue, but no identifying information is included unless the sender specifically asks for credit.

The full privacy policy covers how the site handles data more broadly.

No social media​

There are no official social media accounts for Slight Future. No Twitter, no Mastodon, no LinkedIn, no YouTube channel. This is intentional. The site's content lives on the site, in a format that is searchable, linkable, and not subject to algorithmic distribution or platform moderation.

If you see an account claiming to represent Slight Future on a social platform, it is not affiliated with the site.

A note on tone​

Emails do not need to be formal. Technical accuracy matters more than politeness rituals. A terse correction with the right details is more welcome than a lengthy preamble followed by vague feedback. Write however comes naturally — the goal is to make the site better, not to maintain epistolary conventions.

That said, messages that are abusive, threatening, or obviously automated get discarded. The bar for engagement is low. The bar for harassment is also low, in the other direction.