Before creating a new report on the Issue Council, it's important to check for an existing report. Issues are often described differently by different players, so this guide aims to help you more reliably find the report you are looking for.
Quick jump links:
Functionality
- When searching from the Issue Council Dashboard, suggested issues will instantly appear in the drop down.
- This will update as you add to and modify your search phrase.
- The original post of current issues and reports will be checked against your search terms.
- Contributions and replies to issues will not be checked.
- Reports will be sorted by relevance. This includes many factors, including:
- How closely the report matches the search term(s).
- The age of the report (usually newer reports are prioritized).
- Whether it is linked to the internal CIG issue database (this is likely to override the age).
- In general, the highest ranking report that closely matches your issue should be contributed to.
- The search results page can be further filtered. We recommend filtering the Status, checking for "Open", "Confirmed" and "Under Investigation" reports when trying to add a contribution.
- It's important to note that a new report does not need to be started for each Version or Environment. It is better to update an older existing report with your contribution on a new Version, rather than creating a new report.
Operators
When entering multiple search terms into the Issue Council search form, it checks for any one of the words (also known as the "or" operator). This behavior can be enhanced or changed using the below operators.
| Name | Character | Symbol | Example | Description |
| Exact | Quotations | " | "ship" | This shows reports that specifically contain the exact term at least once. |
| Exclude | Hyphen | - | -ship | This only shows report that do not contain the term. |
| Prefix | Asterisk | * | ship* | This shows reports that have words in them that start with the term. |
| Variation | Tilde | ~ | hanger~ | This shows reports that contain terms similar to the term. |
| And | Plus | + | ship + destroy | This shows reports that contain both terms. |
| Or | Vertical Pipe | | | ship | vehicle | This is a more explicit way to ensure each term on either side of the operator is checked for. |
| Prioritize | Parenthesis | ( ) | (ship | vehicle) + destroy | Used to determine order of operations. |
Features
There are special features of the Issue Council search which will return different results than you would usually expect. These are accessed through combining specific operators with specific term types.
- Search using (partial or full) Issue Code e.g., STARC-5*.
- Search for duplicates (as determined by staff) of an issue simply by entering the Issue Code as an exact term with quotes, e.g., "STARC-1".
- Search for all issues with a particular fix version by first selecting the “Fixed” status filter then searching for the fix version (as listed on the Issue Council) as an exact term with quotes, e.g., "7536660".
- You are able to combine operators. This is most useful for creating phrases with multiple synonyms.
Example Search
As an example, we'll use the following scenario we encountered which forms the theoretical issue title:
Drake Cutlass exploded when trying to land in a hangar
We'll break down the following search phrase to explain its objectives:
The search phrase
( ship* | vehicle* | "cutlass" ) + ( explo* | destr* ) + ( hangar~ | land* | tak* )
First, observe the overall structure of the phrase. There are spaces between term-adjoining operators, and no spaces between term-modifying operators. By counting the sets of ( ) we can see there are three main parts. These are joined together by +, meaning that there are three matches that must be present in the report for it to show in the results. We'll tackle each set of ( ) separately next.
Step 1 - The item, asset or player affected
( ship* | vehicle* | "cutlass" )
Due to the presence of | in between each term, this means we are looking for one of three values for this set. All three terms seem to be related, though; they're all nouns relating to methods of transportation operated by the player.
In this case, these three values have been chosen to anticipate whether players might run into the same issue in different circumstances.
ship is the most commonly used term to describe player-operated transport in Star Citizen are most likely to match the other parts of the query we'll discuss later. We add a * to catch ships, too.
vehicle is a valid synonym which can apply to other types of player-operated transport that might encounter a similar issue in other circumstances. We add a * to catch vehicles, too.
cutlass is included in this case because this is the specific player-operated transport we were using when we ran into the issue. We use " to make sure we're looking for the specific ship model. It is important to include this too, because the issue could be specific to this vehicle, and having a lot of reports about a specific asset allows the QA and development teams to track the root cause of the issue down more quickly.
Step 2 - The event that occurs
( explo* | destr* )
This time, we're looking for one of two terms. These both seem to be the start of verbs in this case; events that occurred.
explo* could refer to explode, explodes, exploded, or explosion. It could also refer to unrelated terms such as explore, but that's why we have two more matches necessary; the combination will help ensure the results are relevant.
destr* could refer to destroy, destroyed, destroys, destroying, destruct, destructs, destruction, or destructed. This really shows the power of the * operator.
Checkpoint
So far, we have:
( ship* | vehicle* | "cutlass" ) + ( explo* | destr* )
This is quite a strong format to use for searching Issue Council. Summarized, it will check for reports that describe a particular thing and a particular event.
However, most of the time, issues only occur under specific conditions. It can be very difficult for internal teams to find the cause of the issue if they don't have a starting point for what to test. Therefore, it's important to include where you were and / or what you were doing when the issue occurred in your report. This forms the final part of the search phrase:
Step 3 - Where and/or when the event occurs
( hangar~ | land* | tak* )
Here we're providing terms that suggest where the issue occurred and when. Remember, the cutlass exploded when landing.
However, using a little imagination or (watching our video evidence closely) we might see that the explosion does not technically occur when the ship touched the ground, but instead when it crosses the threshold into the hangar. Therefore, it's worth searching for other common actions done at the same location.
hangar~ is commonly misspelled as hanger, and players might also think it occurs at all hangars.
~ solves this by looking for anything similar.
land* catches its tense variations.
tak* is the start of taking off, take off, takeoff, take-off. This term has a few different forms.
Step 4 - Time to search!
Filtering for active reports, we should see highly relevant results when using the entire search phrase:
The results show that it's likely that the issue is not limited to the Cutlass in this case, although it's worth clicking through and reading the content of the report in full before committing to contribute to it. It may be that it's actually describing a very different issue, and in that case it's worth checking some more results in the list.
Presuming the report does match our experience, it's good that we found out the issue was not ship-specific, as it means we can avoid our contribution becoming split from reports of other ships which would need to be merged by staff later. There are three benefits to keeping contributions centralized:
- Allows for a better initial assessment of the frequency and severity of the issue quicker for prioritization purposes.
- Reduces the amount of time needed to consolidate reports.
- Provides a larger pool of data for quality assurance to begin their testing with.
Please note: As with all issue management, duplicates are inevitable and should not be seen as a failure. Oftentimes, it is not possible to know that two issues have the same cause until a lot of data from various reproductions is combined and an investigation is completed.
General Use
We can simplify the example phrase, to get a general formula for effective Issue Council searches:
( ship* | vehicle* | "cutlass" ) + ( explo* | destr* ) + ( hangar~ | land* | tak* )
=
thing(s) + event(s) + where/when