Hi, Daniel (and all),
I apologize if we have made you upset, but what started as an administrative task has grown to something more, and we won't intend that at first instance.
The decision of renaming the repo was something done for ease users to recognize the content of the repo, due to the description of it already includes that scope (you already remembered that previously, contract and project-service were joined). As Github makes this renaming transparent, redirecting all requests from the old name to the new one, there's nothing more to do. And all of this comes because there has been a request for including some contract-related modules.
This decision has been done in a quick way and without consulting for 2 main reasons:
- The scope of the repo hasn't changed.
- There is a component that nobody outside from the board values: the administrative work that a new repo means. Eric can say what is this when he made it for the first time for l10n-china.
Now, what it seems to hurt the most is the chosen name: vertical-service. Maybe we miss here your (contributors) opinion, that could be valuable, but it was done in the same sense: let's put a general name that doesn't restrict us in the future. Then we can discuss when PRs come, if we need to split across repositories on each version (as we do when merging contract and project-service).
Pleople, think on one thing: we are dealing constantly with the imperfection: there's no perfect classification, because in the ERP all is connected, integrated, overlapped... so repos are the "best compromise" to handle things in a manageable way, but we all have faced incongruences in modules locations, change of mind about repo creation/deletion, etc, because the "algorithm to decide" has so many side effects that ourselves apply it differently over time and over cases.
@Raphäel, the 1 repo = 1 module can alleviate this situation, but then the discussion will be moved to the tags applied to each repo, and you know the technical (and administrative) challenges that this architecture implies, but this solution is also on the table, you know by the other thread.
Said that, hoping that at least you understand our position, we don't want that you save this bitter taste about this topic, so if you think there's a more appropiate name for the repo, we can handle another renaming. We can even create another repo in the spirit of pleasing if enough arguments are given, but I have argued against it in this mail.