gitlab-roadmap.md

@@ -2,19 +2,32 @@
 
 # History & context
 
-Early experiments using Gitlab ([lab.civicrm.org](https://lab.civicrm.org)) started around March 2017, as a tool to help with managing CiviCamps and the civicrm.org website, followed by the infrastructure issues, marketing, etc. The initial intention was to provide a collaboration space for areas that didn't fit in JIRA/Confluence. People often defaulted to using direct emails with many CCs/forwards, since it was hard to know who was responsible for what.
+Early experiments using Gitlab ([lab.civicrm.org](https://lab.civicrm.org)) started around March 2017, as a tool to help with managing CiviCamps and the civicrm.org website, followed by the infrastructure issues, marketing, etc. The initial intention was to provide a collaboration space for areas that didn't fit in JIRA/Confluence. People often resorted to using direct emails with many CCs/forwards, since it was hard to know who was responsible for what.
 
-We let Gitlab grow organically as a sort of beta service, collecting feedback.  In the beginning, replacing JIRA was not on the table. Gitlab seemed to be a good candidate for replacing a lot of the left-over content of Confluence (after [the migration of dev/admin documentation to mkdocs](https://wiki.civicrm.org/confluence/display/CRMDOC/Content+migration+from+wiki+to+Developer+Guide)) and tracking non-core issues.
+As an experiment, we let Gitlab grow organically as a sort of beta service, collecting feedback. Initially, replacing JIRA was not on the table. Gitlab seemed to be a good candidate for replacing a lot of the left-over content of Confluence (after [the migration of dev/admin documentation to mkdocs](https://wiki.civicrm.org/confluence/display/CRMDOC/Content+migration+from+wiki+to+Developer+Guide)) and tracking non-core issues.
 
-We are now at a point (November 2017) where we have to evaluate what to do with JIRA, whether Gitlab can help with the extensions ecosystem, and how Gitlab can help the larger CiviCRM community.
+In November 2017, we reached a point where we had to re-evaluate what to do with JIRA, whether Gitlab could help with the extensions ecosystem, and how Gitlab can help the larger CiviCRM community.
 
-# JIRA
+# What's wrong with JIRA?
 
-See:
+* We only use a fraction of the features of JIRA
+* JIRA tends to be overly complicated for what we do with it
+* It's not user-friendly, even to most developers
+* It's difficult to host & maintain
+* It's proprietary and also requires managing plugins with their own licenses
+* It's slow.
+
+As a result, JIRA tends to be used only for the issue title, brief description, "affects version" and "fix version". Most of the discussion happening on the Github pull-requests. With few people using JIRA, it has become difficult to discuss feature improvements, triage issues, prioritize by community interests.
+
+See also:
 
 * [the future of JIRA](jira-to-gitlab-migration).
 * Issue #817 
 
+# JIRA Deprecation Roadmap
+
+See: #817
+
 # Extensions
 
 *This has not been formally discussed with the Extensions WGs, brainstorm only!*
@@ -37,4 +50,15 @@ todo
 
 # Feature requests & specs
 
-todo
+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