Being new as Logseq user (two days), I think I’ve got your point regarding a block as the minimum unit, and the journal as the default page. One of the first things that came to my mind after one day using Logseq was that it would be possible to create a vocabulary for my company (software developers) where all common words become pages (e.g EPIC, task, ETL, frontend, backend, etc) and merge it with my client vocabulary (medicine, research, logistics). This would allow me to create quick projects ramp-up taking requirements as journal entries.
Then during project development, ask team members to maintain an interstitial journal, keep using tags from both domains, commit their journals every day and automatically have a common project knowledge base every team member can understand.
Does this sound doable and useful?
Has someone tried to create something similar?
Each high-level expression is like a Logseq block.
High-level, meaning not written for computers, but for humans.
This includes composite expressions, up to the level of function definitions.
A composite expression is a hierarchy of Logseq blocks.
A good atomic note should be relatively easy to transform into code.
Each high-level module is like a Logseq page.
High-level, meaning not an arbitrary packaging of related functions, but a local namespace (not Logseq namespace), gathering all functions that model a well-identified concept within a knowledge domain.
A module is not a datatype, but a unique concept from the perspective of a project.
A single concept may need multiple datatypes to be fully modeled.
A concept may be a common word.
Not every common word is a module.
Not every common word deserves its own page.
Should not spam the graph with pages for every single common word.
Some common words should be fine as common blocks.
Each project is like a Logseq graph.
A project combines some modules to provide a solution within a company.
One Logseq graph per project, is the ideal separation.
Difficult in practice, because of overlapping.
A journal is a log.
Logs should be read-only (except for fixing mistakes from the perspective of the past).
Throughout a project’s life the requirements change.
In your scenario, that means that some older journal entries become outdated.
That would turn non-journal pages into a mix of valid info with outdated one.
Therefore, a journal cannot serve well as the ultimate source of truth.
It takes a knowledgeable human to decide which entries remain valid.
Non-journal pages should be carefully edited to always contain the currently valid info.
Sometimes tools are advertised as if they do everything automatically. Get to know the tool and use it for its real merits.
Anything less than decent knowledge is worse than total ignorance. :) Define "decent knowledge"
Not even close (we live in the age of misinformation), but this is off-topic.
Agree! Point me to an interesting resource and I promise not mentioning this again on this thread :)
Logseq should be:
internal to the team
unknown to the client
Agree! Though! I need some way to organize what client had transfer to me, and collaborate, usually they don't do it. Since block mindset is yet far from mainstream I was considering combine logseq with another client facing tool, more document based but better than their hierachical tools (OneDrive, Gdrive) that anyway doesn't seem to work for them
It is unrealistic to expect from the client to use your tools in an effective way.
Absolutely!
using a single form of internal jargon for both domains
the single point of reference for the team
its non-journal pages only
Journals are:
mere inputs
not effective in sharing knowledge
So you think that sharing journals among the team will lead to more confussion?
I'm planning the folllowing experiment:
use a pet project (internal no client involved)
ask the team members (tech savy) to do interstitial journaling
share their journals
append those journals adding #byPerson to each parent node.
have the aforementioned professional selecting and filtering.
share the graph with the team
take advantage of the plain md format Logseq uses to
export selected resources to a client friendly similar thing (anytype, appflowy)
translate logseq artifacts to something else (client friendly) artifacts
share the client friendly thing with other people in my company (non tech savy)
pages
list of documents
processes
other stuff
if sucessfull, then automate, else iterate
I'm planning to use the following tools
Sync: Git, Gdrive (Drive sync)
Pandocs
Links for documents instead of documents (to use GDrive access permission)
NextCloud (if a 100% opensource stack required)
PS: No intention to reinvent the wheel, any previous experiences are welcome.