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

Document expiration #1652

Closed
hober opened this issue Apr 23, 2020 · 11 comments
Closed

Document expiration #1652

hober opened this issue Apr 23, 2020 · 11 comments

Comments

@hober
Copy link
Contributor

hober commented Apr 23, 2020

Some standards bodies have a notion of documents which expire at some point. Internet-Drafts at the IETF work this way, for instance, and @WICG may add one (see WICG/admin#102).

It'd be nice if Bikeshed supported this or could automate this somehow. Here are some handwavy thoughts:

  • It should be possible to do this by hand for an individual document via metadata. e.g. add Expires and have it take the same format as Date.
  • It should be possible for document statuses to get this automatically by default.
  • The default bikeshed boilerplate should take this into account and throw up a warning (warning-expired.include), and this should be overridable / customizable per-group and per-spec like all other boilerplate is today
@hober
Copy link
Contributor Author

hober commented Apr 23, 2020

I may try to put together a PR for this "in my copious spare time."

@tabatkins
Copy link
Collaborator

Hm. I'm definitely fine with adding this.

If we use the warning system, then perhaps Bikeshed can default it to open or closed depending on whether it's expired at generation time (and if it starts closed, then we put JS in to toggle it open based on the current date.

Probably we want to put a class on <body> too, so you can do things like change the background? A big ol' EXPIRED SPEC like the UNOFFICIAL DRAFT background?

@tabatkins
Copy link
Collaborator

It should be possible for document statuses to get this automatically by default.

Curious what you're thinking about with this. Like, auto-expire based a duration from the generation date? (So specs that just aren't touched for years get expired?)

@hober
Copy link
Contributor Author

hober commented Apr 23, 2020

It should be possible for document statuses to get this automatically by default.

Curious what you're thinking about with this. Like, auto-expire based a duration from the generation date? (So specs that just aren't touched for years get expired?)

Yes. e.g. I-Ds expire 185 days later, IIRC.

Expires could take an ISO 8601 date or duration, maybe? So you could say things like Expires: 2021-01-01 or Expires: P6M. The former is an absolute date for expiration, and the latter is 6 months after the generation date (or the value of the Date: metadata).

@hober
Copy link
Contributor Author

hober commented Apr 23, 2020

If we use the warning system, then perhaps Bikeshed can default it to open or closed depending on whether it's expired at generation time (and if it starts closed, then we put JS in to toggle it open based on the current date.

That's a great idea.

Probably we want to put a class on <body> too, so you can do things like change the background? A big ol' EXPIRED SPEC like the UNOFFICIAL DRAFT background?

Sounds good to me.

@cwilso
Copy link

cwilso commented Apr 23, 2020

I want to be on the record that I am opposed to using this feature in WICG.

@tabatkins
Copy link
Collaborator

That's up to y'all; keep the disagreement to wherever y'all discuss WICG stuff. An expiration feature is reasonable on its own.

@hober
Copy link
Contributor Author

hober commented Apr 23, 2020

Okay, first cut at this is in #1654.

@jyasskin
Copy link
Collaborator

It's not clear that the IETF is happy with their experience with I-Ds claiming to expire. @martinthomson, you'd be the expert here: is draft expiration something that anyone else should do?

@martinthomson
Copy link

There are a few people in the IETF who believe that a dead-mans switch is necessary on every draft specification. I tend to subscribe to a different school of thought on that: the last update is usually a sufficient indicator for the most important question, being "how useful is this specification?" That's the most important question generally.

As the change here is discretionary, it's a bit different than what the IETF does. An explicit choice to arm a timer carries with it a promise. I don't like making promises of that nature, but that is just my preference based on my own experience. I can respect the desire to want to create this sort of signal.

The design in #1654 uses the generator to add the notice. That means that you have a dependency on the generator running. If not daily, then at least on some reasonable interval such that the abandoned work is updated to show the notice. I would have thought that JS would be better in that the content could update dynamically. But that might not be consistent with BS principles.

@tabatkins
Copy link
Collaborator

Note that the final commits I added before merging do indeed add JS if you're in the pre-expiry when you generate, which checks the date and flips it over to an open expiry notice once the date passes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants