content placement basics - yasufumi-nakata/mind-upload GitHub Wiki
Before deciding what to write, the basics of deciding where to put it
This learning page is generated for GitHub Wiki. The public portal is managed on mind-upload.com.
- Updated: 2026-03-14 / Role: Content placement basics
This page is a supplementary material that helps you organize from the beginning where to put new information when adding it to Mind-Upload. Public pages are information portals, wikis are detailed explanations for learning, Issues are changes to be made, Collaborations are for organizing external dependencies, and operations areas are intermediate results. You can check the role differences with examples.
What is shown here is the basics of placement. Please be sure to return to the main text and basis of the original page to judge the correctness or rejection of individual claims.
- Wiki: Guide to reading public pages - This is for people who want to see the role differences between public pages first.
- Wiki: 5 paths to follow after participation/collaboration page - This is for people who want to move on to the next task after determining the location.
- Wiki: How to write your first issue - Additional information on how to write when the location becomes an issue.
- Determining the location first reduces duplication of information and dissipation of leads.
- Separating the public page and the wiki makes it easier to both make the entrance more visible and provide more detailed explanations.
- Externally dependent tasks should be managed separately from changes made here and now.
- Which issues will become independent pages in the future will change depending on the amount of content and reader demand.
- Some topics span multiple pages, so the final destination will continue to be adjusted.
If you start writing the main text immediately when you find new information, you will end up with more duplication and confusion. Decidingthe role of that information first will make it easier to add the necessary details to the wiki while keeping the public page as a portal.
| Location | What to put | Things that should not be placed |
|---|---|---|
| Public page | What we know now, what we don't know yet, where to read next, and a decision chart. | Long material that teaches background knowledge from beginning to end. |
| wiki | Basic explanations, differences between similar words, how to read pages, supplementary materials for learning. | A primary repository for the latest operational decisions and implementation status. |
| Issue | The changes to be performed in this repository now, the modification location, advance conditions, and disproof conditions. | Writing big plans that include external dependencies as if they were completed. |
| Collaborations | Talks that require partners and external conditions, such as joint research, standardization proposals, and institutional cooperation. | A record of small corrections that can be completed only here. |
| Operation area | Unorganized memos, intermediate results, CSV, machine processing results, audit logs. | Show the text as is for readers. |
| The question the information answers | Where to put it first | Reason |
|---|---|---|
| What is currently known and what remains unsolved in this field | Public pages such as Verification, Roadmap | This is because the public page plays the role of indicating the known/unknown as an entry point for judgment. |
| I want to explain terms and background knowledge from the beginning | wiki | It is better to put the learning material on the wiki so that the entrance page can be kept more readable. |
| I want to fix something that can be fixed now | Issue | This is because you can manage executable changes, including completion conditions. |
| I want to organize candidates for joint research and standardization | Collaborations | This is to avoid mixing external dependencies with in-house changes. |
| I want to keep raw data and notes that have not been organized yet | Operation area | This is to prevent fragments from being directly poured into the public text before the integration destination is determined. |
| What I found | Where to put it first | Page to view with assistance |
|---|---|---|
| Explanation for junior high school students | wiki | Content Hub / Public page reading guide |
| Conditions and notes missing from existing claims | Issue to target public page | Verification / How to write your first issue |
| New papers and datasets | Research Harvest or Datasets | A straight path back from literature to implementation and participation |
| One page summary to be handed over to joint research partner | Preparations for connecting to Collaborations | In-house production and external dependencies |
| Fragmented memo whose authenticity and location have not yet been determined | Operation area | Content Hub |
- Create a new page for now: First, check if it can be integrated into an existing page.
- Turn public pages into textbooks: It will be easier to see the entrance if you submit detailed explanations to the wiki.
- Mix Issues and Collaborations: Separate changes you can make now from external dependencies.
- Publishing unorganized notes as is: It is safer to organize them in the operational area first and then decide where to integrate them.
To return to the list of integration destinations, go to Public content integration hub, to go back to participation routes, go to Five paths to take after the participation/collaboration page, to go back to writing methods for writing issues, go to How to write your first issue Please use.