Subject: [Tools-implementation] Why we're looking at the filesystem structure

From: Robert Sparks <[email-masked]>
Date: Mon, 31 Aug 2020 22:09:55 -0500

I've been thinking deeply about both Glen and Henrik's questions about 
why we are looking at the filesystem structure and what our goals are 
when we talk about changing it.

One insight that I think I've identified is that this activity is a 
means to an end, not an end in itself, and we are probably being 
distracted by focusing on what the filesystem structure should be.

It's more important to understand what we really _have_ than it is to 
"fix" it (though I think we should keep the pressure up on making it 
better).

The more important goals are being able to discuss doing something less 
painful to us (operators and coders) and more useful to the community 
than what we're doing now with providing services. When we've tried to 
approach those in the past, we've felt that we need to do things like 
reduce confusion in the URL namespace at www.ietf.org and understand the 
subtle requirements we currently have with services relying on files in 
the various places we have them. Talking about _those_ things,  we've 
run quickly into the need to understand what the files we have are all 
about, and then get lost focusing on changes rather than understanding 
what's there.

I think we're risking getting lost again. The apparent goal we're 
pushing towards (defining a better structure) is not really the what 
we're trying to achieve, though it is providing a good pressure for 
making progress towards those more important goals.

We need to understand and document the things we have. The 
keep/archive/discard conversations are good ways to help us build that 
understanding, but if we build a "perfect" structure in isolation of 
what we're going to do with it, the effort isn't going to pay back well. 
We need to make sure we understand what we're going to do with the result.

Reducing confusion in the www.ietf.org URL namespace is both a "make it 
easier for the user" and "make it simpler for the code and operations" 
goal. Being able to _know_ whether we can pull a service off into the 
cloud without breaking other services (or at least really understanding 
how those other services will have to change) is a prerequisite for 
reducing our pain, and improving the experience for the community. Those 
are goals we should make sure we are moving towards.

There are obvious things to change with where we're keeping things (and 
in some cases, what we're keeping), yes. Let's change them.

But I think we should change the timbre of the conversation and make 
sure we're talking about "what is that" and "what/who uses that" at 
least as much as we're talking about "do we need to keep this". (But 
let's not ignore "should we keep this" and "what do we do with it if we 
_do_ keep it" as we're talking about it).

RjS