feat: adopt collective ownership

[dottiOliviero]

Not sure if the naming is the best one, but the intention is to define a practice in which we are crystal clear in our communication.
Having repos without readmes, or with incomplete ones is not acceptable if we want to build a company in which we cooperate at each level.
Another example is the naming of the services. If we look at AppSales example, they are generic enough but not necessarily using pokemon names or acronims
What is your feeling about this?

[giorgiovilardo]

+1

i dont see the point in having non-descriptive project names. if you want to have a codename sure (write it in the readme), but the repo should be explicative of what it does as a form of respect for your colleagues if anything else.

if you have difficulties having a descriptive project name it's because your project is badly scoped.

the readme stuff in theory is covered by https://github.com/casavo/adr/blob/master/doc/adr/0007-common-stucture-for-project-readme-md.md , but no enforcement has been done.

[giorgiovilardo]

thightly -> tightly

[xpepper]

Not sure if the naming is the best one, but the intention is to define a practice in which we are crystal clear in our communication. Having repos without readmes, or with incomplete ones is not acceptable if we want to build a company in which we cooperate at each level. Another example is the naming of the services. If we look at AppSales example, they are generic enough but not necessarily using pokemon names or acronims What is your feeling about this?
I agree. As @giorgiovilardo was pointing out, we already have a clear decision documented in our ADRs: https://github.com/casavo/adr/blob/master/doc/adr/0007-common-stucture-for-project-readme-md.md, but no one reads ADRs apparently.

@dottiOliviero not sure if the name "collective ownership" is the most meaningful here, as you also were saying. But I agree we need to be clear on some foundational practices, like having up-to-date and useful README files, or having the proper level of automation in place (e.g. one thing I really liked the first days of Casavo was that each project had its own Makefile with a lot of useful tasks for the project automation).

In my view, these "foundational practices" should all aim at removing friction in software development. It reminds me of this article by John Cutler (https://cutlefish.substack.com/p/tbm-240-the-ultimate-guide-to-developer): we should enforce practices that help us be less "counter-productive".
E.g. having a clear and updated README goes in that direction.

BTW It would be nice to have an open discussion on what help us every day to be a bit less "counter-productive" and spend more time on high-leverage activities @pferretti.

[xpepper]

I like the description you added:

encourages everyone to contribute new ideas to all segments of a project, meaning also projects not in the scope of the team. This is tightly coupled with coding standards and translates, for example, in having clear service name and meaningful READMEs

Still, I consider this probably "borderline" as a blip in the tech radar, but I definitely agree with the statement and the overall mindset of "Collective Ownership".
So I approve this, and wait for other people opinions on this.

[dottiOliviero]

reading all your comments i think that the best place for this is the ADR and we should find a way of distributing and enforcing this as a basic practice for all our projects