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
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:
The text was updated successfully, but these errors were encountered:
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]
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:
The text was updated successfully, but these errors were encountered: