this repo has no description
📚 Update Company Knowledge Management and Documentation
+6
-5
+1
-1
Company Knowledge Management.md
+1
-1
Company Knowledge Management.md
···
39
39
- [[Documentation]] should have a common entry point to increase discovery. Each team can have it's own [[processes]] on top.
40
40
- At a company level, each team documents differently. To make the most of that, grow the knowledge organically and locally, not top down. Each team should have its own permissionless and open way of working and should be made public to the rest of the company. That way they can evolve the system to fit their needs. Then, there is a standard protocol to share information between teams.
41
41
- The protocol serves as the team communications API. An abstraction over the inner works of the team that is common to all the other teams.
42
-
- E.g: Each team having a homepage README with links to their slack, ticket system and processes.
42
+
- E.g: Each team having a homepage [README](https://tom.preston-werner.com/2010/08/23/readme-driven-development) with links to their slack, ticket system and processes.
43
43
- Since the protocol is shared between apps, you can build different views on top of the knowledge and tasks via APIs.
44
44
- Add as much information to your tickets/issues as possible. If the tickets/issues are any good, you'll find relevant tickets with links and extra information. That makes easy to tell what is current vs. what is 3 years old. The approach is something like Kafka (a log of everything that happened) versus a database with the current state of the world.
45
45
- [Every document you write can fall into one of two categories](https://clrcrl.com/2021/11/30/fighting-the-entropy-of-knowledge.html):
+5
-4
Documentation.md
+5
-4
Documentation.md
···
26
26
1. Who am I writing this for?
27
27
2. What are the top 1-3 takeaways after someone's read?
28
28
- [Write simply](https://zodvik.com/posts/on-writing-well/):
29
-
- Use fewer than 30 words per sentence
30
-
- Use ordinary words and simple sentences
31
-
- Remove fluff
29
+
- Use fewer than 30 words per sentence.
30
+
- Use ordinary words and simple sentences.
31
+
- Remove fluff.
32
32
- Remove weasel words. Replace adjectives with data or details.
33
33
- Ask the "So what" question to every sentence that you write.
34
34
- Prefer active voice to passive.
···
45
45
46
46
- [Building a README](https://readme.so/).
47
47
- [How to Write a Great README](https://www.appsmith.com/blog/write-a-great-readme).
48
-
- [Template](https://www.makeareadme.com/)
48
+
- [Template](https://www.makeareadme.com/).
49
+
- [Readme Driven Development](https://tom.preston-werner.com/2010/08/23/readme-driven-development).
49
50
- [Starship](https://github.com/starship/starship).
50
51
- [Alacritty](https://github.com/alacritty/alacritty).