On Fri, Jan 26, 2024, at 23:30, Michael Richardson wrote:
Lucas Pardue <lucas@xxxxxxxxxxxxxxx> wrote:> The work I follow is done on GitHib, where a live editors copy is> always available. I-Ds are published to capture what the authors> believe to be a logically complete changeset. The timeliness for> working through issues don't march to the beat of arbitrary draft> deadlines. Publishing logically incomplete changesets is a waste ofI think you've just completely undermined your argument for no-expiry :-)
Not really.
1) Since it's all in github, republishing the "old" document amounts to justcreating a single tag, and pushing that. The effort has gone fromWarren's ~1min, to ~4s to push a button. The WG chairs can even do this.
Publishing a document that does not reflect the current state is a potential source of confusion. It might be easy to do but it's literally a waste of time. It's an action required to appease a process with an arbitrary date. The suggestions to allow WG chairs finer grain control of
2) If WG authors can not come to a reasonable minimal increment in lessthan 6 months, then I think the relevant WG chairs need to schedule manymore interims. THERE ARE PROBLEMS. Maybe even physical ones.
That's easy if you can predict the future. It's harder if things come up. An interim isn't going to answer a case like "I want to gather data to inform this design decision". Any reasonable project management has the ability to slide timeliness due to reality. Arbitrary fixed expiration dates do not.
I also note that the minimal increment might be the adequately describe whatthe tusscle is.Github issue tracking/discussion is useless after two weeks, and multiplerebases.
I strongly disagree. If you encounter that, I would suggest better issue management and document contribution guidelines. I've successfully worked on issues and proposals that span months to years.
ADs and appeal bodies are not going to be able to figure it out.(And I used to rebase projects in CVS)
I doubt GitHub is a contributing factor to that. Do you have examples?
> time; it can be better to postpone and let a draft expire rather than> publish something that's broken. Does that mean the document is dead?> No. It's active as evidenced by the progress of mailing list discussion> and GitHub activity. But what happens is cycles are wasted by people> trying to figure this out from plain English statements that are> cryptic to apply to our tooling and processes.> Furthermore, I'm surprised nobody has brought up the fact that expiry> is trivially gamed by anyone that wants to keep an I-D permanent> alive. No-change keepalive updates are a blot on the archive.So? If you know how to game the system, then you are an insider.Many of us are worried about what outsiders do.{Many of company's marketing person has been caught lying about their productsbeing an "RFC" by the expiry process. I speak from multiple experience,including having to go down the hall and rip ... }
Are you suggesting the marketer checked the expiry date on an I-D and wouldn't have claimed it was an RFC if it has expired? Or that the people that were being marketed to would do the check. Or perhaps nobody would even really care to check?
Since an expiration date has no context, the only status check that can be applied in isolation is a validity check, which is trivially gamed. The suggestions to provide an explicit link to the datatracker in I-Ds offer the opportunity for so-called outsider to be given a nudge to go find out more. As Rob Wilton suggests, if we can make the UI even more accessible to such needs, we stand to improve things.
