Skip to content

Latest commit

 

History

History
321 lines (315 loc) · 18.4 KB

templates.md

File metadata and controls

321 lines (315 loc) · 18.4 KB
Raw
  • Dev docs #.h
  • Community
  • The Roam Team
    • Contact
    • Choice
    • Daily agenda Updated
      • Daily agenda
        • {{kanban}}
          • All day
          • 00:00
          • 01:00
          • 02:00
          • 03:00
          • 04:00
          • 05:00
          • 06:00
          • 07:00
          • 08:00
          • 09:00
          • 10:00
          • 11:00
          • 12:00
          • 13:00
          • 14:00
          • 15:00
          • 16:00
          • 17:00
          • 18:00
          • 19:00
          • 20:00
          • 21:00
          • 22:00
          • 23:00
          • Need to plan
    • An Engineering Problem Solving Process
      • ^^An engineered, systematic approach to problem solving can be invaluable in solving problems, capturing knowledge, and discovering solutions.^^ An approach that I suggest involves starting with a simple outline consisting of the following sections (as appropriate - sometimes it makes sense to combine or eliminate certain sections). Feel free to delete this paragraph as you fill out the template.
      • Problem Statement: This should be a simple 1-2 sentence (no more!) statement of the problem. Do not describe symptoms. To the best of your ability, reduce the problem to its bare essence here. Over time this statement may be refined. A key principle is that ^^if you cannot state your problem concisely, you probably don't know what it is and you almost certainly cannot communicate it effectively to others^^.
      • Description: Here you provide a detailed description of the problem.
        • Describe why you want to solve this problem (if you do) and what, if anything, makes this problem particularly hard. This can be particularly valuable if you are considering writing new code. Sometimes after further evaluation you will realize it is better to use an alternative or take no action at present.
        • Sometimes it is worth capturing the ideas but saving the solution for another time.
      • Given: List all things that have been provided to you, including facts, stories, etc.
      • Required: State all of the requirements to be met to provide a solution to the problem.
        • Functional/User (Required): These are the things that a user must be able to do to solve the problem. They may be stated as user stories such as "As a user, I can do X so that Y." If you do not state who can do what and why, then the requirement is suspect.
        • Nonfunctional/Technical: Technical requirements often revolve around criteria such as scaling, cost, operations, etc. I often recommend a different page for technical requirements as it is easy for problem solvers (especially developers) to move towards a technical solution (a form) prior to actually understanding the problem to be solved (the function).1
      • Knowns: State all the things you know about the problem. Provide links, references, citations, etc. as needed to trace the lineage of each known item.
      • Unknowns: What don't you know about the problem. Here you will try to anticipate the questions that you need to answer to better understand the problem.
        • Alternative presentations of knowns and unknowns could include a Johari Window2 or a "Rumsfeld-esque"3 categorization.

        • {{table}}

            - Known to Self
      - Not Known to Self
          • Known to Others
            • Arena
              • Blind Spot
          • Not Known to Others
            • Facade
              • Unknown
      • Assumptions: What do you believe to be true regarding this problem?
      • Alternatives: What alternatives already exist to this problem? What do you do now to solve the problem? What happens if you do nothing? If this is a technical solution, can an existing solution be used?
      • Solution: Based on all of the previous information, provide the solution to the problem. This could be a technical solution, process, new product, etc. Note that if multiple solutions are provided (suppose you provide multiple product offerings to solve the same problem) it is perfectly appropriate to have subpages for each solution.
      • Recommendations: An alternative to (or something to be used in conjunction with) a solution is one or more recommendations. Again, if appropriate recommendations can merit their own subpages.
    • Hickey Design Process
  • Course

    • [Course name](course link) by [Author Name](<../Author Name.md>) price

      • 2-3 sentence blurb describing the course
  • Theme 
- Plugin
    - `plugin_name`
        - **[Info](<../Info.md>):**
            - Must include GIF and/or video of usage
        - **[Link](<../Link.md>):**
        - **[Getting started](<../Getting started.md>):**
            - Installation, activation and configuration 
        - **[Tutorials](<../Tutorials.md>):**
            - 
        - **[Reference](<../Reference.md>):**
        - **[Developer](<../Developer.md>):**
            - **[Twitter](<../Twitter.md>):**
            - Love this plugin? Say thanks via [Paypal]()
        - **[Code](<../Code.md>):**
- Browser Extension
    - `browser_extension_name`
        - **[Info](<../Info.md>):**
            - Must include GIF and/or video of usage
        - **[Link](<../Link.md>):**
        - **[Getting started](<../Getting started.md>):**
            - Installation, activation and configuration 
        - **[Tutorials](<../Tutorials.md>):**
            - 
        - **[Reference](<../Reference.md>):**
        - **[Developer](<../Developer.md>):**
            - **[Twitter](<../Twitter.md>):**
            - Love this plugin? Say thanks via [Paypal]()
- Coaching
    - `Course Author Name`
        - **[Info](<../Info.md>):**
        - **[Website](<../Website.md>):**
        - **[Areas of specialty](<../Areas of specialty.md>):**
        - **[Contact](<../Contact.md>):**
        - **[Price](<../Price.md>):**
- Docs #.h
    - [ ] Introduction (few bullets) and some GIFs
    - **[Roam Team Videos](<../Roam Team Videos.md>):**
        - [ ] 
    - **[Articles](<../Articles.md>):**
        - [ ] 
    - **[Community Videos](<../Community Videos.md>):**
        - [ ] 
    - **[Key Commands](<../Key Commands.md>):**
- Video/article #.h
    - [ ] [Article link]() or {{[video](<../video.md>): }}
        - **[Features mentioned](<../Features mentioned.md>):**
            - Page refs to features 

# Backlinks
## [FAQ](<FAQ.md>)
- Check out some of our template collections here: [roam/templates](<../roam/templates.md>)

## [February 10th, 2023](<February 10th, 2023.md>)
- [x] [Experiment](<../Experiment.md>) - Demo how it was possible to use the combination of [roam/render](<../roam/render.md>) and [roam/templates](<../roam/templates.md>)

- ## Conor's [Factory Template](<../Factory Template.md>) for creating Option Dropdowns based on block refences  #[roam/templates](<../roam/templates.md>)

- [RM/Component/Select](<../RM/Component/Select.md>) an item from Dropdown List [roam/templates](<../roam/templates.md>)

## [Templates](<Templates.md>)
#[roam/templates](<../roam/templates.md>)