| Prepared-By | VS |
| Status | draft |
This note describes our collective understanding of how we coordinate the development of common open-source ODA initiative.
this code-of-conduct is not a binding agreement by any legal meaning.
this code-of-conduct does not override any licenses provided with the code, as long as they are compatible with contractual rights of IP
this code-of-conduct does not override any contractual IP rights of ODA developers
This document describes practices of collaboration in ODA. It touches some aspects of technical practices (see handbook and best practices for more), but is more focused on more human aspects of collaboration. See also other inspirational examples of code of conduct.
We recognize that ODA is an inter-institute project, with different constrains on IP rights (see also the manifesto). As much as possible, involved institutions (UNIGE, SNSF, CNRS?, others?) encourage open publishing with attribution. We shall choose these licenses whereever possible.
These licenses will, ideally, define entirely the practices of code sharing and re-use, rendering the present code-of-conduct not useful.
The https://github.com/oda-hub repository is owned by the original developers of the code, and technical rights implied apply.
Any developer, internal or external, can submit pull requests and contribute to code.
But each of the components, currently represented by one or more projects in oda-hub, will have one or more maintainers.
- maintainers will make reasonable effort to review pull requests quickly, and will be welcoming to contibutors and understanding to user issues. If maintainer is systmatically not available, it can be considered to add/or replace maintainers, if maintainer agrees.
- maintainers are not obliged to perform developments addressing user issues. This function is regulated separately with contractual obligations of the maintainers.
- maintainers will efficiently coordinate agree with other maintainers to act as quickly as a single responsible maintainer would. If not achievable, and not resolved to the detriment of development, maintainer collective must be revised
- if different maintainers have irreconcilable differences but want to continue maintaining, they should produce their own forks, possibly in the oda-hub organization
to summarize, function of the maintainer is to have a vision of the component development, be able to peacefully align this vision with other maintainers, and be kind and thankful to contributors.
You can! Since licenses are permissive. If in doubt - please read licenses - they are the reference for this sort of answers.
?
What if I contribute some code to ODA, and someone will steal it, embed in a different project and use it for their own good?
That's ok, that's what permissive license implies. Your stolen code will be, however, accompanied by original license and some attribution - reference to authorship.
Sorry, the software is provided as it is, and we generally can not promise to fix any issue on your schedule. If the feature matters for you - feel free to open an issue and PR. But please remember to be civil and polite, you are the one asking for help.
We guarantee features of our deployment as we promise them to our users, not your usage of our code.
credits are to be assigned accordning to provenance.
provenance ensures that the contribution does not emerge out of nowhere when it is expressed in a particular medium. The contribution is typically result of influences and other consumed expressions. The complex structure of the contribution should be recognized when assigning credits. It is in the nature of scientific process to focus on individual role of the last-creator. This should be considered with care.
it is to be recognized that degree of contribution is not well described as a single metric.