gitlab-roadmap.md

@@ -26,7 +26,23 @@ See also:
 
 # JIRA Deprecation Roadmap
 
-See: #817
+See: #817 
+
+
+# Feature requests & specs
+
+Since December 2017, new projects have been created under the Development Team group in Gitlab:
+
+* https://lab.civicrm.org/development-team/features-requests (generic)
+* https://lab.civicrm.org/development-team/cloud-native (topical)
+* https://lab.civicrm.org/development-team/civireport-improvements (should be renamed to just "civireport"?)
+* https://lab.civicrm.org/development-team/membership
+* https://lab.civicrm.org/development-team/Release-Management (moved from Github)
+  * Ex: [CiviCRM 5.x checklist](https://lab.civicrm.org/development-team/Release-Management/issues/1)
+
+These groups can help move forward discussions from the dev mailing-list, transforming ideas into tangible steps forward. They also help bridge the gap between Stack Exchange and Pull-Requests (which used to previously be either on the [old forum](https://forum.civicrm.org) or on JIRA).
+
+Further discussion is slowly going towards a consensus that instead of having one monolithic issue tracker, we could track issues directly in the dev-team sub-projects. Feature requests can be moved from one project to another, and it makes it easier to track priorities/roadmaps per component. We can also share Gitlab labels between projects (ex: for critical/blocker issues). While this could be done in JIRA, it required complicated dashboards. Very few people were comfortable using them. Gitlab makes discovery easier.
 
 # Extensions
 
@@ -42,23 +58,11 @@ Possible use of Gitlab for Extensions:
 
 # Translation
 
-todo
+* Currently people sometimes open issues on Transifex, where they are mostly ignored.
+* Could be an issue tracker equivalent to other projects in the dev-team group (for patches & support).
+* Space for wiki docs.
 
 # Security
 
-todo
-
-# Feature requests & specs
+* Security issues can be handled in a private Gitlab project (currently issues are in non-public JIRA issues).
+* Possibility usable for security-related pull-requests (which Gitlab calls merge-requests), but could require changes to the continuous-integration.
\ No newline at end of file
-
-Since December 2017, new projects have been created under the Development Team group in Gitlab:
-
-* https://lab.civicrm.org/development-team/features-requests (generic)
-* https://lab.civicrm.org/development-team/cloud-native (topical)
-* https://lab.civicrm.org/development-team/civireport-improvements (should be renamed to just "civireport"?)
-* https://lab.civicrm.org/development-team/membership
-* https://lab.civicrm.org/development-team/Release-Management (moved from Github)
-  * Ex: [CiviCRM 5.x checklist](https://lab.civicrm.org/development-team/Release-Management/issues/1)
-
-These groups can help move forward discussions from the dev mailing-list, transforming ideas into tangible steps forward. They also help bridge the gap between Stack Exchange and Pull-Requests (which used to previously be either on the [old forum](https://forum.civicrm.org) or on JIRA).
-
-Further discussion is slowly going towards a consensus that instead of having one monolithic issue tracker, we could track issues directly in the dev-team sub-projects. Feature requests can be moved from one project to another, and it makes it easier to track priorities/roadmaps per component. We can also share Gitlab labels between projects (ex: for critical/blocker issues). While this could be done in JIRA, it required complicated dashboards. Very few people were comfortable using them. Gitlab makes discovery easier.
\ No newline at end of file