Resolve "Update issue templates"

.gitlab/issue_templates/Bug.md

-<!---
-Please read this!
-
-Before opening a new issue, make sure to search for keywords in the issues.
-
-and verify the issue you're about to submit isn't a duplicate.
---->
+<!-- After you create the issue, add a link to the operations issue which triggered this bug. Also add links to any related issues. -->
 
 ### Summary
 
-(Summarize the bug encountered concisely)
+<!-- Concise summary of the bug encountered. -->
 
 ### Steps to reproduce
 
-(How one can reproduce the issue - this is very important)
+<!-- How to reproduce the issue. -->
 
-### What is the current *bug* behavior?
+### What is the current *bug* behaviour?
 
-(What actually happens)
+<!-- What actually happens. -->
 
-### What is the expected *correct* behavior?
+### What is the expected *correct* behaviour?
 
-(What you should see instead)
+<!-- What you should see instead. -->
 
 ### Relevant logs and/or screenshots
 
-(Paste any relevant logs - please use code blocks (```) to format console output,
-logs, and code as it's tough to read otherwise.)
+<!-- Paste any relevant logs. Use code blocks (```) to format console output, logs and code. -->
 
-### Possible fixes
+### Possible causes
 
-(If you can, link to the line of code that might be responsible for the problem)
+<!-- If you have a theory about the possible cause of the bug, include it here. -->
 
 /label ~bug

.gitlab/issue_templates/Feature.md

-### Problem to solve
-
-<!-- What problem do we solve? -->
+<!-- After you create the issue, add a link to the operations issue which triggered this feature request, if applicable. -->
 
-### Intended users
+### Problem to solve
 
-<!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer, Operations), or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. -->
+<!-- What problem do we need to solve? Include use cases, benefits, and/or goals. -->
 
-### Further details
+### Stakeholders
 
-<!-- Include use cases, benefits, and/or goals -->
+<!-- Who will use or benefit from this feature? -->
 
 ### Proposal
 

.gitlab/issue_templates/Release.md

+* See [Tagging a new CTA release](https://eoscta.docs.cern.ch/cta/tag_cta/)
+
+<!-- To obtain the commit id, first update the Release Notes with the version number of the next release and commit to master. -->
+
 ### Initial code references for release
 
-This release should be based on <commit_id> from branch <branch_name>.
+This release should be based on `<commit_id>` from branch `master`.
+
+This release will be tagged as version `vX.Y.Z-R`.
+
+### Additional details
+
+<!-- Should this release be used in production straight away? Normally, NO, it should be deployed and tested on PPS first. -->
 
-### Useful precisions for the announcement channel
+<!-- Does this release require a schema upgrade? (Specify the schema version). -->
 
-Should this Release be used in production strraight away?
- - NO
+<!-- Add additional notes for deployment of this version, *e.g.* if new tables need to be populated. -->
 
-<!-- Just in case this version is part of a specific longer term development/testing effort: tagged on a specific branch to fix urgent production bug, on a parallel branch like drive status in DB or in objectstore... -->
+<!-- Add additional notes if this version is part of a longer-term development/testing effort, *e.g.* tagged on a specific branch to fix an urgent production bug -->
 
 ### Stress test results
 
-<!-- Usual stress test screenshot for the commit_ID referenced higher if everythign goes well for the stress test it stops here otherwise iterations continue in comments --> 
+<!-- Add stress test screenshots for the commit_id referenced above. If everything goes well for the stress test, create the Deployment ticket in the Operations repo. Otherwise, iterate in the comments to solve any problems. -->
 
 /label ~release