Change _ to *

diff --git a/HDL_workflow/libresoc_bug_process.mdwn b/HDL_workflow/libresoc_bug_process.mdwn
index 67adca24e589402098c45bdaa0c1fd6ab349f1ec..8245867096e32427f7eb99e5161ec02ca8bbabca 100644 (file)
--- a/HDL_workflow/libresoc_bug_process.mdwn
+++ b/HDL_workflow/libresoc_bug_process.mdwn
@@ -164,7 +164,7 @@ to help determine the scope of the work involved.
 Given the scale of this project and the critical reliance on certain parts
 of it (such as devscripts, ISA csv files, ISACaller, etc.) on the work done
 by the team, it is extremely important to raise any proposed changes and/or
-improvements, and to wait for feedback _before_ implementing said changes.
+improvements, and to wait for feedback *before* implementing said changes.
 
 Going forward, we all need to keep this in mind when working on
 critical parts of the codebase.
@@ -175,15 +175,15 @@ focus on:
 1. Completing tasks under grant budget
 2. Make small, incremental changes which keep the overall codebase functional.
 3. When coming up with fixes or improvements which are intrusive to the
-   _current_ workflow (which may slow the team down from completing tasks
+   *current* workflow (which may slow the team down from completing tasks
    under grant budget), assign them to 'Future' milestone for grant
    applications going forward.
 
 Why these three points?
 
 1. Work that cannot be related to grant sub-tasks (even if indirectly, by
-   bringing us closer to eventual completion), should be put aside _until
-   future funding is secured/confirmed_.
+   bringing us closer to eventual completion), should be put aside *until
+   future funding is secured/confirmed*.
 2. Small changes make it easier and quicker to find mistakes. That's one of
    the reasons Luke has specified on [[/HDL_workflow]] to stick to small
    commits. *(Andrey: I need to improve on this myself)*
@@ -203,7 +203,7 @@ Why these three points?
 
 - If you discover a problem in code, raise a bug report, and use a
 corresponding 'importance' setting depending on how serious you perceive the
-issue to be. This will start a _discussion_.
+issue to be. This will start a *discussion*.
 
 **No work is to be started yet.**
 
@@ -238,7 +238,7 @@ an issue at all, it is to be set to either of the following:
   see the discussion before the issue disappears.
 
 - Once the issue has been discussed and determined to be critical to current
-grant sub-task/s, and budget considered, _then_ work can proceed in a separate
+grant sub-task/s, and budget considered, *then* work can proceed in a separate
 branch. Only after fixes have been confirmed to keep the CI tests passing,
 can they be rebased (to keep commit history) into the master branch.