| ... | ... | @@ -146,3 +146,11 @@ We should avoid being over-zealous with the number of issue trackers, and experi |
|
|
|
Gitlab also allows moving issues from one tracker to another (although we should only do this during triage, because it would be confusing to code commits with references to a specific issue).
|
|
|
|
|
|
|
|
For another way of seeing it: with LeXiM, some core components are being rewritten in extensions. Sometimes a Mosaico bug might be an unrelated core bug, for example. The same applies to the above example.
|
|
|
|
|
|
|
|
On being user-friendly, this is indeed a big challenge, no matter what. Currently the [dev-team](https://lab.civicrm.org/development-team) looks like this:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Note that currently there is no "core" project (todo). Ideally, each of those projects should have a clear description. The list should not be too long.
|
|
|
|
|
|
|
|
By comparison, JIRA has a lot of very powerful but difficult to use filters. As for Github, we would also have the challenge of whether to open issues in the WordPress/Drupal/Joomla/Backdrop, 'Packages' repositories, as well as extensions. However, Github does not provide a global view of issues and does not allow moving an issue from one project to another. |
|
|
\ No newline at end of file |
