On 5/8/2019 10:45 AM, Adam Spiers wrote:
Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2019-05-07 15:06:10 -0500 (-0500), Jay Bryant wrote:
Cinder has been working with the same unwritten rules for quite some time as well with minimal issues. I think the concerns about not having it documented are warranted. We have had question about it in the past with no documentation to point to. It is more or less lore that has been passed down over the releases. :-) At a minimum, having this e-mail thread is helpful. If, however, we decide to document it I think we should have it consistent across the teams that use the rule. I would be happy to help draft/review any such documentation. [...]
I have a feeling that a big part of why it's gone undocumented for so long is that putting it in writing risks explicitly sending the message that we don't trust our contributors to act in the best interests of the project even if those are not aligned with the interests of their employer/sponsor. I think many of us attempt to avoid having all activity on a given patch come from people with the same funding affiliation so as to avoid giving the impression that any one organization is able to ram changes through with no oversight, but more because of the outward appearance than because we don't trust ourselves or our colleagues. Documenting our culture is a good thing, but embodying that documentation with this sort of nuance can be challenging.
That's a good point. Maybe that risk could be countered by explicitly stating something like "this is not currently an issue within the community, and it has rarely, if ever, been one in the past; therefore this policy is a preemptive safeguard rather than a reactive one" ?
This thread sparked discussion in the Cinder meeting this week and I will just share that here for completeness. Some of our newer members were not aware of this unwritten rule and it has been 'tribal' knowledge for the Cinder team for quite some time. It also has not been an issue for many years. The long story short was: 'If it is a new feature it should be reviewed by at least one person from a different company than the author. For bugs, cores should use their best judgement.' As to whether or not to document it, it looks from the mailing list thread like some teams have documented it and some haven't. So it would seem that letting what each team sees as most fit for their project may be the best answer. Jay