formatting.

Author: csyonghe

community/become-a-committer.md

@@ -11,42 +11,42 @@ High-Impact Contributions: Aim to contribute changes that significantly benefit
 ## Engage in Code Reviews
 In open-source projects, reviewing others’ code is as important as submitting your own. Before becoming a committer, you should:
 
-*Participate in Code Reviews:* Actively participate in code reviews by providing insightful feedback. Look for issues in logic, style, performance, and alignment with Slang’s objectives.
+**Participate in Code Reviews:** Actively participate in code reviews by providing insightful feedback. Look for issues in logic, style, performance, and alignment with Slang’s objectives.
 
-*Help Raise the Code Quality:* Encourage adherence to Slang’s standards and practices by providing constructive feedback. The ability to review others’ code with a critical yet supportive approach is essential for committers.
+**Help Raise the Code Quality:** Encourage adherence to Slang’s standards and practices by providing constructive feedback. The ability to review others’ code with a critical yet supportive approach is essential for committers.
 
 ## Build Trust and Collaboration
 Committer status is granted based on the trust that you are deeply committed to Slang’s success. You can demonstrate this by:
 
-*Being Reliable and Responsive:* Maintain a regular and responsive presence in the project, whether in pull requests, discussions, or reviews.
+**Being Reliable and Responsive:** Maintain a regular and responsive presence in the project, whether in pull requests, discussions, or reviews.
 
-*Work Well with Others:* Slang is a community effort, so committers are expected to work well with other contributors, listen to feedback, and adapt where needed.
+**Work Well with Others:** Slang is a community effort, so committers are expected to work well with other contributors, listen to feedback, and adapt where needed.
 
-*Take Ownership of Work:* Show a sense of responsibility by following up on contributions and addressing issues that arise in areas of the code you’ve worked on.
+**Take Ownership of Work:** Show a sense of responsibility by following up on contributions and addressing issues that arise in areas of the code you’ve worked on.
 
 ## Demonstrate Technical Understanding of Slang
 To maintain and develop the Slang codebase, committers need a comprehensive understanding of its internals. Demonstrate that you:
 
-*Understand Slang’s Architecture:* Learn and follow Slang’s core architecture, coding patterns, and design principles.
+**Understand Slang’s Architecture:** Learn and follow Slang’s core architecture, coding patterns, and design principles.
 
-*Know the Shading Language and Compiler Space:* Familiarize yourself with shading languages and compilers in general. This domain knowledge helps you contribute effectively and make informed decisions as a committer.
+**Know the Shading Language and Compiler Space:** Familiarize yourself with shading languages and compilers in general. This domain knowledge helps you contribute effectively and make informed decisions as a committer.
 
 ## Maintain a Record of High-Quality Contributions
 Consistent quality and dedication are key criteria. Committers typically have:
 
-*A History of Reviewed Contributions:* Have at least 10 high-quality patches merged, with a record of thorough and constructive review feedback.
+**A History of Reviewed Contributions:** Have at least 10 high-quality patches merged, with a record of thorough and constructive review feedback.
 
-*Positive Reviewer Feedback:* Accumulate reviews from existing committers that acknowledge your contribution quality and readiness.
+**Positive Reviewer Feedback:** Accumulate reviews from existing committers that acknowledge your contribution quality and readiness.
 
 ## The Committer Nomination Process
 
 Once you meet the criteria above, you can nominate yourself to become a committer. This process includes:
 
-*Nomination:* You can ask a committer to nominate you to become a committer via our discord channel.
+**Nomination:** You can ask a committer to nominate you to become a committer via our discord channel.
 
-*Internal Review:* Existing committers will review your contributions, code review feedback, and responsiveness to determine your readiness.
+**Internal Review:** Existing committers will review your contributions, code review feedback, and responsiveness to determine your readiness.
 
-*Final Approval:* Upon a positive consensus, you will be granted committer status along with write access to the Slang repository.
+**Final Approval:** Upon a positive consensus, you will be granted committer status along with write access to the Slang repository.
 
 Becoming a committer is a meaningful responsibility, and we value contributors who are invested in maintaining and advancing Slang. Thank you for your continued contributions, and we look forward to welcoming you as a committer!
 

community/code-quality.md

@@ -13,27 +13,27 @@ Many graphics applications are having issues with long shader compilation times.
 
 ## Testing
 
-*Unit and Integration Tests:* Include tests for all new features and bug fixes. Each pull request should add or update tests that validate the new functionality or fix. Pull requests should not break any existing tests.
+**Unit and Integration Tests:** Include tests for all new features and bug fixes. Each pull request should add or update tests that validate the new functionality or fix. Pull requests should not break any existing tests.
 
-*Reproducibility:* Ensure that any reported bug fixes or features work consistently across different environments supported by Slang.
+**Reproducibility:** Ensure that any reported bug fixes or features work consistently across different environments supported by Slang.
 
-*Maintain Test Coverage:* Maintain or improve existing test coverage. Avoid reducing the coverage or introducing untested paths in the code.
+**Maintain Test Coverage:** Maintain or improve existing test coverage. Avoid reducing the coverage or introducing untested paths in the code.
 
 ## Code Readability
 
-*Readable and Self-Explanatory:* Code should be easy to read and self-explanatory, even without comments. Avoid overly complex or nested structures; prioritize clarity over conciseness.
+**Readable and Self-Explanatory:** Code should be easy to read and self-explanatory, even without comments. Avoid overly complex or nested structures; prioritize clarity over conciseness.
 
-*Function and Variable Naming:* Use descriptive names for variables, functions, and classes. Names should make the code’s purpose immediately clear.
+**Function and Variable Naming:** Use descriptive names for variables, functions, and classes. Names should make the code’s purpose immediately clear.
 
-*Comments:* Use comments to document the purpose of new types and functions you introduce. For functions that implement complex logic, comments should focus on why the logic is needed, and not just a rephrase of what the code is doing.
+**Comments:** Use comments to document the purpose of new types and functions you introduce. For functions that implement complex logic, comments should focus on why the logic is needed, and not just a rephrase of what the code is doing.
 
-*Small, Focused Commits:* Keep each commit focused on a single change or issue. This helps reviewers understand the intent of the change and makes it easier to trace history later.
+**Small, Focused Commits:** Keep each commit focused on a single change or issue. This helps reviewers understand the intent of the change and makes it easier to trace history later.
 
 ## Code Review Process
 
-*Follow Review Feedback:* Be prepared to make changes based on feedback from committers. We aim for constructive reviews that ensure quality without stalling progress.
+**Follow Review Feedback:** Be prepared to make changes based on feedback from committers. We aim for constructive reviews that ensure quality without stalling progress.
 
-*Documentation and Clarity:* Provide a clear and detailed pull request description. Include context, goals, and any specific details reviewers should know to understand your contribution.
+**Documentation and Clarity:** Provide a clear and detailed pull request description. Include context, goals, and any specific details reviewers should know to understand your contribution.
 
 ## Community and Collaboration
 Be Respectful and Collaborative: Open-source projects are collaborative efforts. Communicate clearly, and respect feedback and the time of maintainers and reviewers.