afterburner5

tl;dr: the python library is here, if you give it a go, I'd love to hear about it

https://github.com/DragosDumitrache/koalify

Also considering that since the acquisition, they won't do anything to dissuade name-squatting anymore, despite their terms of service still suggesting otherwise

So, if you're using Jira, Confluence is the obvious choice. However, I for one think it suffers from a big issue, i.e. discoverability.

Because there's no tree-like hierarchy, it's quite difficult surfacing information unless you know exactly what you're looking for. And while some people will know what they want, I find it beneficial to make everything as visible as possible, since more eyes means it's less likely for documentation to go stale.

At work, we've currently trialled a multi doc site using MKDocs, with different topics, published into GCS buckets, and sourced from a git repo. mdbook and gitbook offer similar strategies.

Discourse is similar to stackoverflow, and has the advantage of people being able to ask questions, but it's not the best medium for documentation.

I think something light like mdbook might be the right choice to start with, it wouldn't tie you into any particular solution, as your documentation would live in markdown, but would be consumed from a nicer, more polished UI.

This, of course, assumes you're all familiar and comfortable with markdown, but I think the best solution is to try different tools, so the more portable your actual docs are, the better.

Notion is also a very good candidate, and IMO, a better choice than Confluence, but similarly, discoverability isn't great

When you're saying internal communication, do you mean, sharing informations with the wider group? Or just daily communication with your peers?

A wiki is useful for capturing historical context, and for knowledge sharing. As the one stop shop to refer to. And honestly, kudos to you for thinking about that at an early stage, most companies only start to properly consider disseminating information once many habits have been established and it's harder to train people. There are multiple tools available for this, Discourse, MKDocs, GitBook, Notion, Confluence, MDBook. Some are open source, others are not. It just kind of depends on the set of features you need.

For daily communication, most places I've been in used Slack. I've seen a few use other IM chat options, some self hosted, some not. This is less important IMO, at an early stage, as it should never serve as your main historical communication lookup. As such, you should be free to switch over with relative ease.

I worked for a company at some point where, due to the how the original product was built, testing before a release took between 3 and 5 days and was generally quite brittle.

Within my first three months there, we had business requests to improve that. Invariants, and generally speaking, contracts for our models helped us out. Because we were able to run effective, cheap, fast tests, that proved our implementations were satisfying our requirements, pre and post conditions, invariants, the whole shebang, at the contract level, without even worrying about the actual underlying implementation.

This greatly simplified the release tests, and it meant we were able to release much quicker, and with a higher confidence than before

Hey folks,

A while ago I've started working on `Honk` primarily to aid me in my day to day work. Started small, notifying of the pull requests I am interested in, then moved onto Github discussions and failed CI checks.

There are a few tools out there that do this already, but they have typically been either: - a) restricted to Github - b) outside the budget for a company that is trying to become profitable - c) generally lacked enough expressivity to highlight the cases I was interested in, or allow for any sort of generic webhook to be processed

So, the goose made an appearance. I know, it's still Github only, but all in all, it's work in progress. The aim is for this to offer a series of integrations across different services, as well as custom webhooks that developers would be interested in, perhaps from your own service as well.

I'm currently hoping to get some feedback and feature requests, so if anyone thinks they might find this helpful and would like to trial it out for a little while (currently undefined as a period, as I haven't quite implemented payments yet).

A bit more information can be found on the [about page](https://oneroar.io/about), but I am also keen to discuss this on the thread.

We're currently in the process of leveraging Github discussions for that.

I know that, but what advantage do you get from trawling through a commit sequence, over the general feature with proper documentation? If you can't understand how the overall feature was implemented, that PR generally speaking is lacking enough context to be reviewed, so why did it get merged in?

Louder, for the purists at the back!

I can see where the author's coming from. However, my approach for a PR might be a bit of a mix. Normally, I aim to make a PR be reviewable, commit by commit. However, in some cases, due to a semicolon missing (you get the point), or some instance where I'm being daft, or me bumbling in the dark trying to fix a piece of ancient, undocumented code, the history might end up being less than clean. The messages will always describe my train of thought in those scenarios, but the overall history wouldn't be cut and dry.

I tend not to worry about that and generally just squash the commits when I merge, so that, on main, there's a single commit for a particular feature. That's an overall piece of work I did. If someone wants to dig into a feature commit by commit, they can typically check the PR out and do it that way, but in practice, I've rarely seen that happen, and if it did, it was more for the overall feature rather than any one commit.

So, overall, it's not that commit messages don't matter, but rather that, while a pristine history is always nice to see, it's not always possible without unnecessary head scratching that generally just costs more dev time for very little benefit.