People actively dislike confluence. (And it's something that's stuck in my craw - how do we build documentation that's easy to organize? That's my quarantine project. :)
The solution we had was to give one Space for each team/department in the company: one space for Customer Support, one for Engineering, Data Scientists, Business Analysts and Operations/Management. Each team lead was responsible in ensuring that other teams from the company could find the information needed, but aside from that we let each team organize itself.
The only hard rule was the one I stated above, everything else came somewhat organically. Managers and Business Analysts, for instance, still preferred to work in Word/Excel, so their pages was mostly just placeholders for Office Docs and attachments. This was fine by me, as long as they could always respond quickly with the right file/link if someone else in the team asked for something.
This is the single biggest tip I would give any company who uses Confluence. For some reason, most companies I work for that use Confluence insist on using minimal separation of Spaces. I.e. IT in general has a Space, and my team has a folder nested 6 folders deep in some path that I can never remember and have to bookmark.
It makes search effectively useless. If I search for "X api documentation" I get 10,000 results ranging from meeting minutes that some unrelated team put up that just happen to use those terms, to pages from other teams documenting how they use the API.
A Space should be treated the same as a Jira project. If I had my way, I would create a Space every time we created a Jira project.
And my biggest request for the Confluence team would be better markdown support (I should be able to indicate that I want to type Markdown without having to click through a giant list), and a way to set up a space to sync from Markdown files stored in Git. Some of us don't want to use the WYSIWYG editor, and I would love to be able to use an MR review process for documentation changes before they go live.
So one day Jeff Bezos issued a mandate. He's doing
that all the time, of course, and people scramble like
ants being pounded with a rubber mallet whenever it
happens. But on one occasion -- back around 2002 I
think, plus or minus a year -- he issued a mandate that
was so out there, so huge and eye-bulgingly ponderous,
that it made all of his other mandates look like
unsolicited peer bonuses.
His Big Mandate went something along these lines:
All teams will henceforth expose their data and
functionality through service interfaces.
Teams must communicate with each other through these
interfaces.
There will be no other form of interprocess
communication allowed: no direct linking, no direct
reads of another team's data store, no shared-memory
model, no back-doors whatsoever. The only communication
allowed is via service interface calls over the
network.
It doesn't matter what technology they use. HTTP,
Corba, Pubsub, custom protocols -- doesn't matter.
Bezos doesn't care.
All service interfaces, without exception, must be
designed from the ground up to be externalizable.
That is to say, the team must plan and design to be
able to expose the interface to developers in the
outside world. No exceptions.
Anyone who doesn't do this will be fired.
Thank you; have a nice day!
I'm trying to do that work now. It's not even that I don't think it can be done in confluence or wikis in general, but rather we don't have a great methodology in organizing it.
I'm keeping a list of what I find at https://www.ebiester.com/annotated-links/documentation/2020/... but I'm not seeing what I really want just yet.
Too much structure, and people will wait until they have all of the details needed to start contributing, or they will not contribute unless it's "their job". Too much flexibility and they don't know where to start.
I found that it was always better to let documentation and knowledge sharing follow the same principles as code: let it come bottom-up, see what patterns emerge and only worry about structure when the current practices hit a bottleneck. But then again I never worked on any project that I had hundreds of people directly depending on the documentation, so it might not work as a strategy for larger-scale organizations.
Your knowledge system keeping in sync with your version control is also a major plus, this is the primary reason why I don't like tools like Confluence, because it's easy for them to get out of sync with the actual system, and this can require too much coordination.
I don't follow. How much do you have of your non-techies updating your knowledge base and how do they get to know if what they are updating is "in sync" with the system if the changes are making are orthogonal with the functionality?
It seems your case is mostly about documentation of the technical product, specs, requirements. Yeah, this can go to your version control, and I would bet that you could find a Confluence plugin that would generate the documentation from version control and sync with the rest of your Confluence pages if you wanted.
But I really, really doubt your method can scale beyond the IT side of any middle-to-large organization. The moment you ask Business/Customer Support people to actually go look at anything like Gitlab/Github's interface is the moment you lose 90% percent of buy-in from both non-techies and management at any company that is not absolutely dominated by Software Engineers.
Requiring integration with version control is a convenience for engineers, but it is so far from the tooling from those that live on Excel sheets that you might as well ask them to never touch the documentation side.
The interface is not so much what I object to it. It is the fact that you mentioned "being in sync with the system", which I assume you mean "being in sync with the codebase/released code".
There are plenty of things that happen on any company that have no relation to the code, and you are telling me that you have people on the non-tech side which are expected to understand on what branch of the repo their contributation with documentation is supposed to go? Are their milestones and projects always dependent on the codebase? This is the part that makes no sense to me.
> So we do strongly believe this is scalable, at least for our use case.
I am not telling you that what you are doing is wrong, but scalable it is not. Beware the usage of the Royal We when you say "our use case": are you speaking on behalf on the whole company or just the tech team? This is key difference that you will learn as the organization grows.
Some more details about our approach that addresses your concerns: (1) for content changes unrelated to code, anyone (tech or non-tech) is able to open a new MR, and after approval it automatically gets merged into our reference branch and deployed (2) for content changes related to new (unreleased) code, the input from non-tech people (e.g. customer support) is usually requested via an already existing merge request (via a mention), they can then add their input/content via gitlab's interface straight into the markdown files (and see a live preview), this way we ensure this sort of content goes live along with the code and requires no extra coordination
> I am not telling you that what you are doing is wrong, but scalable it is not.
I hope with my clarification above it makes more sense.
> when you say "our use case": are you speaking on behalf on the whole company or just the tech team?
On behalf of the whole company: we have a single product/platform that is continuously increasing in complexity, and it really helps to have a single process in order to maintain a knowledge base that covers as many aspects as possible (tech and non-tech). We believe this approach will also minimize replication of content across departments (facilitates cross-linking), and we're intending to also create an aggregated search (next to the individual search) across all categories of our knowledge base (product/engineering/support/sales/..), in order to more easily retrieve relevant content.
> Beware the usage of the Royal We when you say "our use case"
I am not implying this is set in stone, we (as a whole team) thought long about this flow, and for now it seems to work great, and I hope (responsible for maintaining this technically) that it scales up to some point far enough in the future. I'd say we were mostly inspired by Gitlab, they seem to adopt a similar approach, and that seems to be scaling quite okay over there :). We've noticed ourselves that the general "documentation mindset" has definitely grown among the team because of this specific process and the ease of adding content, updating content and retrieving content.
As for Gitlab, their work processes are interesting, but I assume that most of the non-technical work there goes to issue tracker and the wiki? I am failing to see where there a strong connection to the code repository is required there.
Futureperfect: can those convos be mediated via a wiki?
While using Confluence, I tried to keep track of activities. Like when another team updates an API I'm using. Manually. IIRC, I could watch pages. But I couldn't follow individuals, topics, teams, etc.
In the wiki page proper? Theoretically, yes, but it would involve a lot of discipline from everyone in your team.
One thing that worked for our team (i.e, our Confluence Space) was to keep all pages with a "comments" page at the end. Any comment that came up on that page was basically meant an "issue" to be resolved in the documentation: clarify a point, update another, link to a related page with more details, etc. Once the person that created the comment was satisfied, we treated the issued as resolved and deleted the comment without prejudice.
I now recall that C2 wiki has convention of comments. They're immortal. It sucks.
FWIW, I've been advocating everything (everything) gets a TTL. Like renewable leases. Culling is such a huge problem, burden. As others have commented (in the org-mode thread), upkeep becomes onerous. It may be cheaper just to rediscover stuff that's gone stale.
--
There are different types of convos, interactions, transactions with their own use cases that all need to be implemented specifically.
All of the purpose built focused tools I've seen, per that cliche, eventually add an email feature.
And I can't think of a hybrid solution. Maybe bug trackers.
I hope someone someday cracks this problem.
One big change that I got with my team to do successfully in a company was to change the attitude regarding communication and documentation on Slack.
It involved one single, simple rule: whenever you want to ask anything you need to do your work on Slack, phrase it a way that relates to the Wiki/Knowledge Base.
In our case it was Confluence. So, instead of getting questions on channels such as "How do I do X?", we would ask "Can someone point me to the Confluence page that explains how to do X?". Instead of asking someone to send a file or spreadsheet with data that I needed, I would ask them to revise and update the Confluence page, and so on. That would apply even for meetings that were held. If someone missed a meeting and wanted a re-cap, it was easy to point to the page with the minutes of the meeting, and so on.
In the beginning we did have to prod and nag some of the colleagues so they would drop old habits, but after a couple of weeks when the majority understood that Wikis are meant to be editable freely it was working really well. There were no longer huge threads on Slack and there was no more stress about missing anything that happened on Slack. It did help (a lot) that we had the support from upper management in implementing this, as they were the ones worried the most about losing communication scattered in a million threads and channels.