Project naming: How can sources, evaluation dates, and unresolved questions be recorded?

When a project name gets chosen, the reasoning behind it often fades quickly. A few months later, someone asks why it was called that, whether other options were considered, or who made the final call. If no one wrote anything down, the answer is usually lost. A simple naming log — even a short text file kept alongside the project folder — is one way to keep that information available for later, though its usefulness depends on whether entries are actually made and kept up to date.

For sources, note where each candidate name came from. Was it suggested in a meeting, pulled from a reference document, proposed by a specific person, or generated during a brainstorm? You do not need a formal citation style. A line like "suggested by [person] during kickoff on [date]" or "derived from internal working title [X]" is enough. The goal is to let future readers trace the origin without having to ask around.

Evaluation dates matter because names often get revisited. If a name was proposed in March but only approved in June, that gap may explain why certain decisions were made in between — or why a name feels outdated by the time it goes live. Recording when the name was first raised, when it was discussed, and when it was confirmed gives anyone reviewing the project a timeline they can follow. This is especially useful when team membership changes and new members inherit a name they had no part in choosing.

Unresolved questions are the part most teams skip. Maybe the name works internally but has not been checked against external naming conventions. Maybe there is a concern about how it translates in another language, or whether it conflicts with an existing product elsewhere. Rather than leaving these as vague memories, write them down as open items with a brief note on what would resolve them. This keeps the question visible until someone actually addresses it, instead of letting it quietly disappear.

None of this requires a heavy process. A few lines per project — source, key dates, open questions — kept in a place the team already looks at, is usually sufficient. The point is not to create bureaucracy but to give yourself and future collaborators enough context to reduce the chances of re-deciding, misremembering, or walking into a problem that was already noticed but never written down.