You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: DataFormats/QualityControl/README.md
+3-2Lines changed: 3 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,7 +15,7 @@ Data quality is determined through two methods:
15
15
16
16
Both methods utilize the same data format for Flags.
17
17
During processing (both synchronous and asynchronous), Checks produce Qualities and associate them with Flags.
18
-
The Quality Control framework then transmits these Flags to the RCT through a gRPC interface (**not ready yet**, to be done in the scope of QC-978).
18
+
The Quality Control framework then transmits these Flags to the RCT through a gRPC interface (more details in QC repository documentation).
19
19
Detector experts can then review the automatically generated Flags and make any necessary modifications or additions directly in the RCT.
20
20
21
21
### Quality Control Flag Structure
@@ -49,12 +49,13 @@ Each Flag Type has the following attributes:
49
49
#### Creating and Managing Flag Types
50
50
51
51
***FlagTypeFactory** ensures a centralized and consistent list of available Flag Types.
52
-
New types can only be created through this factory.
52
+
New Flags can only be created through this factory.
53
53
***[flagTypes.csv](etc/flagTypes.csv)** defines the existing Flag Types, including their ID, name, and "bad quality" determinant, factory method name and a switch to deprecate a flag.
54
54
The table serves as the source to automatically generate the corresponding methods in FlagTypeFactory.
55
55
***Adding new Flag Types:** If a new issue requires a flag not currently defined, propose the addition by contacting the async QC coordinators.
56
56
They have the authority to add new Flag Types to the RCT.
57
57
These changes will then be reflected in the [flagTypes.csv](etc/flagTypes.csv) file through a pull request.
58
+
Any proposals for new Flag Types should describe the effects on usability of data from analyzer point of view and they should not be detector-specific unless well-argumented.
58
59
***Modification of existing Flag Types:** Existing Flag Types should not be modified in terms of their definition.
59
60
Instead, one may create a new Flag Type and mark the existing one as obsolete in the CSV table.
60
61
This will add the `[[ deprecated ]]` attribute to the corresponding method.
0 commit comments