-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unify concepts and naming around pending, ignore list, released, etc tickets #164
Comments
Currently there's a streaming gRPC call for getting assignments. If a ticket can only be assigned once, we could change this into a long poll rpc with no streaming. It just returns an assignment when the ticket gets an assignment. |
This was discussed in TSC and the resolution is same as what we discussed internally. For now, we need not have a state machine with new states for the Ticket etc. We can cleanup naming to be consistent - but scope the changes in v1.0 to just that. |
Naming wise, I think we've settled upon these names for states and transitions: I've check the protos, and their names are fine. The documentation on the protos and internal naming isn't all up to date however. Additionally, it's possible to move tickets directly from active to assigned (which might be ok, unsure), and it's possible to assign to an already assigned ticket. These are things I think we can clean up within the backwards compatibility guarantee. Though getting it done by 1.0 would be good. New documentation should use this model, and old documentation should be updated to use it. At some point the code should also be rectified to use this. Some examples of bad areas:
|
This has been done to external API naming / documentation. |
There's currently several different names and concepts around ticket state where it has been returned from a fetch match calls, but it has not yet been assigned or deleted. In the API surface, documentation, and internal code this doesn't have a consistent conceptual model.
The task is a consistent conceptual model on ticket state should be developed. Names and documentation should be changed to follow this conceptual model.
The text was updated successfully, but these errors were encountered: