Live data from Hacker News

Ask HN: How does your team handle knowledge documentation?

news.ycombinator.com

71–80 of 93 posts

Re: Ask HN: How does your team handle knowledge documentation?

#71

Earlier quoted context omitted.

Good to know that Github wikis aren't searchable. We have a Github Enterprise installation and were considering using the wiki for our longer, detailed documentation, but lack of search is a no go I think.

You can search on Github wikis. You enter your query in the search bar to the right of the Github logo. I guess wink hasn't tried to in the past year ( https://github.com/blog/2219-search-wiki-pages ).

Wow, now that's undiscoverable. Thank you, missed that one completeley

Blog post is from August 2016 "You can now search for wiki pages from either the main search page, or within a repository."

Guess I made up my mind about that 1-3 years earlier and have used the extension ever since :) Ah well, one click less at least.

Re: Ask HN: How does your team handle knowledge documentation?

#72
Have done this role a couple of times. You need to make one person responsible for documentation and traceability, because collaborative editing in a wiki like tool without some editorial oversight and organisation leads to problems later on. The tool really doesn't matter, Confluence works well with Jira, pwiki is nice to use, even sharepoint works in a pinch. Heck, I've even used Enterprise Architect and Mindjet MindManager!

Re: Ask HN: How does your team handle knowledge documentation?

#73

I work at a large bank. Mostly people hold all relevant knowledge in their own head, and when they receive a request for information they only respond if their manager knows yours. Then, they will mostly refuse to create any type of actual document and instead request that you set up a meeting with them through Outlook. They are of course completely booked on their Outlook calendar for at least the next few weeks, an…

Having spent many years in a company with banks as clients, thank you for so clearly confirming what I have always suspected.

Re: Ask HN: How does your team handle knowledge documentation?

#74
post #64

Earlier quoted context omitted.

what is the company called you founded?

The company is called Slab (somewhat of a double reference to a thing you can write on and slab serif fonts). It is current in private beta but if you would like to take an early look please find my email in my profile and I would be happy to share with HN.

How is your solution different?

Re: Ask HN: How does your team handle knowledge documentation?

#75
post #64

Earlier quoted context omitted.

The company is called Slab (somewhat of a double reference to a thing you can write on and slab serif fonts). It is current in private beta but if you would like to take an early look please find my email in my profile and I would be happy to share with HN.

How is your solution different?

We is much simpler and easy to use and plays well with the non-Atlasssian ecosystem (as well as with JIRA). In both these regards we like to think of ourselves to Confluence as Slack is to Hipchat.

Re: Ask HN: How does your team handle knowledge documentation?

#76
For Semantic Synchrony[1], we keep our notes in Semantic Synchrony, a knowledge graph server (written in Java, using Gremlin and Neo4j) and client (Emacs). It allows for selective sharing, and you can connect your private notes to your shared notes however you like -- for instance, I've got a lot of "half-formed hypothesis" notes that I don't think are worth anybody else's time, so I keep those private. It eliminates the dead link problem, and the linearity constraints that trees (let alone flat folders or text files) impose.

It's open-source, with a lot of features, and well documented.

[1] https://github.com/synchrony/smsn/wiki

Re: Ask HN: How does your team handle knowledge documentation?

#77
Alfresco is an open source Enterprise content management software which has frontend UI called Alfresco Share. The installation is simple using their all inclusive executable which bundles the server, database, and Solr for searching any and all data. It also has this concept of business workflows which you say is a pain point for you. Each document can have workflows assigned to it at which point it has a life of it's own, passing from user to user, emailing itself, tagging itself, etc. There is a learning curve on the dev side, especially if you aren't Java savvy, but once you get the hang of it it's very powerful. I've personally written an API in Lua for syncing documents. I assign bot accounts from the Share UI which are given permission to crawl and sync directories to bot accounts on the server (origin server or external server), and each bot has a job to do on each document it gets, for which it writes and dispatches a service with systemd, then uploads the processed documents back to alfresco. And this is probably 1% of what Alfresco is actually capable of (and my implemention reeks of hackiness, because I hate Java). A team of devs is bound to get more use out of it.

Re: Ask HN: How does your team handle knowledge documentation?

#78

Solution: Hire a librarian. I'm not kidding in any way. They are massively underemployed and are very good at exactly this task. Back at PBwiki we hired a librarian who not only organized all the things but ended up running and building our support organization. Do not tell them what tool to use, let them own your knowledge base and make their requests for information understood to be P1 priority.

I am afraid that the idea of hiring an expert for a specialized task goes against the trend of "full-stack developers". Imagine explaining why it is not necessary for the project to have a database expert, a back-end expert, or a web expert... but you definitely need a wiki-pages-organizing expert.

The librarian is not for a single project, but the entire company. The librarian's job is to make sure that as much information as possible is stored in a manner that is searchable and accessible to all employees who need the information when they need it with minimal effort.

Re: Ask HN: How does your team handle knowledge documentation?

#79
From what I have seen creating up to date documents is considered superfluous. There are tons of excuses for why people are not updating the documents. Raising a PR for small changes is one of those excuses.

Any tool you find will have it's own version control restrictions. People will use that as a crutch to say - Well, the tool x has steps a, b, c which is too much of hassle for a minor change.

This cannot be solved by using better tools or solutions.

To give examples from my experience:

One of the places where I saw the best documentation was at a bank. Every project came with specific amount of time dedicated to updating documentation. This ensured people don't complain about not having time or the process being tedious etc.

Though as there was no time allocated for peer review of document control - It did not stop people from being lazy or creating dependencies by knowingly adding generic information in the document.

In worst of places, a software product company - documentation was looked down upon. Everyone was more than happy to "set up time to discuss" than put actual effort in good documentation. As I joined after the aforementioned bank, I had a habit of abhorring meetings and creating up to date document which was shared with the team.

The end result was that people still wanted to have meetings. On being told, I shared document with relevant info with them, they used act surprised and ask to share the document again.

Re: Ask HN: How does your team handle knowledge documentation?

#80

Solution: Hire a librarian. I'm not kidding in any way. They are massively underemployed and are very good at exactly this task. Back at PBwiki we hired a librarian who not only organized all the things but ended up running and building our support organization. Do not tell them what tool to use, let them own your knowledge base and make their requests for information understood to be P1 priority.

This is a brilliant idea.

I really never thought of actually having a person responsible for internal corporate knowledge, but it makes a lot of sense!

Post reply on HN