This Software Development Knowledge Repository is a centralized and organized collection of information on various software development topics. It's designed to be a valuable resource for developers, both experienced and beginners, as well as anyone interested in the field.

• Topics Coverage: The repository covers a wide range of software development topics, including programming languages, frameworks, design patterns, best practices, Architecture, and more.

• Markdown and Obsidian: Markdown is used for creating the documentation in this knowledge repository due to its simplicity and universality as a plain text format. The primary tool for managing and editing these notes is Obsidian, a powerful knowledge management app. With Obsidian, you can create notes using customizable Markdown templates, establish connections between related notes, and build a dynamic web of knowledge.

• Mindmaps: One of the benefits of using Obsidian is the ability to create mind maps to connect related concepts and topics. Mind maps can help users navigate through the repository and understand the relationships between different subjects.

I encourage contributions from the community. Here are some best practices for maintaining and growing the repository:

• Updating Existing Notes: Contributors can update existing notes to keep them current by adding yourself as a author you can use github username and update the "EditDate" property if making changes to existing notes.

• Creating New Notes: When creating new notes, use Markdown templates to maintain consistency in formatting specifically [[_Regular Note]]template. Obsidian can help with this using custom templates by pressing alt n. You can create your own templates to suit specific note types or add templates that you found effective.

• Sharing Personal Experience: I also believe in the value of personal experiences. Contributors are encouraged to share their real-world experiences in companies and teams. These stories can provide valuable insights, lessons learned, and tips for navigating the industry.

• Draft Pull Requests (PRs): If you decide to fork an initial project for your repository, consider using draft PRs for contributions. This allows contributors to collaborate on changes before merging them. It's a good practice for maintaining transparency and ensuring that everyone is on the same page.

• ToDo: There are notes in this vault that have todo check list the ones that include personal are my personal todos. While the ones without personal are open for anyone to address also more of these todos will be added throughout the vault for existing and future notes or if there is a note added by someone you can add todo as well.

When submitting a request to merge, please direct it towards the Peer Review Branch.

1. Final: These notes represent the pinnacle of quality within your system. They are detailed, grammatically sound, and structurally solid. Each one is enriched with relevant backlinks and tags, ensuring seamless integration into the larger knowledge vault. While they are considered complete, there is always a possibility for minor improvements, such as updating tags to reflect evolving topics or expanding the vault. Crucially, notes at this stage have either undergone peer review or are marked for it, confirming their accuracy and thoroughness. Notes with a "peer reviewed" property value of 1 have completed this process.

2. Done: Notes classified as Done are robust in content and structure, yet still have potential for greater integration within the vault. This could involve adding additional backlinks to establish stronger connections with related notes or incorporating new tags to enhance findability and categorization. Although these notes do not require significant modifications to their core content, the process of enriching their network within the vault can increase their overall utility. Like Final notes, those in the Done category should also undergo peer review, marked by a "peer reviewed" property value of 1 once reviewed.

3. Refinement: This category is for notes in the midst of active development if your interested in learning more about a topic for these types of notes then add your self as a author and make a PR so one person is working on a document at a time. They may be in the process of being restructured, having content added, or both. The emphasis for these notes is on enhancing their integration within the vault through the addition of backlinks, broadening their tagging for improved navigation and organization, and evaluating their potential to be split into separate notes or combined with existing ones. Peer review at this stage is crucial to ensure that these notes evolve in line with the vault's standards for quality and coherence. Notes are marked with a "peer reviewed" property value of 0 initially, indicating pending review.

4. Draft: Representing the initial creative burst, Draft status notes are raw and foundational. They provide a basic structure for ideas and information that will be further developed and refined. At this stage, notes are not typically subjected to peer review, as they are still too nascent in their development. These notes have a "peer reviewed" property value of 0, reflecting their early stage in the note development process.

This systematic approach ensures a dynamic and structured progression for each note, from conception through to finalization, enhancing the overall richness and connectivity of the knowledge vault.

By maintaining this public repository and following best practices, we aim to:

• Share knowledge and best practices.
• Create a community of knowledge sharing.
• Help newcomers and experienced developers alike.
• Foster collaboration and growth in the software development field.

With a well-organized repository, Markdown templates (including custom and found templates), the power of Obsidian, the inclusion of personal experiences, and draft PRs, we can create a dynamic and evolving resource for the software development community.

Feel free to customize this template further to align with your specific goals for the software development knowledge repository.

This repository includes a collection of Markdown files covering various subjects, along with my personalized Obsidian setup, inclusive of plugins and custom configurations.

Feel free to establish your Obsidian repository for managing personal notes.

When you deem your contributions valuable and ready for integration into this main repository, fork it and append the specific note. This method avoids including your individual Obsidian settings and plugins, which may differ from those in this repository. This streamlined approach expedites the pull request process and merging procedure. It also allows you to maintain your unique Obsidian setup if desired. Otherwise, only new documentation or plugin and Obsidian config changes will be merged based on the nature of the alteration.

When managing intricate documentation in Enterprise-level companies, using tools like Confluence or others, it's crucial to highlight the rationale behind document creation or employ effective naming conventions. In step-by-step guides, especially for tasks like project setup or environment configuration, documentation should clearly distinguish between optional and mandatory steps. This practice minimizes redundancy and ensures users grasp the purpose of each procedure, understanding the flexibility or indispensability of specific steps. However, the challenge persists in motivating individuals to read thoroughly, especially when confronted with multiple similar documents that may lack comprehensive insights into their origins and significance.

**Follow these steps to contribute to a project:

1. Fork the original repository to your GitHub account.
2. Clone your fork to your local machine using Git.
3. Create a new branch to work on your changes.
4. Make your desired changes, commit them to your branch, and push the branch to your fork on GitHub.
5. Visit the original repository and click on the "New Pull Request" button.
6. Select your branch as the source for the pull request and provide a clear explanation of your changes.
7. The repository owner of the original project will review your pull request and decide whether to merge it into their repository.

• Beginner Guide to Obsidian
• Obsidian Playlist
• https://help.obsidian.md/Home