The first thing to decide is "location" rather than "content"
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.
First, separate the 5 storage locations
| 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. |
Decide where to place the information based on what it answers
| 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. |
How to place common cases
| 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 |
Common mistakes
Mistake
- 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.
Where to return next
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.