OpenChain-Project / Contribution-Process-Specification

This is a specification to develop a reference specification related to contribution process management for organizations.
Other
3 stars 1 forks source link

Contributing Organization Documents Approvals #8

Open shanecoughlan opened 1 year ago

shanecoughlan commented 1 year ago

From Item 1 here: https://github.com/OpenChain-Project/Contribution-Process-Specification/issues/2

To a receiving organization for open source contributions (most likely a project), it is of importance to understand if the contributions received have the internal approvals necessary for the developer to contribute the code. Thus a requirement should be that the organization contributing also (where so is required by their open source policy) document and maintains a registry of the approvals it has given. If the organizations policy says that any developer is free to contribute to any project, obviously no such approval is necessary.

ContiMary commented 1 year ago

I think making this a requirement could be overkill. It can be part of the process and/or the strategy to track this. It should be optional, in my view.

Jimmy-ahlberg commented 1 year ago

I don't see this one as overkill. It seems necessary for good internal governance in an organization if nothing else. There is the external value connected here for the receiving party, and the internal value for the contributing organization, and the value for the contributing individual.

For example: If we assume that an organization require its employees to seek approval for contributions if more than 10 lines of code (a pure hypothetical), we can assume that there may be consequences for an employee who (perhaps repeatedly) fails to follow the processes.

If I was a contributing employee, I would want it documented somewhere that my contribution was authorized by the right instance within my organization. If nothing else as a CYA for all employees that contribute code.

Likewise if I'm not the contributing employee, but on the approver side in the organization, there is a value for me to see what we have approved in the past. Perhaps I'm new in my role, perhaps we have reorganized, or my predecessor won a billion € at the lottery and quit on the spot without a proper handover. Having access to the approval history has value to me.

A niche case is also in a potential M&A or Corporate audit scenario where the buyer/auditor might want to know what open source projects the target organization have contributed to. Again having it readily accessible in some form is of great value.

What I would want to avoid is to make overly detailed and prescriptive requirements on how this "archive/register" should look like. If an organization uses JIRA to manage the approval flow for open source contribution requests then that is fine as a register. If everything is done via email, that is fine also. If you require everything to be manually signed in triplicate, countersigned, notarized, stamped, and archived, that is also fine (but not advisable). To reiterate a point the original issue, if there is no approval needed according to the organizations policy (for whatever reason), then I would find it overkill to require tracking of contributions, it might be advisable for the reason @ContiMary points to, but I then agree that it should be optional.