Merge pull request #29 from sfuosdev/issue-29/docs-structure

changing docs structure

Author: TommyOh0428

README.md

@@ -74,4 +74,24 @@ The format will look as this:
 │   ├── readme4.md
 ```
 
+After that process, you need to add your section in <code>sidebars.ts</code> in order to display in documentation section.
+
+```ts
+tutorialSidebar: [
+  "intro",
+  {
+    type: "category",
+    label: "WSL Installation",
+    items: [
+      "tutorial-wsl/sfu-vpn",
+      "tutorial-wsl/why-wsl",
+      "tutorial-wsl/wsl-installation_Windows",
+      "tutorial-wsl/wsl-installation_macOS",
+    ],
+  },
+];
+```
+
 To contribute, please submit a Pull Request. Our executive team will review and confirm your submissions before they are published.
+
+Thank you for your contribution!

blog/2023-01-16-pm/what-is-pm.md

@@ -0,0 +1,10 @@
+---
+slug: first-post
+title: The Beginning of Documentation
+authors: [tommy]
+tags: [docusaurus]
+---
+
+<!-- truncate -->
+
+SFU Open-Source Development Club decided to utilize a documentation tool to provide valuable resources that help students who want to start learning programming and joining software projects. We will be using Docusaurus, an open-source tool made by Meta (Facebook) and will try to provide valuable tools to them. This tool will be open to everyone at Simon Fraser University. The update with our documentation will be shown in the Blog section. This idea has been suggested by Jiin Kim and deployed by Tommy Oh.

blog/2024-01-16-execs/execs.md

@@ -1,17 +1,15 @@
 ---
-slug: welcome
+slug: blog-feature
 title: Purpose of blog feature
 authors: [tommy]
 tags: [how-to-use, docusaurus]
 ---
 
 <!-- truncate -->
 
-The SFU Open Source Development Club will use the Docusaurus Blog feature to document the responsibilities and tips of project leads and club executives. The blogs can be based on personal experience or basic knowledge.
-
-With permission from the club presidents, any SFU OS Dev Club executives, ex-executives, project leads (project managers), and project members can write blog posts. Blog posts can be .md or .mdx format.
+The SFU Open Source Development Club will use the Docusaurus Blog feature to show the documentation update and may add acknowledgement of the documentation. Writing blog posts strictly only for Presidents and Director of Technology.
 
-If you are willing to write blog, please make your profiles in <code>authors.yml</code>:
+If you are writing blog, please make your profiles in <code>authors.yml</code>:
 
 ```yml
 slorber:

blog/2024-09-23-blog.md

@@ -0,0 +1,10 @@
+---
+slug: jan-update
+title: January update
+authors: [tommy]
+tags: [updates]
+---
+
+<!-- truncate -->
+
+Up until January, SFU Open-Source Development Club has updated Documentation about Windows Subsystem for Linux (WSL), Git Documentation, and Code Styling. Thank you for your contribution: [Sean Wotherspoon](https://github.com/Seanspoons), [Mehrab Uddin](https://github.com/uddinmehrab), and [Yoonsang Yoo](https://github.com/Yonny04).

blog/2025-01-16-purpose-of-blog-feature.md

@@ -1,3 +1,8 @@
+updates:
+  label: updates
+  permalink: /updates
+  description: updates tag description
+
 how-to-use:
   label: How to Use
   permalink: /how-to-use

blog/2025-01-23-update-jan.md

@@ -1,13 +1,18 @@
 ---
 sidebar_position: 3
 ---
+
 # Bad Code Style Examples
+
 These examples show how poor code style practices can lead to code that is difficult to read, maintain, and debug. Issues such as unclear naming, improper use of language features, inconsistent formatting, and poor error handling can all contribute to technical debt and reduce code quality.
+
 ## Example 1: C - Addition Function
+
 ```c
 int add(int a,int b){printf("%d",a+b); // adds two numbers}
 ```
-## Why This is Bad Code Style:
+
+### Why This is Bad Code Style:
 
 No Spaces After Commas: There are no spaces between parameters (a,int b), making the code harder to read.
 
@@ -18,11 +23,13 @@ Inline Comment Without Spacing: The comment (// adds two numbers) is directly at
 Single-Line Function Body: The entire function is written in one line, which reduces readability and makes debugging difficult.
 
 ## Example 2: Python - Improper List Sorting
+
 ```py
 def srt(lst):
     return lst.sort()
 ```
-## Why This is Bad Code Style:
+
+### Why This is Bad Code Style:
 
 Non-Descriptive Function Name: The function name srt is not descriptive, making it unclear what the function does.
 
@@ -31,20 +38,22 @@ Misuse of sort(): The function uses lst.sort(), which sorts the list in place an
 Lack of Documentation: There is no docstring or comment to explain what the function does or what parameters it takes.
 
 ## Example 3: JavaScript - Inconsistent Error Handling
+
 ```js
 function getData(url) {
-    fetch(url)
-    .then(response => {
-        if (response.status != 200) {
-            console.log('Error: ' + response.status);
-        }
-        return response.json();
+  fetch(url)
+    .then((response) => {
+      if (response.status != 200) {
+        console.log("Error: " + response.status);
+      }
+      return response.json();
     })
-    .then(data => console.log(data))
-    .catch(error => {});
+    .then((data) => console.log(data))
+    .catch((error) => {});
 }
 ```
-## Why This is Bad Code Style:
+
+### Why This is Bad Code Style:
 
 Inconsistent Error Handling: The catch block is empty, which means that errors are not properly handled or logged, making debugging difficult.
 

blog/tags.yml

@@ -3,6 +3,7 @@ sidebar_position: 2
 ---
 
 # Good Code Style Examples
+
 These examples illustrate the benefits of following good code style practices, such as using descriptive naming, proper spacing, clear documentation, and effective error handling. These practices help improve readability, maintainability, and reduce the likelihood of bugs.
 
 ## Example 1: Java - Calculator Class
@@ -22,13 +23,13 @@ public class Calculator {
 }
 ```
 
-## Why This is Good Code Style:
+### Why This is Good Code Style:
 
 Readable Function Name: The function name (addNumbers) is descriptive and follows a consistent naming convention, making it easy to understand the purpose of the function.
 
 Proper Spacing: The code uses spaces between parameters (a, b) which makes the function signature more readable.
 
-Descriptive Documentation: The comment block (/** */) provides detailed information about the function, including parameters and the return value. This helps other developers understand the code quickly.
+Descriptive Documentation: The comment block (/\*\* \*/) provides detailed information about the function, including parameters and the return value. This helps other developers understand the code quickly.
 
 ## Example 2: Python - Sorting a List
 
@@ -45,7 +46,8 @@ def sort_numbers(numbers):
     """
     return sorted(numbers)
 ```
-## Why This is Good Code Style:
+
+### Why This is Good Code Style:
 
 Descriptive Function Name: The function name sort_numbers clearly describes what the function does.
 
@@ -54,28 +56,26 @@ Docstring: The function includes a detailed docstring that describes the paramet
 Simplicity: The function body is simple and uses Python's built-in sorted() function, demonstrating a clear and efficient approach.
 
 ## Example 3: JavaScript - Fetching Data from an API
-``` js
+
+```js
 async function fetchData(url) {
-    try {
-        const response = await fetch(url);
-        if (!response.ok) {
-            throw new Error('Network response was not ok');
-        }
-        const data = await response.json();
-        console.log(data);
-    } catch (error) {
-        console.error('There has been a problem with your fetch operation:', error);
+  try {
+    const response = await fetch(url);
+    if (!response.ok) {
+      throw new Error("Network response was not ok");
     }
+    const data = await response.json();
+    console.log(data);
+  } catch (error) {
+    console.error("There has been a problem with your fetch operation:", error);
+  }
 }
 ```
-## Why This is Good Code Style:
+
+### Why This is Good Code Style:
 
 Error Handling: The use of try...catch ensures that errors during the fetch operation are properly handled, making the code more robust.
 
 Clear Function Name: The function name fetchData makes it immediately clear that the function is fetching data.
 
 Readability: Proper indentation and spacing make the code easy to follow. The use of descriptive error messages ('Network response was not ok') helps with debugging.
-
-
-
-

docs/code-styling/bad-code-styling.md

@@ -0,0 +1,9 @@
+# Executive Documentations
+
+SFU Open-Source Development is a student club at SFU aimed at bringing together talented individuals from tech, design, and business. Our primary goal is to collaborate on projects that contribute to the community while providing valuable learning opportunities for our members.
+
+This documentation will talk about general policies that executives need to follow, the description and requirements of each executive position, and good-to-have skills for executives.
+
+This is for current executives for reference but also for people who want to apply for executive positions.
+
+DO NOT EDIT this documentation section except presidents of the club.