-
Notifications
You must be signed in to change notification settings - Fork 200
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
Comments
I may try to put together a PR for this "in my copious spare time." |
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 |
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 |
That's a great idea.
Sounds good to me. |
I want to be on the record that I am opposed to using this feature in WICG. |
That's up to y'all; keep the disagreement to wherever y'all discuss WICG stuff. An expiration feature is reasonable on its own. |
Okay, first cut at this is in #1654. |
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? |
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. |
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. |
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:
The text was updated successfully, but these errors were encountered: