Ask HN: How do you share/organize knowledge at work and life?

I've used Confluence with teams of hundreds, and it's ok.

It is reliable, flexible and has a pretty good search which works when you have multiple access levels. It's a bit clunky sometimes though.

I actually launched https://ulluminate.com to help with knowledge sharing. I found myself looking through my bookmarks far too often to share things with friends and coworkers. I wanted a tool where I could segment my bookmarks into private, shared, and public spaces and provide annotations as to why I thought the link was helpful. Also the ability to search a link and domain across the network of public bookmarks will be really cool for discovering like minded people and subjects.

I still have A LOT of work to do on it, but the goal is to make it really valuable for team and peer communication. I think if you use a bookmark extension to navigate your organization's structure, it should stay more up to date than a wiki (at least thats my hope).

I'm a stickler for well-written tickets.

In general: All products have a few pieces of information that must be clearly provided in a bug report (or support escalation.) For my product, (desktop file sync,) this includes build version, unedited log files, filenames, and clear steps to reproduce.

Industry-wide, a clear ticket title that is more than "XXX doesn't work," that uses known product terminology, is also important. [Edit] Also critical is that information that defines what the ticket is, such as clarifications, and updating the steps to reproduce, shouldn't be buried in comments. Edit the ticket description.

Poorly-written tickets, either because they are missing agreed-upon information, like log files, or because they just don't explain what the problem is, are sent back. I tell all my engineers to regularly look through their tickets and send anything back that's confusing; so once they are able to work on the ticket, everything they need is there.

Another critical thing: It's important that tester follow good practice for your specific product. I've had testers attach videos, but ignore log files. Videos might be very useful in a product that the tester worked on in an old job, but they very rarely are helpful when trying to diagnose why a file isn't uploading. (That's why we have logs.)

The final critical thing: Managers must respect what engineers need in tickets. This means that the testers' manager should be instructing testers in the specific items of information that they need to collect for your product. If a manger doesn't respect the fact that you need logs (or whatever else you need) present in every bug report, your problem isn't communication. It's that you have a manager who doesn't respect the needs of your business.

[Edit] Why is it important to be a stickler, and make sure that tickets are well written? When you have to look at a LOT of tickets, you don't have the time to read through 100 comments in each ticket, and then spend an hour trying to reproduce the ticket just to understand what the problem is. If you have a lot of tickets that don't make sense within the first 60 seconds that you look at the ticket, then you need to figure out how to improve ticket quality.

Another thing: Don't combine bugs into the same ticket. This happens when testers start doing things like failing verification because they found a new bug. (Does the ticket refer to the new bug or the old bug. How come, when I follow the steps to reproduce, I can't reproduce the bug?) This also happens when testers think that the same bug has multiple steps to reproduce. It's always easier to close a bug as a duplicate, than the fix one bug in a ticket and keep the ticket open for the other bug.

Love bookstack. Thanks for sharing.

I agree with this. However, the only annoying thing is it copies and pastes text as a photo. I’ve stared using outlook email drafts as a place to put rough notes. They are searchable, they sync with the cloud and copy/paste works as expected. Give that a shot if you want.