Period should not be required for a card

[inghamn]

Different metric types do not necessarily need a range of time. For instance, metrics that are simple counts of something only involve a single point in time.

We should make it so that the time period is not a required field for cards. The period field should still be passed to the Service methods, if it's provided.

[rbdietz]

Cards with counts may need a date. For instance, the dataset goal is 100
datasets by Jan 1, 2018.

On Wed, Nov 16, 2016 at 1:39 PM, Cliff Ingham notifications@github.com
wrote:

Different metric types do not necessarily need a range of time. For
instance, metrics that are simple counts of something only involve a single
point in time.

We should make it so that the time period is not a require field for
cards. The period field should still be passed to the Service methods, if
it's provided.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#14, or mute the
thread
https://github.com/notifications/unsubscribe-auth/ABFVegY6ibjqK2ywQc_UEFhuujur8m1lks5q-03PgaJpZM4K0RoJ
.

[inghamn]

Yes, we still require an effective date parameter for the card. What we're not requiring is the time period parameter.

In the current metrics, the time period parameter is set to 30 days. This makes sense for calculating "the percentage of reports that are responded to on time". More precisely, it is:

The percentage of reports [submitted within 30 days]

Within 30 days of what? Now? Yesterday? October 17th?

The percentage of reports - submitted up to 30 days before some arbitrary effective date.

All metrics are going to require support for an effective date declaration. Its this day range declaration that should be optional.