I agree with most of the above Graham. However, my post is not merely about about what to call something. It's about understanding what that 'something' is. With User Stories, we are referring to that 'something' 's description or narrative. But not that 'something' itself.
User Stories are a great post-analysis device. Once we have captured and modelled our Requirements, which can be expressed as User Stories themselves, then writing Stories are a great way to help us define our Specifications, i.e. our system behaviour, i.e. our Features.
But User Stories as an analytical abstraction offer no more value (and sometimes less) than a business process diagram or a set of examples. Which is why we need to be analysing & parsing a Story/diagram/example into its constituent domain entities (Goals, Capabilities, Features) and refer to them instead of their ancestral story/diagram/example.
When a client comes to me with a User Story, example, conversation, etc, I will analyse its impacts and create a model (Impact Map). From then on I will keep referring to those model entities and I will communicate this to my client. I will also create new User Stories as descriptions for any derived Features. The original stories/examples/conversation are only transient descriptors that helped create the model. Any new stories just help describe our model entities. It's those entities that we're basing our system on, not the stories behind them.
So let's stop talking about 'User Stories' and start talking about:
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.