Initial client

[aricart]

Not sure why we need to separate - perhaps all that needs to happen is that server only ADRs should be labeled as "SERVER ONLY", as in most cases an ADR for the server will have some sort of impact on the client. IE all the ADRs on server dir have some significance on the client.

[scottf]

I could number them starting with 1 but I thought to differentiate between client and server. Too bad tools aren't smart enough to allow manual assignment of a number or to just figure out what the largest number is. I'm guessing I could even write go code to create a file from a template with the proper number. Also, don't we all know markdown?

I disagree that all adrs in the server folder will have impact on the client. Configuration is a prime example of both major confusion and lack of documentation that does not specifically affect building a client.

[ripienaar]

I think there consensus on the call. We have ADRs. Not ADRs for many different purposes.

[aricart]

I disagree that all adrs in the server folder will have impact on the client. Configuration is a prime example of both major confusion and lack of documentation that does not specifically affect building a client

Every single ADR in the server dir deals with client things.

[ripienaar]

ADRs are not for every configuration setting. They would be to describe the general design and approach taken with the configuration system as a whole or as a detail on how we might integrate with KMS systems as a general capability.

If you want to document a config item go right ahead and make a docs PR. Or handle it as a task. ADRs are not documenting for end users nor are they task lists or references.

The existing documented process has this:

When to write an ADR

Not every little decision needs an ADR, and we are not overly prescriptive about the format. The kind of change that should have an ADR are ones likely to impact many client libraries or those where we specifically wish to solicit wider community input.