Change culture in OpenZipkin isn't currently templated on well defined processes such as exist in the ASF. Neither is the loosely defined benevolent dictator role.. well defined.. Plus, it isn't exactly the same per repo. None of these things are problems, just realities.
OpenZipkin has many repos and the ones that progress have a champion (or few) who ultimately make decisions to accept or hold off on change. In some cases, particularly documentation and spec repos, decision making or collaboration is far wider, as we try to ensure parties not in the OpenZipkin org are engaged.
There is a core group in OpenZipkin who have sustained efforts and interest, many times working on change they aren't paid to work on nor personally care about. We don't formally dub people like this with titles, but we appreciate them. We have no obvious roster, but it is easy to tell who are more active than others, and who help with the burden of decisions and change.
I have plopped guidance about what sort of change I think is in the long term interest of the projects I spend most time on. It isn't always popular (believe me), but we also can't rely on hiring people to maintain code either. https://github.com/openzipkin/brave/pull/287 So when I'm working on projects I usually follow the same process.
Others follow different processes, but it usually boils down to this: change is merged based on the judgement of those who bear the responsibility and highest burden of change. It isn't merged by committee of folks not fixing bugs or supporting it. Netflix calls this Freedom and Responsibility.
This is a bit of a ramble, but @cschneider asked since it isn't written down, and of course next time we talk about foundation, process and bylaws it might be easier to have it summarized someplace. I'd be happy for someone to polish this more, or pitch into how they lead their OpenZipkin repo which might be different than how I perceive things.
codefromthecrypt
commented
7 years ago
We had a discussion about foundation move, and part of this was about the current change culture and decision making. https://github.com/openzipkin/openzipkin.github.io/issues/51
Change culture in OpenZipkin isn't currently templated on well defined processes such as exist in the ASF. Neither is the loosely defined benevolent dictator role.. well defined.. Plus, it isn't exactly the same per repo. None of these things are problems, just realities.
OpenZipkin has many repos and the ones that progress have a champion (or few) who ultimately make decisions to accept or hold off on change. In some cases, particularly documentation and spec repos, decision making or collaboration is far wider, as we try to ensure parties not in the OpenZipkin org are engaged.
There is a core group in OpenZipkin who have sustained efforts and interest, many times working on change they aren't paid to work on nor personally care about. We don't formally dub people like this with titles, but we appreciate them. We have no obvious roster, but it is easy to tell who are more active than others, and who help with the burden of decisions and change.
I have plopped guidance about what sort of change I think is in the long term interest of the projects I spend most time on. It isn't always popular (believe me), but we also can't rely on hiring people to maintain code either. https://github.com/openzipkin/brave/pull/287 So when I'm working on projects I usually follow the same process.
Others follow different processes, but it usually boils down to this: change is merged based on the judgement of those who bear the responsibility and highest burden of change. It isn't merged by committee of folks not fixing bugs or supporting it. Netflix calls this Freedom and Responsibility.
This is a bit of a ramble, but @cschneider asked since it isn't written down, and of course next time we talk about foundation, process and bylaws it might be easier to have it summarized someplace. I'd be happy for someone to polish this more, or pitch into how they lead their OpenZipkin repo which might be different than how I perceive things.