Merge pull request #2103 from dfinity/dev-journey-patch

Update Dev Journey index and update style guide

docs/tutorials/developer-journey/index.md

@@ -11,8 +11,8 @@ The developer journey is designed to give both new and existing developers a cle
 This developer journey will focus on developing canisters and applications using Motoko. In the future, there will be additional variations of the developer journey that focus on different developer paths, such as:
 
 - Rust development.
-- ckBTC-focused development.
-- ckETH-focused development.
+- Bitcoin-focused development.
+- Ethereum-focused development.
 
 :::
 

docs/tutorials/index.mdx

@@ -12,8 +12,8 @@ This section contains Internet Computer tutorials that will guide developers to
 This developer journey will focus on developing canisters and applications using Motoko. In the future, there will be additional variations of the developer journey that focus on different developer paths, such as:
 
 - Rust development.
-- ckBTC-focused development.
-- ckETH-focused development.
+- Bitcoin-focused development.
+- Ethereum-focused development.
 
 :::
 

style-guide.md

@@ -461,49 +461,48 @@ Answer
 
 ## Difference between tutorials and guides
 
-Tutorials should be stand-alone projects that a user can follow A-Z that may build off of an example code, may use a variety of different concepts, tools, or assets, and ultimately results in a working example project.
 
-In contrast, guides should be more focused on individual concepts or workflows and then building off of those. For example, the guides for building a smart contract backend with Motoko each focus and build upon individual concepts within Motoko, such as using integers in calculator functions or querying using an actor.
+Tutorials should be either stand-alone projects that a user can follow A-Z that may build off of an example code, may use a variety of different concepts, tools, or assets, and ultimately results in a working example project, or should be a comprehensive, intentional collection or series that is meant to be followed from start to finish (such as the Developer Journey). 
+
+In contrast, guides should be more focused on individual concepts or workflows and then building off of those. Guides should not need to be followed in a specific order or be part of a series for the reader to utilize and benefit from them. For example, the guides for building a smart contract backend with Motoko each focus and build upon individual concepts within Motoko, such as using integers in calculator functions or querying using an actor.
 
 ### Writing a tutorial
 When contributing a tutorial, the following general format and structure should be used. It is important to note that the content of tutorials will vary, and this format can be expanded and elaborated on to include more detailed workflows or content.
 
+An exeption to this format is the Developer Journey tutorial series, which uses a slightly different standardized format due to the unique nature of the Developer Journey series. All other tutorials should follow this format. 
+
 ```
-# Page title
+# Page title (Title that should be displayed on the sidebar)
 
 ## Overview
 
-Text
+This section should contain an overview of what the tutorial will teach the developer. This information includes what technology features are being highlighted (HTTPS outcalls, Bitcoin integration, ledger, etc) and should explain why these features are important to the developer. This section should also provide an overview of what is being built (DEX, NFT example, etc). 
 
 ## Prerequisites
 
+This section should be used to list any prerequisites that a developer will need to follow this tutorial, assuming they have not followed any other tutorial. Common prerequisites include installing the IC SDK, installing an IDE, and installing Node.js. 
+
 - [x] Prerequisite 1.
 - [x] Prerequisite 2.
 - [x] Prerequisite 3.
 
-## Step 1: Description of step
-
-Text
-
-### Subtopic 1
+## Step 1: Description of step (This should describe what the developer will accomplish in this step. Ex: “Create a new project”, “Open the main.mo file”, “Write a function that makes an inter-canister call”, etc.)
 
-Text
+Include any context or additional information for the developer to complete this step. Typically this will include the code snippet, command to run, or other information about what the developer must do. It is also beneficial to include the ‘why’ a developer is completing this step to help further their understanding.
 
-## Step 2: Description of step
+### Subtopic 1 (Subtopics are optional. They can be used to break up tutorials that cover several different concepts, such as an HTTP outcalls tutorial that covers both GET and POST requests; subtopics can be used to break the tutorial into two parts - one for GET and one for POST.)
 
-Text
+Include any context or additional information about what the subtopic is and how it relates to the overall theme of the tutorial. 
 
-### Subtopic 2
+## Step 2: Description of step 
 
 Text
 
-## Step 3: Description of step
-
-Text
+– Repeat above format as necessary for duration of tutorial
 
 ## Conclusion
 
-Text
+Wrap up the tutorial by reiterating what the developer learned about, what they accomplished, and what they are able to do with the result of this tutorial (continue building, enhance example by adding additional features, etc.)
 
 ## Resources
 - [Link](link.example)