Robert, (Still copying ietf@ because I think these issues are important to the whole community, not just those with the time and energy to track tools-discuss) I don't know the notes facility well enough to ask this question precisely --I qualify as one of those who had barely heard of it before these threads started -- but it seems to me that you've made a strong case for per-thread timeouts/ delete limits. Some things (like minutes) should disappear quickly for reasons others have given; others (like design team efforts) may need "after inactivity" or other much longer timeouts. So it sounds as if any feature requests should allow for per-thread/ per-activity timeouts, not just a global setting or that we should start distinguishing, RSN, among different types of notes. FWIW, I note that, while I-Ds supposedly expire after six months, things have evolved to the point that we still say that but old ones are essentially treated as archival with no special effort need to get to them. That is an extreme example of the bottom of the slippery slope I think others have been concerned about. best, john --On Friday, September 17, 2021 08:28 -0500 Robert Sparks <rjsparks@xxxxxxxxxxx> wrote: > (Setting Reply-To once again - lets please reduce the > crossposting and move the whole conversation onto > tools-discuss@) > > I'm going to take up part of Carsten's argument now, > attempting to wear no hats. > > I personally don't want a "delete n days after creation" type > of policy. I could accept (and probably support) a "delete > after n days of inactivity" policy where n was large - at > least two meeting-cycles large, if not larger. > > This tool is being used for other things than working group > minuting. > > There are teams that I am on that have used notes as places to > develop things like tools implementation plans - the notes > served a longer than a few (even 30) days purpose until the > effort finished. I can see the same being useful for design > teams, where the real artifacts that come out are emails to > the list and drafts. The expectation, in my opinion, is that > these should be expected to be there for awhile, but not > _forever_. > > What I don't think is ok is carrying the need to redirect > these urls a few years from now when the technology under them > has moved on. URLs into this service shouldn't be placed in > RFCs, giving us the burden to preserve the content and its > location forever. > > Putting my tools team hat back on - hedgedoc does not (to my > knowledge) support this autodelete concept at this time. We > could make a feature request whether or not it ends up being > something we decide to use. But should we decide to have such > a delete policy, it would be some time before it is > implemented. > > RjS > > > On 9/16/21 9:47 PM, Carsten Bormann wrote: >>> In doing so, you've now also characterised others' positions >>> in a disparaging way and expressed cynicism about the IETF >>> process. I understand you may be frustrated, but I don't >>> think doing so is constructive. >> Mark, >> >> sometimes it is absolutely necessary to express how a >> discourse makes one feel. >> >> Yes, this discussion is frustrating and unlikely to lead >> anywhere good, and I have to choose my battles. >> >> I made my points, and I will shut up now. >> >> Grüße, Carsten >> >
