... | ... | @@ -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
|
|
|
|
|
|
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 |
|
|
* 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 |