James,

Given that this post continues a pattern I have observed in you of asking loaded questions, repeating the same questions over and over, and assumptions of bad faith, I would not be surprised if people do not find it to be a fruitful use of their time to engage with you. You may wish to consider this for the future.

On 28 January 2017 at 19:45, James Salsman <jsalsman@gmail.com> wrote: 
1. Is the ability to rerun metrics more important than protecting
reader privacy?

This is a classic example of a loaded question. You also asked almost this exact same question two months ago, and received several answers. What is the reason for you asking almost exactly the same question again?
 
2. On what basis is the decision on the previous question made, or if
there is no decision on the question yet, who has the authority to
establish that basis?

On what basis was the decision made to have logs? Nuria already answered this question. They are essential for debugging problems and understanding our readership so we can serve their needs better. To quote Nuria, who was even repeating herself when she said this, "Again, repeating myself: could we make this 60 days interval slightly smaller? Yes, probably, a bit. Could we do without short term retention of raw IPs? No, not really." Again, I am unsure what you hope to learn by repeating this question.
 
3. Can Ops use access logs in which the article names have never been
stored on permanent, non-RAM media?

4. Can the users who require logs of article names use those in which
the IP address, proxy information, and geolocation has never been
stored on permanent media?

The implicit assumption here is that reasonable means are not being taken to safeguard user data by Technical Operations, which is not a good way to start a conversation. You have also made other technical assumptions, such as that one can only use volatile storage to safely store data. I suggest you trust the expertise of Technical Operations, since these questions appear to show you do not posses such expertise yourself.

Dan