We use Gitlab issue queues to organise our work as a community:
- It helps co-ordinate releases, i.e. to decide what will make its way into the upcoming release, and what will be assigned to a future version of CiviCRM;
- It is a focal point for all issues so people can collaborate on identifying them, fixing them, and testing the fix once implemented.
- Anyone in the community can use it suggest improvements and report bugs;
The core team play a co-ordinating role, and work on many of the issues. Many members of our community also work on resolving issues (and may also help with co-ordination). If you have an issue in the queue that you need fixed as soon as possible, consider providing the resources to fix it by submitting it to our paid issue queue.
Before submitting a feature request to the issue queue, make sure you have discussed your ideas with the core team or others in the community and there is agreement about how it will be implemented and who will fund it. We recommend you do by posting on CiviCRM's Stack Exchange in the form of a question ("how can I ...?") or by asking on the Mattermost community chat.
Before reporting a bug to the issue queue, please ensure you understand the bug reporting process and have verified that it is indeed a bug. We typically need clear steps to reproduce any bug before we can start work on it but you can find full details on how to report a bug here, or how to report a suspected security issue here. If you need help with bug reporting, please ask on Mattermost.
Prioritizing Issues
In an ideal world we would have the resources to implement all the improvements and fix all the bug reports we receive on the issue queue (all the sensible ones, anyway). In reality, we do not have the resources to do this and so have to triage issues. Triaging ensures we have the maximum impact with limited resources and it is based on the following :
- What is the severity of the issue? Major security issues and bugs that result in data loss (which are fortunately very rare) are always treated as highest priority by the core team and fixes are released as soon as possible, in accordance with our security policy. After these issues, we consider the impact the issue will have on those sites that it affects
- How many people are affected? We place a higher priority on bugs that affect many people and improvements that will benefit a lot of people. Issues pertaining to parts of the system that are not commonly used will be given a lower priority than parts that are used day to day by the majority of our users.
- Has the issue reporter also attached code that can be used to resolve the issue? (and what is the quality of the code?) The more work that has been done already, the more likely it is that the issue will be resolved in the next version.
- Is this good for everyone? Resolving this issue may make CiviCRM better for you, but could have unintended consequences for other users. If the issue adds a feature that is useful for 5% of our community but complicates a process a currently very simple for the rest of our users, we may decide not to resolve the issue in core. Functionality like this is probably best added as an extension.
Taking into account all of the above, we decide on one of the following:
- Schedule the issue for the next revision of CiviCRM (e.g. if the current release is 5.0.3, the issue will be resolved in 5.0.4). Scheduling the issue is a statement of intent. It does not guaruntee that the issue will be fixed in the next revision and a minority of issues are typically 'bumped' to the following release. If you want to ensure an issue will be fixed in an upcoming revision, you should use our paid issue queue or provide the resources to fix the issue yourself.
- Schedule the issue for the next minor version of CiviCRM (e.g. if the current release is 5.0.3, the issue will be resolved in 5.1.0). Again, although we do our best to resolve as many issues as possible for each release, we do not guaruntee that this issue will be resolved in the next minor version. You can guaruntee this happens by paying for the issue to be resolved or providing the resources to fix the issue yourself.
- Assign the issue to a future version. We do this when we recognise that the issue is valid but do not envisage having the resources to work on it until we have completed all the more pressing issues. Given that issues are continually being reported, an issue can stay in future version indefinitley. But never fear, you can 'jump the line' and get the issue fixed now via the paid issue queue.
- Close the issue. This may happen if the issue duplicates another issue, or if it’s already fixed in a different version, or if the information is too incomplete, or if the design/assumptions are inappropriate. We always give a full explanation as to why we have closed the issue and depending on the reason, you may want to improve the issue based on the feedback you were given so that it can be re-opened.
If the triage could not be completed for any reason we will request more information from the reporter before proceeding with one of the above courses of action.
Paid Issues
If you want an issue fixed faster than we are able to fix it in our standard issue queue, one option is to submit it to our paid issue queue. Essentially this enables you to move up the pririty queue by providing the (finanical) resources to fix the issue yourself.By doing so, you are helping to fund improvements to CiviCRM that keeping it free to download and used by our entire community.
