Skip to content
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

Display Delay at every Event #1139

Open
AWi92 opened this issue Jul 15, 2024 · 1 comment
Open

Display Delay at every Event #1139

AWi92 opened this issue Jul 15, 2024 · 1 comment
Labels
improvement Improvement on existing feature

Comments

@AWi92
Copy link

AWi92 commented Jul 15, 2024

First of all, I would like to say that I really like your software and that this is exactly what I wanted to program some time ago. How quickly the delay (over / undertime) feature was implemented was impressive and that's what makes the software really useful for me.

For the analysis during the event and especially after the event, I would find it practical if it could be displayed per event how much delay this event has produced (positive and negative).
Especially for events with the same crew, this information could help to organize processes differently / better for the future. For example if the opening allways produces -3 min delay maybe we should change this duration from scratch or find out why it takes so much extra time.

If this is not a feature that is relevant for other users, I think that your extensive API gives me enough data to log this by myself.

Here is a image that shows what I mean:
image

@cpvalente
Copy link
Owner

cpvalente commented Jul 15, 2024

Hi! Thank you for taking the time to write this proposal.

We have investigated a similar feature in the past which we called the reporter.
The initial specification was written in a comment here
#165 (comment)

We ended up making a demo implementation but hit some roadblocks on deciding how the feature should behave, at the time, we could not find users with a workflow that would make use of the feature so I took it as a sign that the feature had little value to the users.
We ended up pushing this back in priority and adding a comment Reporter (has to be useful to runtime)
Perhaps I was wrong or this has changed?

In my proposed implementation, the report was something you could download after a show was done. We saw that this could be useful for users that need to keep track of deviations on the time something took (like in repertoire theater). Your proposal takes it a (good) extra step of pushing it one extra level by showing it as the rundown progresses, this sounds to me like a step in the right direction in satisfying the condition has to be useful to runtime.

A good first step could be revisiting the initial specification. If you would like to collaborate with us on the creation of this feature by providing testing and guidance on the specification, it would be much appreciated. If so, please do get in touch at [email protected]

@cpvalente cpvalente added the improvement Improvement on existing feature label Jul 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
improvement Improvement on existing feature
Projects
None yet
Development

No branches or pull requests

2 participants