What the client updates identify is the codebase family, not the organization¶
Corrects the interpretation of the entry above, whose tables stand. The organization accuracy of 0.912 is a statement about class means, and class means inherit the class's composition. Per project, measured from the same cosines:
| from | toward | relation | mean cosine |
|---|---|---|---|
| pyside (Qt, Python) | Qt C++ | same organization | 0.215 |
| pyside | OpenStack Python | same language | 0.212 |
| pyside | Qt docs | same organization | 0.181 |
| starlingx/docs (OpenStack) | OpenStack Python | same organization | 0.227 |
| starlingx/docs | Qt docs | same content | 0.219 |
| qtdoc (Qt) | Qt C++ | same organization | 0.230 |
| qtdoc | OpenStack docs | same content | 0.219 |
| nova | neutron, ironic | same organization and language | 0.274 |
| qt-creator | qtbase | same organization and language | 0.263 |
| OpenStack Python | Qt C++ | neither | 0.252 |
Qt's one Python project is no more Qt-like than Python-like; it is an island. The documentation projects lean toward their own organization by 0.01 at most. What stands out is a family: the OpenStack Python services align with one another as closely as clients of one project do, and so do Qt's two C++ libraries. Neither organization alone nor language alone raises alignment; the two together do.
So the within-content rows of the entry above are family tests in disguise: within Python the Qt side is one project, within documentation each side is one project, and a project is recognisable from its update. (The C++ cell built to settle this later returned 0.395 against a 0.698 baseline: no organization effect at all beyond content and project.) The defensible claim is that a client's update identifies its codebase family. Whether the organization is what defines a family, a house style shared across the organization's projects in one language, cannot be separated here, because each organization-and-language cell holds one to three projects and the only cross-organization comparison within a language rests on one Qt Python project.
This agrees with the separability probe and with RQ1's project contrasts, both of which put the signal at the codebase rather than the organization. Three instruments now point the same way.
What would separate them. Several projects per organization in one shared language, on both sides. The train and dev windows offer that only for OpenStack Python (starlingx/test, config, distcloud, swift, nova, neutron, ironic); Qt's Python is pyside alone. A third Gerrit organization with several Python projects (Wikimedia's hosts pywikibot and many Python tools) would give the cross-organization, same-language, multi-project cell this design lacks.