Bikeshedding the specification name

[ctcpip]

this issue is to bikeshed the name of the spec

my thoughts right now on the current working name, contributing.yml are:

• coupling the name of the spec with the interchange format
  • I think we should avoid this
• 'contributing' is narrower in scope than what the spec is meant to cover

my suggestion is to call it 'Sustainability Specification'

'sustainability' is the word that, IME, is most frequently used when discussing the subject matter of what the spec is intended to cover. one example being the OpenJS Foundation Sustainability Group

what do others think?

[MattiSG]

+1

• The Sovereign Tech Agency uses “resilience” and “sustainability”.
• The Functional Source License aims at solving “developer sustainability”.

[sjn]

With apologies, I may be somewhat at fault for opening this bike-shedding discussion.

My initial intention was changing the name from "Contributing.yaml" to "CONTRIBUTING.yaml", so the project name more clearly communicates what is the main expected output of this group: A specification for a machine-readable file, that is functionally equivalent to CONTRIBUTING.md.

My claim is that CONTRIBUTING.yaml communicates this a little better than Contributing.yaml does.

Originally, the project was called "OSS Sustainability" We had a naming discussion back in September when this project was considered for inclusion into TC-54, and back then the proposed new name (that was ultimately dismissed) was "The Dugnad specification".

I'm happy with the name as it is, with the capitalization as my only nit to pick.

[ctcpip]

Thanks Salve. I think there may some misunderstanding of the point I intended to raise.

My concern is in regard to semantic coupling between the specification's scope/purpose and its filename/format.

Right now the working name Contributing.yaml implies:

• the spec is primarily about what the interchange format is called
  and
• the spec is coupled to a single file format

TC54-TG4's scope/programme of work suggests the purpose of the spec goes beyond the filename itself.

The goal is to provide machine-readable information about project sustainability and support; thus naming the spec after the role it plays (e.g. 'Sustainability Specification', 'Sustainability Metadata Specification', or similar) would make it clearer to adopters what the intent is, regardless of actual file name or extension.

This also allows future flexibility, e.g. if tools support alternate serializations or locations.

My suggestion is that we name the spec such that it describes what it does rather than how it is encoded or how the file is named, because conflating the two makes the intent less clear to consumers and tooling.