I find it hard right now to share knowledge with everyone on the team and to turn knowledge into actual learnings.
I don't know how you guys do it, but I would love to know. We are now 50 people in the company and I don't know anymore how to make this scale. What is your process? Do you use any tool for it? How good is it? What needs improving?
Self-promo: I'm currently building software called Thanks For Sharing.
At launch, we'll be focusing on features that help employees to provide feedback to their organization leaders.
We're also exploring requirements for building out internal knowledge bases for organizations that have more sharing and communicative elements. Link in my bio if any are interested.
Would love to get in touch with you as we are developing a tool at this moment, exactly for this purpose. Target is a cross between jira and notion. your experience is valuable, and you would be granted life-free usage.
Edit: Agree with afarrell though a good tool should guide processes and be actively used also in operations for information And knowledge not to be dated.
Apart from being pretty slow, I don't think Jira really sucks once a) it is configured to your needs b) you know how to use it (which should be fairly easy with a in place). Which goes for pretty much any tool more complicated than notepad, so to speak: it's not like the other similar tools out there are much better, just different, imo. Though I have the impression a lot of people who think Jira sucks might be using it where they actually don't need it because much simpler tools could suffice in their particular situation.
All tools suck in a way that actual reality of doing work is complicated and tools are obviously way simpler so you end up trying to reduce the reality to fit the model of a particular tool.
That explains why email is still the most used tool. It also sucks but you can do any type of project with email and everyone knows how to use it.
Rwtxt.com for personal stuff. Minimalist, simple, supports markdown, exports data and can be self-hosted with no hassle (it's a go binary, and that can run anywhere, and it uses sqlite, so no complicated db setups). It works for small groups too, though it breaks when two people try to edit aat the same time.
QOwnNotes, cross platform open source app for creating/editing/tagging/searching markdown files, synced with NextCloud. I've finally found the system that doesn't hold me back, and I've stopped looking for anything better.
This is for my own personal use, maybe/probably not as suitable for a team.
I have a directory named “mystuff” that’s gitignored globally, in every repository I work on. This is where I store commands, snippets, scripts, ideas, meeting notes etc. To organize things I find on the web, I simply use bookmark folders in the browser.
In our company we use both github wiki and google drive to share knowledge.
A combination of indexed markdown documents, org-mode with orgzly (android) and devonthink (macos) as a gui
Thinking of using TiddlyWiki as gui again as it works with Firefox Reality in the Oculus Go and Quest, but it doesn't work well with markdown and org-mode documents. Perhaps use it as yet another system.
I use http://diigo.com to quickly bookmark/tag/annotate links I find. It is about the most advanced bookmark manager out there with capabilities to store copy of page/pdf with annotations, search content etc.
I've used Bookmark OS for bookmarking for a couple years and have recently started using it for notes as well. It allows for sharing folders of bookmarks and notes with teams https://bookmarkos.com
Recently I found out Balsa (https://github.com/balsa-team/balsa) - which looks promising since it has a WYSIWYG editor with comments, plus can be deployed on premises.
http://fellow.co has been immensely helpful for me , it has every thing I need to manage information at work place and also has a personal section which is useful. I would recommend you to give this a try
Personal : small library of notebooks, I generally dont share these
Professionally : physical notebooks and Onenote books. Every time I join a new team I start a new notebook and when I leave I pass it to someone else if they want it. My Onenote files are publicly accessible to anyone.
Mostly meetings and word of mouth. That's why I lose one week+ on a lab software that I cannot make run on my local development machine. Even personal projects I spend a few months on are better documented than the software that is used here in production.
I use google keep for writing notes. In work we use the enterprise garbage all others use too. Google calender for datespecific stuff. Anything coding specific i have in github as markdown documents, some remain as drafts in my blog repository.
At Sourceress we formalized skillsharing with a simple spreadsheet. Now, engineers teach each other the skills that we want to spread throughout the org.
We tried. It's pretty much like the normal stack overflow (Question and Answer based).
But we found that in the end - a normal wiki was actually more useful. I think this was mainly because of how our organization works. We're all physically on the same campus, at most a colleague is 2 minutes walking away. Hence we tend to often have in-person communication, or first via Slack, after which a colleague walks over to explain it anyway..
Using a wiki, the person knowledgeable about the domain can just create a document to refer people to which is quite natural. What is not natural for this person is to create a question and then answer it himself. (I know you could use SO as a wiki but than you're losing some of the utility anyway).
I'm not saying that it can't work, but a lot depends on company culture / structure, at least I think so. So if you're in a situation where people often post questions on slack and people respond through slack, maybe SO is a good alternative.
(Oh also, on another note, during our test people would post question on SO and no one would answer because no one is looking, or people think "someone else will answer" and don't bother to check up later. Via slack, at least it's more visible and scoped to the correct channel with the correct people for the domain).
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.
At launch, we'll be focusing on features that help employees to provide feedback to their organization leaders.
We're also exploring requirements for building out internal knowledge bases for organizations that have more sharing and communicative elements. Link in my bio if any are interested.