[Oct 9] Allow a grace period before closing a submission phase

[LowPolyCount]

IE, If we close at 11:59pm, don't close until 12:09am. This will help prevent confusion.

[LowPolyCount]

If we could get this for phase 2 closing (September 30th, 2017) that would be an incredible help!

[thaeli]

..why can't we just set the close time in the system later than we announce the close time to be? I understand the intent of this change, but it does add non-intuitive behavior (making the system behave in a different fashion than the config file states) and we should avoid that as much as possible.

…

On Sat, Sep 9, 2017 at 7:43 PM, Joel Gonzales ***@***.***> wrote: If we could get this for phase 2 closing (September 30th, 2017) that would be an incredible help! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#99 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXeemew1Xa8UUPOBQRy9NlBjbcqWDKdks5sgyK3gaJpZM4PSJzi> .

[kitsuta]

The literal answer to your question is that the string that shows the deadline (e.g., on the application page, in the emails) is the same date string that's actually used for the deadline. We can add a buffer... it would be pretty non-standard in comparison to other deadlines, but it wouldn't be too tricky. Most deadlines in the system are not fuzzy, though, and I think we'd like to keep it that way.

…

On Sat, Sep 9, 2017 at 8:53 PM thaeli ***@***.***> wrote: ..why can't we just set the close time in the system later than we announce the close time to be? I understand the intent of this change, but it does add non-intuitive behavior (making the system behave in a different fashion than the config file states) and we should avoid that as much as possible. On Sat, Sep 9, 2017 at 7:43 PM, Joel Gonzales ***@***.***> wrote: > If we could get this for phase 2 closing (September 30th, 2017) that would > be an incredible help! > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#99 (comment)>, or mute > the thread > < https://github.com/notifications/unsubscribe-auth/AAXeemew1Xa8UUPOBQRy9NlBjbcqWDKdks5sgyK3gaJpZM4PSJzi > > . > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#99 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG3WB-_NqCsE2c_fIq3-bGAcd2wd1mZ8ks5sgzL1gaJpZM4PSJzi> .

[thaeli]

Ah. I'd prefer to implement as adding new "public_closing_time" config options instead of a grace period in only this one place.

…

On Sep 9, 2017 10:07 PM, "Victoria Earl" ***@***.***> wrote: The literal answer to your question is that the string that shows the deadline (e.g., on the application page, in the emails) is the same date string that's actually used for the deadline. We can add a buffer... it would be pretty non-standard in comparison to other deadlines, but it wouldn't be too tricky. Most deadlines in the system are not fuzzy, though, and I think we'd like to keep it that way. On Sat, Sep 9, 2017 at 8:53 PM thaeli ***@***.***> wrote: > ..why can't we just set the close time in the system later than we announce > the close time to be? > > I understand the intent of this change, but it does add non-intuitive > behavior (making the system behave in a different fashion than the config > file states) and we should avoid that as much as possible. > > On Sat, Sep 9, 2017 at 7:43 PM, Joel Gonzales ***@***.***> > wrote: > > > If we could get this for phase 2 closing (September 30th, 2017) that > would > > be an incredible help! > > > > — > > You are receiving this because you are subscribed to this thread. > > Reply to this email directly, view it on GitHub > > <#99 (comment)>, or > mute > > the thread > > < > https://github.com/notifications/unsubscribe-auth/ AAXeemew1Xa8UUPOBQRy9NlBjbcqWDKdks5sgyK3gaJpZM4PSJzi > > > > . > > > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#99 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AG3WB-_NqCsE2c_fIq3- bGAcd2wd1mZ8ks5sgzL1gaJpZM4PSJzi> > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#99 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXeek4VMj8C1qD761BLfxHCM7el6ycZks5sg0RYgaJpZM4PSJzi> .

[kitsuta]

I think in some ways having it be unique to the MIVS plugin/workflow makes business-logic sense. If someone can't manage to fill out a regular ol' form in time, they're just being silly... but with something like prepping a game or video for submission, there's like a million things that can go wrong on you. I imagine it's like when you've finished your essay just in time for school but then the printer decides that functioning is optional... except you have four different steps that are that printer (video editing/exporting software, YouTube/other service upload, YouTube/other service PROCESSING, probably more I haven't thought of). In that case, an extra 10 minutes' leeway makes sense, because the submitter may have that kind of delay introduced by other steps in the submission process that are outside of their (and our) control.

…

On Sat, Sep 9, 2017 at 10:17 PM thaeli ***@***.***> wrote: Ah. I'd prefer to implement as adding new "public_closing_time" config options instead of a grace period in only this one place. On Sep 9, 2017 10:07 PM, "Victoria Earl" ***@***.***> wrote: > The literal answer to your question is that the string that shows the > deadline (e.g., on the application page, in the emails) is the same date > string that's actually used for the deadline. > > We can add a buffer... it would be pretty non-standard in comparison to > other deadlines, but it wouldn't be too tricky. Most deadlines in the > system are not fuzzy, though, and I think we'd like to keep it that way. > > On Sat, Sep 9, 2017 at 8:53 PM thaeli ***@***.***> wrote: > > > ..why can't we just set the close time in the system later than we > announce > > the close time to be? > > > > I understand the intent of this change, but it does add non-intuitive > > behavior (making the system behave in a different fashion than the config > > file states) and we should avoid that as much as possible. > > > > On Sat, Sep 9, 2017 at 7:43 PM, Joel Gonzales < ***@***.***> > > wrote: > > > > > If we could get this for phase 2 closing (September 30th, 2017) that > > would > > > be an incredible help! > > > > > > — > > > You are receiving this because you are subscribed to this thread. > > > Reply to this email directly, view it on GitHub > > > <#99 (comment)>, or > > mute > > > the thread > > > < > > https://github.com/notifications/unsubscribe-auth/ > AAXeemew1Xa8UUPOBQRy9NlBjbcqWDKdks5sgyK3gaJpZM4PSJzi > > > > > > . > > > > > > > — > > You are receiving this because you are subscribed to this thread. > > Reply to this email directly, view it on GitHub > > <#99 (comment)>, or > mute > > the thread > > < https://github.com/notifications/unsubscribe-auth/AG3WB-_NqCsE2c_fIq3- > bGAcd2wd1mZ8ks5sgzL1gaJpZM4PSJzi> > > . > > > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#99 (comment)>, or mute > the thread > < https://github.com/notifications/unsubscribe-auth/AAXeek4VMj8C1qD761BLfxHCM7el6ycZks5sg0RYgaJpZM4PSJzi > > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#99 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG3WB1FHaxRuo0s7Tw8bwLfMbJgn4wB9ks5sg0bUgaJpZM4PSJzi> .

[kitsuta]

Gonna try to get this done before the new round two deadline on Oct 9th!