gitlab-roadmap.md

@@ -123,19 +123,58 @@ but also:
 
 ## How one would search to find if an encountered problem was a known issue, an issue being addressed, etc.?
 
+> "It would really help if a non-developer, non Github user could get some sense of how to use the proposed repository and, specifically, how one would search to find if an encountered problem was a known issue, an issue being addressed, etc." (@dtarrant)
+
 The proposed Gitlab structure would be to have project spaces around components/themes of CiviCRM (financial, cloud-native, translation, reports, etc, but there would still be a "core" project).
 
 This would aim to create somewhat more manageable spaces where teams can prioritise within those spaces). We can also search across projects in Gitlab.
 
 It might also be necessary to also search the pull-request queue on Github, in case someone directly opened a pull-request.
 
+## TODO: Splitting issues across projects might be confusing? Triage?
+
+> "We cannot expect our users to have to understand the internal workings of CiviCRM in order to choose where they need to file their bug report." (@cividesk/Nicolas)
+
+> "Note that if easy to move issues around projects in GitLab, we might resolve end-user reporting of issues through an external, non-authenticated form collecting basic info on the issue (and reporter), which would then create an issue in the 'triage' project in GitLab. The issue would then be triaged and moved to the appropriate development project by technical contributors." (@cividesk/Nicolas)
+>
+> "Is there any type of structure proposed for entering issues? Key words, categories, etc. A form?" (@dtarrant)
+
+> "The ability to apply multiple labels/tags, to indicate which components an issue relates to, provides a more flexible classification system than having to create an issue in one of a number of projects." (@davej)
+
+## Document the account creation, permissions, workflow
+
+> "Can a non existing user easily create an account and (issue) report?" (@xavier)
+
+Anyone can create a civicrm.org account, but currently the accounts are still manually moderated (because of spam). It usually takes 24-48h to have an account validated. People can also ping on Mattermost (which is not connected to civicrm.org authentication).
+
+> "given the short timeframe to Jira issue creation being closed, is there a 'howto' for how / where to raise issues on gitlab for the uninitiated / non-dev / client minded" (Martin from Circle)
+
+Currently there isn't a guide for reporting issues on JIRA (?), but it would be nice to have one for Gitlab. It's clear that, even for experienced developers, we need a clear guide on how to create a new issue.
+
+> "Who can add labels/assign/add milestone?" (@xavier)
+
+Milestones should be added only when the PR is merged. It's impossible to know when issues will be merged, because we release monthly.
+
 ## What about the 2000 open issues in JIRA that are not confirmed?
 
-We would encourage more triage before making JIRA read-only. CiviCRM does occasionally purge issues that have not had activity in 18 months. Batch-closed issues can then be re-opened by people watching them (who will receive an email notification) and still interested on working on the issue.
+> "Perhaps some clearer communication as to why those issues are not being migrated and some guidance or a notice posted in JIRA should be provided." (Justin-Agileware)
+
+> "I do like the idea of not migrating everything - my wishlist would be for a 'migrate this issue'button" (@eileen)
+
+CiviCRM does occasionally purge issues that have not had activity in 18 months. Batch-closed issues can then be re-opened by people watching them (who will receive an email notification) and still interested on working on the issue.
+
+Therefore we would encourage:
+
+* More triage of unconfirmed issues before making JIRA read-only, to either close or confirm as many issues as possible.
+* A few weeks before JIRA is set as read-only (including for existing issues), issues will be batch-closed, so that the authors and watchers on those issues receive a notification that their issue has been closed. They can then go in JIRA and request that the issue be re-opened. This might need some tweaking technically, but the short version is that people will receive a reminder to go and update their issue.
+
+To be clear, we do hope to migrate more than the current 39 confirmed issues. The fact that there are only 39 confirmed open issues (out of 2000) shows that more triage needs to be done.
 
 ## What about Stack Exchange?
 
-Stack Exchange is the front-line of support. Sometimes the answer is "this is a bug, therefore it needs to be tracked in an issue". As with Gitlab, we will discourage people from opening support requests in Gitlab.
+(related to points raised by @dtarrant)
+
+Stack Exchange is the front-line of support. Sometimes the answer is "this is a bug, therefore it needs to be tracked in an issue". As with JIRA, we will discourage people from opening support requests in Gitlab.
 
 ## Won't the separate issue trackers confuse users? what about overlap?
 
@@ -162,11 +201,3 @@ This needs more testing!
 Gitlab has a per-issue privacy flag, but we would have to ensure that all issues created have that flag. Otherwise, it might be simpler to make the project fully private.
 
 In any case, this needs more testing.
\ No newline at end of file
-
-## TODO: Document the account creation, permissions, workflow
-
-* Can a non existing user easily create an account and (issue) report?
-  * Anyone can create a civicrm.org account, but currently the accounts are still manually moderated (because of spam). It usually takes 24-48h to have an account validated. People can also ping on Mattermost (which is not connected to civicrm.org authentication).
-  * Currently there isn't a guide for reporting issues on JIRA (?), but it would be nice to have one for Gitlab.
-* Who can add labels/assign/add milestone?
-  * Milestones should be added only when the PR is merged. It's impossible to know when issues will be merged, because we release monthly.
\ No newline at end of file