reading to change workflow - yasufumi-nakata/mind-upload GitHub Wiki
See everything from observation, proposal, execution, and isolation of external dependencies in one straight line
This learning page is generated for GitHub Wiki. The public portal is managed on mind-upload.com.
- Updated: 2026-03-14 / Role: Reading to change workflow
This page is a workflow guide for connecting the insights gained from reading Mind-Upload pages to actual changes and organization. When you find a new paper, notice a theoretical weakness, see the shape of a proposal, know a fix that can be fixed right away, or know that an external dependency is required, it will guide you in a straight line to which page to go back to and what to make.
What is shown here is a workflow arrangement. To check the validity of individual proposals and papers, be sure to go back to the original page text and rationale.
- Wiki: Differences between facts, hypotheses, proposals, and execution tasks - This is for people who want to sort out the differences in roles between pages first.
- Wiki: 5 paths to follow after participation/collaboration page - This is for people who want to decide on the next page after the participation page.
- Wiki: Basics of deciding where to put new information - For those who want a more detailed look at where to put it.
- If you decide which artifact to turn what you read into, information will be less scattered.
- The page to return to is different for literature organization, theory organization, proposal, execution task, and external dependence.
- Even when it comes to external dependencies, there are quite a few preparations that can be made in-house first.
- Which realization will lead to the greatest results will depend on the unresolved problems and implementation status at the time.
- The extent to which the discussion of external dependence progresses to concrete cooperation depends on the other party and the conditions.
On this site, we do not leave behind what we read and understand. First, decide whether it is an attempt to organize the literature, a theoretical weakness, a suggestion, a fix that can be removed immediately, or an external dependency, and then decide where to return.
| What I noticed after reading | Back to | What to make there |
|---|---|---|
| I found a new paper or evidence | Research Harvest / Papers | Connections to unsolved problems, evidence examples, wide archiving. |
| I found weaknesses in the theory and differences in assumptions | Perspective / Idea | Review of limits, theoretical framework, and design principles. |
| I could see the direction and policy to move forward | Proposals | Suggestions, stream organization, evidence links. |
| I can now see changes that can be fixed in this repository | Issue | Execution task, advance condition, refutation condition, modification position. |
| I realized that external collaboration and systems were necessary | Collaborations | External dependent tasks, in-house preparations, minimum deliverables. |
| Things to distinguish | How to judge |
|---|---|
| Literature organization or proposal | If you want to organize ``what has been learned,'' you should organize the literature, and if you want to show ``how to proceed,'' you should make a proposal. |
| Suggestion or Issue | If it's a change that can be fixed in this repository right now, it's an issue, and if it's still in the planning stage, it's a suggestion. |
| Issue or Collaborations | If you need a partner, an IRB, equipment, or a contract, call Collaborations, and if you can do without them, call Issues. |
| Public page or wiki | If you want to show the main points and what is known/unknown, use the public page, and if you want to learn from the basics, use the wiki. |
| Scene | Back to | Reason |
|---|---|---|
| I found a new EEG paper | Research Harvest | If you don't first sort out which U will be effective, it will tend to be scattered among proposals and issues. |
| After reading Perspective, I was concerned about the weaknesses of the theory | Perspective / Idea | It is better to leave it as a theoretical arrangement first, so that the premises of the proposal and implementation are less likely to deviate. |
| After reading the Proposals, I saw a deficiency that could be fixed immediately | Issue | This is the stage from organizing proposals to specific revisions and completion conditions. |
| When I tried to write an issue, there were too many external dependencies | Collaborations | This is because internal changes and external dependencies need to be separated. |
- Turn interesting literature into a proposal as it is: It is safer to return to unresolved issues and arranging issues first.
- Write the immediate fixes on the suggestion page: It is better to separate the execution task into an issue so that it can have completion conditions.
- Mixing external dependencies with issues: It is easy to get stuck if you do not separate internal changes and waiting for the other party.
- Add all background information to the public page: It is better to post detailed explanations from the beginning to the wiki to maintain the entry point.
If you want to go back to the differences in the roles of pages, go back to Differences between facts, hypotheses, proposals, and execution tasks, go back to deciding where to put it Basics of deciding where to put new information, go back to the next page path for participation Five paths to follow after participation/collaboration page.