... | ... | @@ -42,7 +42,21 @@ Since December 2017, new projects have been created under the Development Team g |
|
|
|
|
|
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.
|
|
|
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 (ex: the projects listed above)
|
|
|
* We can also share Gitlab issue 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.
|
|
|
|
|
|
This structure can also help with funding feature requests. For example:
|
|
|
|
|
|
* A group of people might create a set of feature requests for improving reporting
|
|
|
* Gather feedback from the community by having upvotes on issues
|
|
|
* If there is enough positive feedback, create a "Make it Happen" (MIH) campaign
|
|
|
* Nag people who upvoted the issues, to participate in funding, implementation, testing.
|
|
|
* No need to duplicate specs in various spaces (wiki, google-doc, etc). The issues may serve as meta-issues (with items split off in sub-issues) or be used directly to track the implementation.
|
|
|
|
|
|
# Extensions
|
|
|
|
... | ... | @@ -77,6 +91,34 @@ https://lab.civicrm.org/community-team/gsoc2018/ |
|
|
* Project ideas are in markdown files in the git repository: https://lab.civicrm.org/community-team/gsoc2018/tree/master
|
|
|
* Students can apply to GSoC by opening an issue.
|
|
|
|
|
|
# Structure and tags
|
|
|
|
|
|
While we hope to keep Gitlab fairly organic and allow for some experimentation, some elements have been mentioned a lot, so they might be worth documenting up front.
|
|
|
|
|
|
## Issue labels common across all projects
|
|
|
|
|
|
* critical (important for triage, to search across projects)
|
|
|
* major (same as above)
|
|
|
* feature (feature-request)
|
|
|
* feature-postponed (closed feature request, might be re-opened later, so it might be important to track separately when we close it, since gitlab does not have a "wontfix" status)
|
|
|
* ?
|
|
|
|
|
|
## Groups and projects
|
|
|
|
|
|
Ideally the groups should somewhat reflect the Teams and Working-Group structure, but there can be some exceptions where it makes sense (better visibility, structure, etc).
|
|
|
|
|
|
* Core Team (internal to the Core Team)
|
|
|
* Community Team (ex: GSoC, webinars)
|
|
|
* Development Team (all projects related to core code)
|
|
|
* Marketing Team (ex: civicamps, website)
|
|
|
|
|
|
but also:
|
|
|
|
|
|
* Documentation (docs.civicrm.org)
|
|
|
* Extensions
|
|
|
* Infrastructure (sysadmin things for running CiviCRM.org and other tools)
|
|
|
* Security (CiviCRM security issues, kept private)
|
|
|
|
|
|
# Frequently asked questions (FAQ)
|
|
|
|
|
|
## How one would search to find if an encountered problem was a known issue, an issue being addressed, etc.?
|
... | ... | @@ -93,4 +135,14 @@ We would encourage more triage before making JIRA read-only. CiviCRM does occasi |
|
|
|
|
|
## 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. |
|
|
\ No newline at end of file |
|
|
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.
|
|
|
|
|
|
## Won't the separate issue trackers confuse users? what about overlap?
|
|
|
|
|
|
> Ex: a receipt for an event registration shows an incorrect amount. Should this be filed in the 'event', 'contribution', 'accounting' or 'civimail' project? Actually, neither because this is probably just a token issue so should be filed in the 'core' project. [ref](https://lab.civicrm.org/infrastructure/ops/issues/817#note_2799)
|
|
|
|
|
|
We should avoid being over-zealous with the number of issue trackers, and experiment when it makes sense, when it doesn't. Ideally, they should be fairly close to the current list of Mattermost channels. We need to experiment more.
|
|
|
|
|
|
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. |
|
|
\ No newline at end of file |