Org Private Structure

[dendron-bot]

Org Private Structure

• NOTE: to see the full text of this with wikilinks, see [[scratch.2021.11.18.094459.org-private-structure]]

Summary

This is divided into 3 parts

• top level nodes: these represent the different hiearchies within the dendron workspace
• common nodes: these are common nodes used in multiple hiearchies
• common sections: these are common sections used across multiple notes

The section at the end is for proposals and discussion to change the given organization.

Note that this doesn't cover contents from pkg.* or dendron site as those have been discussed elsewhere

Top Level Nodes

More info on each node provided in their own section

• area
• coe
• handbook
• investor
• leaflet
• meet
• ops
• people
• proj[ects]
• s[ervice]
• scratch
• tasks
• templates
• user
• weekly

Area

Areas are standards to be maintained over time.

Example notes:

• Community
• Growth
• Product
• Team

Common Hierarchies:

• area.{name}.sop: all sops for given area

CoE

Correction of error of lessons from operational incidents

Dendron

Catch all for everythign else

• Dendron Github Issues
• Backlog tasks
• Icebox tasks
• Crop Tasks

Common Hierarchies:

• dendron.tasks.{type}: a task

Handbook

Public facing notes about culture and processes at Dendron

Investor

Investor letters

Common Hierarchies:

• investor.journal.{month}: investor letter for the particular month

Leaflet

Internal company memos

Meet

Used for recurring meetings

• weekly planning
• office hours
• metrics review

Common Hierarchies:

• meet.{type}.{date}, eg. 16

Ops

Used to plan out releases

Common Hiearchies:

• ops.release.{early|regular}.{date}, eg. 2021 11 16

People

Customer tracking

Common Hiearchies:

• people.{name}, eg. David Mohl

Project

These are projects that the Dendron Team is undertaking. A project is a collection of tasks that take between 1 week to 1 month to complete.

Common Hiearchis:

• proj.{date}-{name}, eg. 2021 11 Org Private Reorg

Scratch

Scratch notes

Service

Services used by Dendron.

Examples Notes:

• Airtable
• Discord

Common Hiearchies:

• s.{name}.sop.{name}, eg. Creating a Survey
• s.{name}.ref, eg. s.aritable.ref

Tasks

This represents individual tasks for dendron team members

Common Hierarchies:

• task.{scope}.{date}.{name}, eg. Sample View Component

Templates

Used for global templates that don't fall udner any hiearchy

• NOTE: we were using this as a dumping ground for all templates prior so there's a lot of hiearchy specific templates in here

Weekly

Weekly planning

Common Hierarchies:

• weekly.journal.{date}, eg. 23

User

The user hierarchy covers individual tasks and planning

Common Hiearchies:

• user.{name}: user readme
• user.{name}.{date}: daily standup
• user.{name}.{date}.m.{name}: meeting/discussion

Common Nodes

Ref[erence]

Used as a catchall for information that needs to be referenced

Examples:

• Ref: airtable bases and accounts

Temp[plate]

Used for templates used in schemas. Should be put as a child of the note where the template needs to be used

Examples:

• user.kevin.temp.weekly-journal

SOP

Standard operating procedure

Primarily used in service and area

Examples:

• Weekly Release Notes

Schema

Node under a hiearchy that describes the schema for the given hiearchy

Common Sections

Summary

This is a basic description of what a note is about

Key Points

Summary of what needs to be taken away

Details

Diving into the weeds of implementation

Lookup

Additional material and links that are directly relevant for the project

Examples:

• link to code that is relevant for implementation

Related

Related notes. Not directly needed for given project but helpful to provide backlinks

Examples:

• people involved in a meeting
• a project that is blocked by the given task
• etc

Proposal

• organizing principles

  • we should try to keep top level nodes small (eg. under 20)

• immediate:

  • dendron.tasks.[backlog|icebox|crop] can be removed, we can keep them on airtable by applying the tag in the frontmatter and prioritizing there
  • dendron.metrics -> area.metrics
  • schemas be created for all listed hiearchies

• future:

  • instead of a handbook hiearchy, it makes more sense to consolidate handbook notes into area.* and just have a handbook vault that demarks public processes

[nickolay-kondratyev]

What do we think about having optional 'links' be a part of the the hieararchies, where we would make individual notes that link to specific parts of the hierarchy. It is a bit of a workaround since we can't look up the headers, but it aligns with the philosophy of everything being a quick look up away.

For example I have made some links into docs that are helpful for quick navigation.
Example ![[user.nickolay.nk.links.async-meet-google-team-drive]]

One side added benefit of these links is that it can work as the 'alias' feature as well adding one more names than the header would have, making it more likely for the information to be looked up. Totally see if we want to just wait for header lookup to come online as well.

[kevinslin]

How would this work?If I'm understanding this, this would be creating a child called links? I think this would be resolved once we can navigate to headers.

In general, I think anything that is a section within a note can also be a note in itself. The point of delineation is [[Amoeba|dendron://dendron.dendron-site/dendron.guides.workflows.amoeba]] - once a section has grown big enough, it can be its own child.

As for header navigation, maybe we can do a poor mans navigation without dynamic preview. eg. when adding a # at the end of lookup, lookup operates over headers of the topmost selection

[jonathanyeung]

Top Level Nodes

Area

I feel like area.team is going to be a bit ambiguous and become a catch-all section.

btw - it looks like all the section links within area get redirected to https://wiki.dendron.so/index.html?

Dendron

Given the proposal to eventually remove icebox/backlog/crop, what will remain here? I'm not that keen on having a catch-all section; I feel like the catch-all section should be scratch.

CoE

Feels like it should be a 2nd level node, not a top level node. I feel like it should go under 'operations'.

Leaflet

I feel like this should maybe be consolidated into whatever landing spot 'handbook' is in.

Services

Given our other pattern of using a ref hierarchy (which I've warmed up to the idea of, given how a lot of other sites organize this way), would it make sense to move this into like a ref.services section?

Common Sections

Lookup

I don't like the name of this section as much - it makes me think specifically of Dendron Lookup. I feel like this can be rolled into the 'Related' Section. (or also links, like Nickolay suggested above)

[ScriptAutomate]

I'm adding my thoughts to the discussion here, since they are mostly related to things you've mentioned :)

Catch all for everythign else

Dendron Github Issues
Backlog tasks
Icebox tasks
Crop Tasks

Common Hierarchies:

dendron.tasks.{type}: a task

An extension to your commenting on this, too: When looking at deprecating this, would all potential tasks then be scratch.* notes until conversion to task.{scope}.{date}.{name} format? Or would they all just be task.{scope}.{date}.{name} but with something of a #backlog|#icebox|#crop tagging in order to know where they are in the current categorical priority (outside of the H|M|L)?

Feels like it [CoE] should be a 2nd level node, not a top level node. I feel like it should go under 'operations'.

I agree, I think ops.coe.* would work well next to ops.release.*, or even leaflet.coe.*, unless leaflet is moved into the area top level hierarchy (area.leaflet.coe.*). If not existing somewhere within area.*, coe will be likely linking to area.*.sop.* due to potential impact on an sop under the hierarchy due to lessons learned (can backlink either way)

Given our other pattern of using a ref hierarchy (which I've warmed up to the idea of, given how a lot of other sites organize this way), would it make sense to move this [services top-level hierarchy] into like a ref.services section [instead of having ref as a common node]?

ref makes sense to me as a common node, as opposed to a top-level hierarchy, since I can see that appear in cases like *.sop.*.ref, like with the Airtable example.

I don't like the name of this section [Lookup] as much - it makes me think specifically of Dendron Lookup. I feel like this can be rolled into the 'Related' Section. (or also *.links.* as a common node, like @nickolay-kondratyev suggested)

I was thinking the same thing: either rolled into Related, or split into something like:

• Related or Links (directly related), and with notes directly in or note refs to related *.links.* common node(s)
• Further Reading (additional resources, for backlinks)

[kevinslin]

@jonathanyeung

I feel like area.team is going to be a bit ambiguous and become a catch-all section.

Right now, its mostly operations (eg. weekly releases, metrics, etc). We can split it but for now, I think its still okay.

btw - it looks like all the section links within area get redirected to https://wiki.dendron.so/index.html?

This is because the links point to our private repo and get converted to wikilinks when publishing. Since these notes aren't published, they resolve to the index. You can navigate by going to the note inside our workspace

Given the proposal to eventually remove icebox/backlog/crop, what will remain here? I'm not that keen on having a catch-all section; I feel like the catch-all section should be scratch.

Currently, there's a bunch of legacy here. We will probably deprecate it over time but its going to be a bigger undertaking. in terms of using scratch as catchall - I would push against that because scratch is meant to be a place for temporary things (aka a scratchpad). it doesn't have any inherent organization besides by time

Feels like it should be a 2nd level node, not a top level node. I feel like it should go under 'operations'.

Agreed

Leaflet. I feel like this should maybe be consolidated into whatever landing spot 'handbook' is in.

What about area.company? We can consolidate handbook.company in there as well

Given our other pattern of using a ref hierarchy (which I've warmed up to the idea of, given how a lot of other sites organize this way), would it make sense to move this into like a ref.services section?

Currently, services have the following:

• SOPs
• Quickstart
• Reference (eg. links to airtable tables)

This will probably also expand in the future (eg. troubleshoot, faq, etc)

Fine moving it as a chlid of ref if we preserve service as a distinct hierarchy with its own structure

I don't like the name of this section as much - it makes me think specifically of Dendron Lookup. I feel like this can be rolled into the 'Related' Section. (or also links, like Nickolay suggested above)

The idea is to introduce our own vocabulary - Lookup means referencing things. Just like terraform = infrastructure as code, form the association between lookup = finding relevant information.

[kevinslin]

@ScriptAutomate

An extension to your commenting on this, too: When looking at deprecating this, would all potential tasks then be scratch.* notes until conversion to task.{scope}.{date}.{name} format? Or would they all just be task.{scope}.{date}.{name} but with something of a #backlog|#icebox|#crop tagging in order to know where they are in the current categorical priority (outside of the H|M|L)?

all notes would be task.{scope}.{date}.{name}. we would use tags to keep track of them. The main interface for interacting with them would be airtable

I agree, I think ops.coe.* would work wel

+1

ref makes sense to me as a common node, as opposed to a top-level hierarchy,

I think it can be both. ref is interesting because it makes sense at every level (eg. you could have multiple levels of ref). take the below example (a bit contrived)

- ref.aws
- ref.aws.ref.accounts
- ref.aws.ref.accounts.ref.{dev,prod}

I was thinking the same thing: either rolled into Related, or split into something like:

See my response to jonathan above. open to change my mind on this

[hikchoi]

If we want to push the association of the term "lookup". What about using it in a sentence rather than just "lookup"?

e.g.)

## Summary
 
## Key Points

## Details

## Things you should Lookup

## Related

I think this distinguishes the lookup section and related section more clearly