Even if the “claims” appear to be the same, their roles are not the same
Literature organizing, theoretical notes, design principles, technical proposals, issues, and collaboration candidates are not all of the same type of text. First, separating what pages are recording makes it difficult to misread the strength of the affirmation and the next action.
First, divide into 5 types
| Type | What are you doing | Main page |
|---|---|---|
| Observation/Organization | Record what is known and what is unresolved. | Research Harvest / Papers / Casework |
| Hypothesis/Theoretical Frame | I will show you how to think about it so that it can be easily applied to the design conditions. | Perspective / Idea |
| Proposal/Policy | Indicates in which direction to proceed and in which stream to organize. | Proposals |
| Run task | Now cut the changes, completion conditions, and disproof conditions that you want to make in this repository. | Issue / Hands-on |
| External dependent task | We organize work that requires external conditions, such as joint research, standardization, IRB, equipment, legal matters, etc. | Collaborations |
Differences between pages that look similar
| Page | Main role | Easy to misread |
|---|---|---|
| Perspective | A research note that tracks the supporting points and weaknesses of a theory by arranging literature and limitations. | Although it is a long article, it is not a declaration of a final theory. |
| Idea | This is a theoretical frame that narrows down the design principles and working hypotheses to be adopted. | This is a summary of the position and does not mean that it has been experimentally proven. |
| Proposals | This is an organization chart that tracks the status, stream, and rationale of a proposal. | Acceptance of a proposal does not mean code implementation or joint research. |
| Issue | This is the entry point for managing changes to be executed here and now, with completion conditions. | It will be confusing if you treat big theories and external dependencies in the same box. |
| Collaborations | This is a practical page that organizes candidates for external dependencies and necessary preparations before collaboration. | This is a candidate list, not an agreed list. |
How to move naturally
| Where you are now | Next natural destination | Reason |
|---|---|---|
| Observation/Organization | Perspective / Proposals | The next step is to organize the literature and decide how to read it and what policy to use it for. |
| Hypothesis/Theoretical Frame | Verification / Roadmap | This is because it is necessary to translate the hypothesis directly into design conditions and verification conditions. |
| Proposal/Policy | Issue / Hands-on | To translate suggestions into actual changes and minimal loops. |
| Run task | Content Hub / Verification | This is to proceed while re-checking the location and completion conditions. |
| External dependent task | In-house production and external dependencies | This is because we first need to break it down into preparations that can be made in-house. |
Common confusion
Mistake
- Reading a theoretical frame as a list of facts: Idea contains a working hypothesis.
- Reading the proposal page as implementation complete: Proposals are a summary table, not a completion report.
- Turn the issue into a big idea note: It's safer to drop the issue to a change that expires in this repository now.
- Read Collaborations as a TODO list: An organization of potential external dependencies and preparations, not a ready-to-do list.
Where to return next
If you want to go back to the role differences of the entire public page, please use Public page reading guide, if you want to go back to the status of the proposal page, please use How to read proposals and status labels, and if you want to translate it into execution tasks, please use How to write your first issue.