Is the compute time of recalculating it over and over again more or less burdensome than receiving multiple PRs and spending the time to address each of them – including closing five (or more next year!) of them?
If you answer that I think you'll have a good reason to either merge or close the Time.current.year PR 🤗
I actually quite enjoy this odd throwback ritual, but acknowledging that in pure software/productivity terms it should be computed. Merged a PR that does that.
Since we're eyeing a future where people can stand up their own version of our open source platform community, hardcoded dates will eventually be bad legacy code.
Since we're hoping that future happens at some point in 2019, makes sense to go computed now. 😂
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Is the compute time of recalculating it over and over again more or less burdensome than receiving multiple PRs and spending the time to address each of them – including closing five (or more next year!) of them?
If you answer that I think you'll have a good reason to either merge or close the
Time.current.yearPR 🤗Abhaha I agree with you, let's keep it hard-coded or put it dynamic but in a partial, cached until 2019 ends 🤔
I actually quite enjoy this odd throwback ritual, but acknowledging that in pure software/productivity terms it should be computed. Merged a PR that does that.
Since we're eyeing a future where people can stand up their own version of our open source platform community, hardcoded dates will eventually be bad legacy code.
Since we're hoping that future happens at some point in 2019, makes sense to go computed now. 😂